45 good habits

Original address: http://news.csdn.net/a/20100212/217004.html



Attitude

1. Do the real thing

Don't complain, complain, blame others, find out the problem, and find a solution. Be brave enough to take on problems and mistakes.

2. Haste is not enough. Solving problems

with cleverness and expediency, and seeking speed without regard to code quality will leave a deadly dead end for the project.

3.

Treat . Discuss issues wisely, sincerely and humbly, and propose innovative solutions.

4. Against all odds and forge ahead

Courage is often the only way to overcome difficulties.

Study

5. Track Changes It's not scary that

new technologies emerge in an endless stream. Persist in learning new technologies, reading books, reading technical magazines, participating in technical activities, and communicating with people. It is necessary to understand more about the reasons behind the new words, grasp the general trend of technology, and be cautious when applying new technologies to product development.

6. Invest in the team

Build learning team and continuously improve the average level of brothers.

7. Know how to throw away

old routines and techniques. Don't rest on your laurels.

8. Break the casserole and ask to the end.

Keep asking, and truly understand the essence of the problem. Why? Should be your mantra.

9. Grasp the development rhythm

Control the time, develop good habits, and don't work overtime.

Development process

10. Let customers make decisions

Let users be on the scene, listen to their voices, and let them have the final say on the most important decisions for the business.

11. Let design guide rather than manipulate development

Design is a map forward, it shows the direction, not the purpose itself. The level of detail in the design should be appropriate.

12. Appropriate use of technology Technology is selected

based on need and not other factors. Strictly inquire about various technical solutions, and sincerely face various problems.

13. Make your application release-ready

By making good use of continuous integration and version management, you should be able to compile, run, and even deploy your application at any time.

14. Early integration, frequent integration

Integration is risky, as early as possible to integrate as much as possible.

15. Automate deployments early

16. Use demos for frequent feedback

17. Use short iterations, incremental releases

18. Fixed price means betrayal of promises

Estimates should be constantly changing based on actual work.

User Article

19. Guardian Angels

Automated unit tests are your guardian angels.

20. Use it first, then implement it

Test -driven development is actually a design tool.

21. Different environments have different

issues . We should pay attention to multi-platform issues.

22. Automated acceptance tests

23. Measure real progress Don't kid yourself

when it comes to effort estimates.

24. Listen to your users

Every complaint hides a precious truth.

Programming

25. The code should clearly express the intention

Code is for people to read, don't play tricks.

26. Communicating in code The art of

comments .

27. Make trade-offs dynamically

Remember, there is no best solution. It is impossible to cover all kinds of goals, focusing on the needs that are important to users.

28. Incremental

programming Build, test, refactor, rest with a little bit of code. Keep your code clean and tidy.

29.

Try . Don't use patterns, principles, and particular techniques without good reason.

30. Write cohesive code

Classes and components should be small enough to have a single task.

31. Tell, don't ask. Use

more messaging, less function calls.

32. Substitution by contract

Delegation is often preferable to inheritance.

Debugging

33. Record problem solving log

Don't fall in the same place twice. Mistakes are the most valuable asset.

34. Warnings are errors

Ignoring compiler warnings can be a big mistake.

35. Breaking down problems individually

Divide and conquer is one of the most important ideas in computer science. However, the parts should be well separated to consider from the design and prototyping stages.

36. Report all exceptions

37. Provide useful error information A

little more thought will bring you great convenience when things go wrong.

Teamwork

38. Regularly arrange meeting time

Regular meetings and short meetings.

39. Architects must write code Architects who

don't code are not good architects. Good design comes from actual programming. Programming can lead to deep understanding.

40. Implement collective ownership of code

Let developers rotate between different modules and tasks in different areas of the system.

41. Become a mentor

Teaching . Sharing improves the overall capability of the team.

42. Let people figure out their own way to

lead the way, rather than provide solutions directly. Give everyone the opportunity to learn by doing.

43. Share code when you're ready

Don't submit code that doesn't compile or doesn't pass unit tests!

44. Do code reviews

Reviewing is extremely important to improve code quality and reduce errors.

45. Report progress and problems in a timely manner Be

proactive and don't let others ask you.