- More than everything else, code quality is an attitude. Either, the team has it or not. The attitude to refactor when something is wrong. The attitude to be a boy scout. As an architect, it is important to create an environment where such an attitude is appreciated. (There are always bad sheep, who take the code quality to such depth that it is not fun anymore, but I like them more than developers who keep churning out bad code).

- Have a good static analysis tool(and is part of Continuous Integration). Sonar is the best bet today. Understand the limits of Static Analysis. Static Analysis is not a magic wand. For me, results from Static Analysis are a signal: It helps me decide where I should look during peer or architect reviews?

- Have good peer review practices in place. Every user story has to be peer reviewed. Put more focus on peer reviews when there is a new developer or there is a new technical change being done. Make best use of Pair Programming. The debate is ongoing : Is pair programming more productive or not? I would rather stay out of it. You make your choice. However, these two scenarios are bare minimum:

- Nope, code quality tools are just a guidance!

- Your focus should be to write code that adheres to "4 Principles of Simple Design"

- Peer Reviews are necessary!

- Complexity of a method

- Naming variables, methods and classes

- Size of methods and classes

- Number of parameters


- One Slide from PDF - Making use of SONAR

- https://github.com/in28minutes/java-best-practices/blob/master/pdf/CodeQuality.pdf

- PDF : https://github.com/in28minutes/java-best-practices/blob/master/pdf/CodeReview-BestPractices.pdf


- Unit Testing and Mocking : We are in the age of continuous integration and delivery, and the basic thing that enables those is having a good set of unit test in place. (Don’t confuse unit testing with screen testing done manually to check if the screen flow is right. What I mean by unit testing is JUnit test’s checking the business logic/screen flow in a java method (or) set of methods). Understand JUnit. Here is a good start : https://www.youtube.com/watch?v=AN4NCnc4eZg&list=PL83C941BB0D27A6AF. Also understand the concept of Mocking. When should we mock? And when we should not? Complicated question indeed. Understand one mocking framework : Mockito is the most popular one. Easymock is a good mocking framework as well.

- Refactoring. Is there an Architect who does not encounter bad code? Understand refactoring. Understand the role of automation tests in refactoring.

- Continuous Integration. Every project today has continuous integration. But, the real question is “What is under Continuous Integration?”. Compilation, unit tests and code quality gate(s) is the bare minimum. If you have integration and chain tests, wonderful. But make sure the build does not take long. Immediate feedback is important. If needed, create a separate build scheduled less frequently for slower tests (integration and chain tests). Jenkins is the most popular Continuous Integration tool today.

[[ModernDevelopmentPractices.png]]

[Unit Testing Best Practices](pdf/UnitTestingBestPractices.pdf)

- How often is code commited?

- How early are problems/defects found/fixed?

- Deployment

- Chain Tests

- How long does a Continuous Integration build run for? Is there a need for multiple builds?

[Design in Agile Projects](pdf/AgileAndDesign-Evolution.pdf)


- 4 Principles of Simple Design. https://www.youtube.com/watch?v=OwS8ydVTx1c&list=PL066F8F24976D837C


- First of all I’m a great believer that agile and architecture go hand in hand. I do not believe agile means no architecture. I think agile brings in the need to separate architecture and design. For me architecture is about things which are difficult to change : technology choices, framework choices, communication between systems etc. It would be great if a big chunk of architectural decisions are made before the done team starts. There would always be things which are uncertain. Inputs to these can come from spikes that are done as part of the Done Scrum Team.But these should be planned ahead.

- Architecture choices should be well thought out. Its good to spend some time to think (Sprint Zero) before you make a architectural choice.

- I think most important part of Agile Architecture is Automation Testing. Change is continuous only when the team is sure nothing is broken. And automation test suites play a great role in providing immediate feedback.

- Important principles for me are test early, fail fast and automate.

- PDF https://github.com/in28minutes/java-best-practices/blob/master/pdf/LayeringInJavaApplications.pdf

- Do we need to expose external web services?


- Swagger

- YARAS

- Why is it important?

- Personal Experience with Deployment Automation, Providing user screen with requests/responses

###Architecture Review



[10 Tips for Eclipse and Maven](pdf/10TipsforEclipseAndMaven.pdf)


[10 Tips for Eclipse and Maven](pdf/10TipsforEclipseAndMaven.pdf)

- Do not commit derived files.

- Do not commit IDE files.

- Commit often

- Use Git



- PDF Presentation https://github.com/in28minutes/java-best-practices/blob/master/pdf/LoadAndPerformanceTestingBestPractices.pdf

- Have clear performance objectives. That’s the single most important objective. Decide Peak Load, Expected Response Time, Availability Required before hand.