45 habits of excellent programmers

Attitude

1. Do not complain, complain, blame others, locate the problem, and find a solution. Be brave enough to handle problems and errors.

2. Speed is not up to speed: Use a clever and cost-effective solution to solve the problem.CodeQuality, will leave a dead corner for the project.

3. Ignore people: discuss issues with wisdom, sincerity, and humility, and propose innovative solutions.

4. overcome all difficulties and forge ahead: courage is often the only way to overcome difficulties.

Learning:
5. Tracking changes: the emergence of new technologies is not terrible. Learn New Technologies, read books, read technology magazines, participate in technical activities, and communicate with others. Be cautious when using new technologies for product development.

6. Investing in the team: Build a learning team and continuously improve the average level of the teams.

7. Discard: The old routines and technologies should be lost. Do not stick to it.

8. Break through the casserole and ask the question to the end: keep asking questions and truly understand the nature of the question. Why? It should be your mantra.

9. Grasp the development pace: control the time, develop good habits, and do not work overtime.

Development Process

10. Let customers make decisions: let users listen to their voice at the scene, and make the most important decisions for the business.

11. Let the design guide not manipulate development: design is the forward map, which directs the direction rather than the purpose. The design details should be appropriate.

12. Rational use of technology: select technology as needed rather than other factors. Strict questioning of various technical solutions, and sincere face to various problems.

13. Make applications available for release at any time: with continuous integration and version management, you should be able to compile, run, or even deploy applications at any time.

14. Early Integration and frequent integration: integration is risky and should be integrated as much as possible as soon 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 of commitment: estimates should be constantly changing based on actual work.

User

19. Guardian Angel: Automated unit testing is your guardian angel.

20. Use it first to implement it: Test-driven development is actually a design tool.

21. Different environments have different problems: Pay attention to multi-platform issues.

22. Automatic Acceptance Test

 

23. measure the actual progress: Do not deceive yourself in workload estimation.

24. Listen to the user's voice: Every complaint hides valuable truth.

Programming

25. The code should clearly express its intention: The Code is intended to be read by people and should not be clever.

26. Code Communication: The art of annotation.

27. Dynamic trade-offs: Remember, there is no optimal solution. Various goals cannot be all-encompassing, focusing on important user needs.

28. incremental programming: build, test, refactor, and rest with a little bit of code. Let the code clean.

29. Try to make it as simple as possible. If there are no good reasons, do not use any patterns, principles, and special technologies.

30. Compile the code for cohesion: the class and component should be small enough and the task should be single.

31. Don't ask: use more messages and use less function calls.

32. replacement by contract: the delegate is often better than the inheritance.

Debugging

33. Record the problem resolution log: do not fall twice in the same place. Errors are the most valuable asset.

34. Warning is an error: warnings that ignore the compiler may make a big mistake.

35. Individually solve the problem: Divide and conquer is one of the most important ideas in computer science. However, from the design and prototype stages, each part should be well separated.

36. report all exceptions:

 

37. Provide useful error information: It takes a little more effort to facilitate errors.

Team collaboration

38. Regular Meeting schedule: Regular Meeting and short meeting.

39. architects must write code: architects who do not write code are not good architects. Good design comes from actual programming. Programming can bring a deep understanding.

40. Collective Ownership of code: allows developers to rotate between different modules and tasks in different regions of the system.

41. Become a Mentor: teaching and learning. Sharing can improve the overall ability of the team.

42. Let everyone find a solution by themselves: guiding the direction, rather than providing a solution directly. This gives everyone the opportunity to learn in their work.

43. Share the code after preparation: do not submit code that cannot be compiled or has not passed the unit test!

44. Code Review: Review is extremely important to improve code quality and reduce errors.

45. report the progress and problems in a timely manner: proactively report and do not ask others to ask you.