You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+37-65
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,6 @@
2
2
I've been Programming, Designing and Architecting Java applications for 15 years. I would like this page to serve as a good starting point for programmers to understand what it takes to build good applications. I would talk about Best practices and Frequently asked questions in Coding, Designing and Architecting Java Applications. If you have feedback, contact me on my website http://www.in28minutes.com.
3
3
4
4
## Journey of a Programmer
5
-
6
5
### How to become a good programmer?
7
6
8
7
@@ -48,12 +47,29 @@ I've been Programming, Designing and Architecting Java applications for 15 years
48
47
49
48
50
49
### Code Quality
50
+
###Code Quality Overview
51
+
52
+
53
+
- 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).
54
+
- 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?
55
+
- 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:
56
+
- Onboarding a new programmer. Makes him comfortable with all the new things he has to encounter.
57
+
- Implementing a complex functionality.
58
+
- Next question is how to approach a Code Review. Difficult to cover everything. I would make a start. When doing a code review, I start with static analysis results (for example, sonar). I spend 10 minutes getting an overview of components and/or layers (focusing on size and dependencies). Next I would pick up a unit test for a complex functionality. I feel unit tests are the best place to discover the dependencies and naming practices (I believe good names = 50% of maintainable code). If a programmer can write a simple and understandable unit test, he can definitely write good code. Next, I look for 4 principles of Simple Design. After this, there are 100 other things we can look for - You decide.
59
+
60
+
### Why should you not take code quality tools at face value?
61
+
- If a project has a great Sonar report, does it mean it is perfect?
62
+
- Nope, code quality tools are just a guidance!
63
+
- Your focus should be to write code that adheres to "4 Principles of Simple Design"
64
+
- Peer Reviews are necessary!
51
65
#### Why should you have coding standards?
52
66
#### What are the most important coding standards?
[Design in Agile Projects](pdf/AgileAndDesign-Evolution.pdf)
113
130
#### Evolutionary Design
131
+
### What are the 4 Principles of Simple Design?
114
132
###Design Focus Areas
115
133
116
134
- 4 Principles of Simple Design. https://www.youtube.com/watch?v=OwS8ydVTx1c&list=PL066F8F24976D837C
@@ -196,6 +214,7 @@ Listed below are some of the important considerations
196
214
- Personal Experience with Deployment Automation, Providing user screen with requests/responses
197
215
198
216
### Component Based Architecture
217
+
#### Why should you create small components?
199
218
200
219
## How to be a good architect?
201
220
- PDF - How to be a good architect : https://github.com/in28minutes/java-best-practices/blob/master/pdf/How%20to%20be%20a%20good%20Software%20Architect.pdf
@@ -232,68 +251,19 @@ Most important qualities I look for in an Architect are
232
251
233
252
#### 10 Tips For Eclipse
234
253
[10 Tips for Eclipse and Maven](pdf/10TipsforEclipseAndMaven.pdf)
235
-
236
-
## Frameworks
237
-
## Performance
238
-
### Why should you optimize judiciously?
239
-
### How can you increase performance and reliability of applications using Queues?
240
-
241
-
### Distributed Cache
242
-
243
-
244
-
## Security
245
-
246
-
247
-
248
-
### Why should you create small components?
249
-
250
-
### Why should you migrate to GIT?
251
-
252
-
### What are the 4 Principles of Simple Design?
253
-
254
-
### What is Pair Programming?
255
-
256
-
### Why is readable code important?
257
-
258
-
### What is component based architecture?
259
-
260
-
### Why should you commit your code often?
261
-
262
-
263
-
264
-
265
-
### Why should you write unit tests with/before code?
266
-
267
-
### What are version control best practices
254
+
### Version Control
255
+
#### Why should you migrate to GIT?
256
+
#### Why should you commit your code often?
257
+
#### What are version control best practices
268
258
- Do not commit derived files.
269
259
- Do not commit IDE files.
270
260
- Commit often
271
261
- Use Git
272
-
273
-
### Why do Stateless applications perform better?
274
-
275
-
###Code Quality Overview
276
-
277
-
278
-
- 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).
279
-
- 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?
280
-
- 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:
281
-
- Onboarding a new programmer. Makes him comfortable with all the new things he has to encounter.
282
-
- Implementing a complex functionality.
283
-
- Next question is how to approach a Code Review. Difficult to cover everything. I would make a start. When doing a code review, I start with static analysis results (for example, sonar). I spend 10 minutes getting an overview of components and/or layers (focusing on size and dependencies). Next I would pick up a unit test for a complex functionality. I feel unit tests are the best place to discover the dependencies and naming practices (I believe good names = 50% of maintainable code). If a programmer can write a simple and understandable unit test, he can definitely write good code. Next, I look for 4 principles of Simple Design. After this, there are 100 other things we can look for - You decide.
284
-
285
-
### Why should you not take code quality tools at face value?
286
-
- If a project has a great Sonar report, does it mean it is perfect?
287
-
- Nope, code quality tools are just a guidance!
288
-
- Your focus should be to write code that adheres to "4 Principles of Simple Design"
289
-
- Peer Reviews are necessary!
290
-
291
-
## Security
292
-
Hmmm... Should I really explain the importance of Security?
- First and Foremost - NO premature optimizations. Any optimization decision should be based on numbers or past experience. In Donald Knuth's paper "Structured Programming With GoTo Statements", he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of non critical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
### How can you increase performance and reliability of applications using Queues?
281
+
282
+
### Distributed Cache
283
+
284
+
### Load and Performance Testing
309
285
- PDF Presentation https://github.com/in28minutes/java-best-practices/blob/master/pdf/LoadAndPerformanceTestingBestPractices.pdf
310
286
- Have clear performance objectives. That’s the single most important objective. Decide Peak Load, Expected Response Time, Availability Required before hand.
311
287
- Establish clear performance expectations with the Interface Services
- Make sure team is not making premature optimizations. Any optimization decision should be based on numbers or past experience. In Donald Knuth's paper "Structured Programming With GoTo Statements", he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of non critical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
317
293
- Have Clear Strategy on How to Handle expected load. What would be the initial settings on the application server? Do you plan to use a clustered environment? Do you need a load balancer?
318
294
319
-
320
-
321
-
322
-
323
-
324
-
325
-
326
-
295
+
## Security
296
+
Hmmm... Should I really explain the importance of Security?
0 commit comments