45 habits of efficient programmers

"Accepting others' ideas rather than blindly accepting them is a sign of an educated mind ."

-Aristotle

 

Attitude:
1. do practical work
Less complaints and complaints, less criticism of others; find out the problem and find a solution; used to take responsibility
2. Speed is not up to speed
The cost of privilege cannot be long; code quality is crucial (continuous refactoring)
3. Wrong person
Case-based discussion
4. overcome all difficulties and forge ahead
Courage is the only way to overcome difficulties.

 

Learning
5. Tracking changes
New technologies emerge in an endless stream, insist on learning, participate in technical activities, communicate with others, and grasp the Technology Trend
6. Investing in teams
Build a Learning Team
7. Discard
Old routines and technologies, should be lost
8. Break the sandpot and ask to the end
Ask more why
9. Grasp the development pace
Control time, develop good habits, and try not to work overtime

 

Development Process
10. Let customers make decisions
Users must listen to their voice at the scene, and have the say on the most important decisions of the business.
11. design guidance rather than development manipulation
Design is a forward map, guiding the direction rather than the purpose itself. The design details should be appropriate
12. reasonably use the technology
Select technology as needed rather than other factors. Strictly screen various optional technical solutions and sincerely face various problems
13. Make the application available for publishing at any time
Through continuous integration and version management, You can compile, run, or even deploy applications at any time.
14. Early Integration and frequent Integration
Integration is risky. Try to integrate as much as possible.
15. Early automatic deployment
16. Use the demo to get frequent feedback
17. Use short iterations and incremental release
18. Fixed prices mean betrayal
Estimation should change based on actual work

 

Tools
19. Guardian Angel
Automated Testing is your guardian angel
20. Use it first to implement it.
Test-driven development
21. Different environments have different problems.
Pay attention to the problem of multiple platforms (cross-platform)
22. Automatic Acceptance Test
23. measure the real progress
Do not deceive yourself in workload Estimation
24. Listen to your voice
Every complaint hides valuable truth.

 

Programming
25. The code should clearly express the intent
The Code is intended for humans. Do not be clever.
26. Use code to communicate
Annotation Art
27. Dynamic trade-offs
There is no optimal solution, and various goals cannot be fully covered, focusing on important user needs
28. incremental Programming
Write a little code to build, test, refactor, and rest. Clean code
29. As simple as possible
Rather than traditional. Complexity must be justified.
30. Compile cohesion code
Classes and components should be small enough, with a single task
31. Please do not ask
Use more messages and less function calls
32. Replace according to contract
Delegation is often better than inheritance.

 

Debugging
33. Record problem solving logs
Do not fall twice in the same place. The greatest wealth of errors.

Error archiving information should include:
. Problem occurrence date
. Problem Description
. Solution details
. Reference an article or website to provide more details or related information
. Screenshots of any code snippets, settings, or dialog boxes
34. Warning is an error
Ignoring the warning of the compiler may make a big mistake.
35. solve each problem
Divide and conquer
36. report all exceptions
37. Provide useful error messages
Make a little effort to write error messages

Team collaboration
38. schedule regular meetings
Regular Meeting and short meeting (stand-up meeting)
39. The architect must write code
Architects who do not write code are not good architects. Good architects come from practical programming. They can have a deep understanding of the Code.
40. Implement code Collective Ownership
Allows developers to rotate between different modules and tasks in different regions of the system
41. Become a mentor
Teaching and learning. Share
42. Let everyone find a solution
Guidance, rather than directly proposing solutions
43. Share the code after preparation
Do not submit code that cannot be compiled or has not passed the unit test.
44. Perform code review
Review is critical to improving code quality and reducing errors
45. report progress and problems in a timely manner

 

In addition, the comparison between pig and chicken is quite interesting!

Code review checklist:
All exception handlers cannot be blank
Whether the input parameter is valid
Code readability
Are there any obvious errors?
Repeated code?
....