The Pragmatic Programmer Quick Reference Guide

From The Pragmatic Programmer: From Journeyman to Master

  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 a Catalyst for Change
  6. Remember the Big Picture
  7. Make Quality a Requirements Issue
  8. Invest Regularly in Your Knowledge Portfolio
  9. Critically Analyze What You Read and Hear
  10. It’s Both What You Say and the Way 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 Decisions
  15. Use Tracer Bullets to Find the Target
  16. Prototype to Learn
  17. Program Close to the Problem Domain
  18. Estimate to Avoid Surprise
  19. Iterate the Schedule with the Code
  20. Keep Knowledge in Plain Text
  21. Use the Power of Command Shells
  22. Use a Single Editor Well
  23. Always Use Source Code Control
  24. Fix the Problem, Not the Blame
  25. Don’t Panic When Debugging
  26. “Select” Isn’t Broken
  27. Don’t Assume It – Prove It
  28. Learn a Text Manipulation Language
  29. Write Code That Writes Code
  30. You can’t Write Perfect Software
  31. Design with Contracts
  32. Crash Early
  33. Use Assertions to Prevent the Impossible
  34. Use Exceptions 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. Always Design for Concurrency
  42. Separate Views from Models
  43. Use Blackboards to Coordinate Workflow
  44. Don’t Program by Coincidence
  45. Estimate the Order of Your Algorithms
  46. Test Your Estimates
  47. Refactor Early, Refactor Often
  48. Design to Test
  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. Start When You’re Ready
  57. Some Things Are Better Done than Described
  58. Don’t Be a Slave to Formal Methods
  59. Costly Tools Don’t Produce Better Designs
  60. Organize Teams Around Functionality
  61. Don’t Use Manual Procedures
  62. Test Early. Test Often. Test Automatically.
  63. Coding Ain’t Done ‘Til All the Tests Run
  64. Use Saboteurs to Test Your Testing
  65. Test State Coverage, Not Code Coverage
  66. Find Bugs Once
  67. English is Just a Programming Language
  68. Build Documentation In, Don’t Bolt It on
  69. Gently Exceed Your Users’ Expectations
  70. Sign Your Work

Advertisements

发表评论

Fill in your details below or click an icon to log in:

WordPress.com 徽标

You are commenting using your WordPress.com account. Log Out /  更改 )

Google photo

You are commenting using your Google account. Log Out /  更改 )

Twitter picture

You are commenting using your Twitter account. Log Out /  更改 )

Facebook photo

You are commenting using your Facebook account. Log Out /  更改 )

Connecting to %s

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理