45 habits of efficient programmers

Write down EfficiencyProgram45 habits of members.

Attitude

1. Do things

Don't complain, complain, blame others, locate the problem, and find a solution. Be brave enough to handle problems and errors.

2. Speed is not up

Solve the problem with a smart and cost-effective solution.CodeQuality, will leave a dead corner for the project.

3. Wrong person

Let's discuss things in a wise, sincere, and open-minded manner, 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 teams

Build a learning team to continuously improve the average level of the brothers.

7. Discard

Old routines and technologies should be lost. Do not stick to it.

8. Break the casserole and ask to the end

Constantly ask questions to truly understand the nature of the problem. 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. design guidance rather than development manipulation

Design is a forward map, which directs 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. Follow up on various technical solutions and face all kinds of problems with sincerity.

13. Make the application available for publishing at any time

By making full use of 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. Try to integrate as much data 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 promises

Estimation should be constantly changing based on actual work.

User

19. Guardian Angel

Automated unit testing is your guardian angel.

20. Use it to implement it.

Test-driven development is actually a design tool.

21. Different environments have different problems

Multi-platform issues should be emphasized.

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

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

28. incremental Programming

Write a little code to build, test, refactor, and rest. Let the code clean.

29. As simple as possible

Rather than traditional. If there are no good reasons, do not use any patterns, principles, and special technologies.

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 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. solve each problem

Divide and conquer is one of the most important ideas in computer science. However, from the design and prototype phases, each part should be well separated.

36. report all exceptions

37. Provide useful error information

A little more effort will bring you great convenience when something goes wrong.

Team collaboration

38. schedule regular meetings

Regular Meeting, short meeting.

39. The architect must write the code.

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

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. Sharing can improve the overall ability of the team.

42. Let everyone find a solution

Provide guidance rather than directly providing solutions. 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. Perform code review

Review is critical to improving code quality and reducing errors.

45. report progress and problems in a timely manner

Inform you actively. Do not ask others to ask you.