Основные положения из Pragmatic Programmer

1. Care about your craft.

Если вы пишите программы, то пишите хорошие программы (плохих и без вас уже более чем достаточно).

2. Think! About your work.

Это как в известном анекдоте - "Штрилиц подумал. Ему это понравилось и он решил подумать еще раз". Делайте это все время работы над программами и вам это тоже понравится. Да и программы будут получаться лучше :))

3. Provide options, don't make lame excuses.

4. Don't live with broken windows.

5. Be catalyst for change.

6. Remember the big picture.

7. Make quality a requirements issue.

8. Invest regularly in your knowlodge portfolio.

9. Critically analyze what you read and hear.

10. It's both what you and how you say it.

11. DRY - Don't Repeat Yourself.

12. Make it easy to reuse.

13. Eliminate effects between unrelated things.

14. There are no final desicions (everything should be reversible).

15. Use trace bullets to find your target.

16. Prototype to learn

17. Program close to problem domain.

18. Estimate to avoid surprises.

19. Iterate the schedule with the code.

20. Keep knowledge in plain text.

21. Use the power of command shell.

22. Use a single editor well.

23. Allways use source control.

24. Fix the problem, not the blame.

25. (First Rule of Debugging) Don't Panick.

26. Select isn't broken.

27. Don't assume, prove it.

28. Learn a text-manipulation language.

29. Write code that writes code.

30. You can't write perfect software.

31. Design with contract.

32. Crash early.

33. If this cannot happen, use assertions to ensure it won't.

34. Use execptions for exceptional problems.

35. Finish what you start.

36. Minimize coupling between modules.

37. Configure, don't integrate.

38. Put abstractions in code, details in metadata.

39. Analyze workflow to improve concurrency.

40. Design using services.

41. Allways design for concurrency.

42. Separate views from models.

43. Use blackboards to coordinate workflow.

44. Don't program by coinsidence.

45. Estimate the order of your algorithm.

46. Test your estimates.

47. Refactor early, refactor often.

48. Design to test (contract).

49. Test your software or your users will.

50. Don't use wizard code you don't understand.

51. Don't gather requirements - dig for them.

52. Work with a user to think like a user.

53. Abstractions live longer than details.

54. Use a project glossary.

55. Don't think outside the box - find the box.

56. Listen to nagging doubs - start when you;r ready.

57. Some things are better done than described.

58. Don't be a slave to formal methods.

59. Expensive tools do not produce better results.

60. Organize around functionality, not job functions.

61. Don't use manual procedures - automate.

62. Test early, test often, test automatically.

63. Coding aren't done until tests run.

64. Use saboteurs to test your testing.

65. Test state coverage, not code coverage.

66. Find bugs once (add new tests for found bugs).

67. Treat english as just another programming language.

68. Built document in, don't bolt it.

69. Gently exceed your user's expectations.

70. Sign your work.