The Pragmatic Programmer

by Andy Hunt

29. Write Code That Writes Code 103 Code generators increase your productivity an...

30. You Can't Write Perfect Software 107 Software can't be perfect. Protect your code and users...

31. Design with Contracts. 111 Use contracts to document and verify that code does no more and n...

32. Crash Early 120 A dead program normally does a lot less damage...

33. Use Assertions to Prevent the Impossible 122 Assertions validate your assumptions. Use them to protect yo...

34. Use Exceptions for Exceptional Problems 127 Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. ...

35. Finish What You Start. 129 Where possible, the routine or object that allocates a resource should be r...

36. Minimize Coupling Between Modules 140 Avoid coupling by writing "shy" code and ap...

37. Con.gure, Don't Integrate 144 Implement technology choices for an application as configuration options, not th...

38. Put Abstractions in Code, Details in Metadata 145 Program for the general case, and put the specifics ...

39. Analyze Work.ow to Improve Concurrency 151 Exploit concurrency in...

40. Design Using Services. 154 Design in terms of services—independent, concurrent objects behind well-d...

41. Always Design for Concurrency 156 Allow for concurrency, and you'll design cleaner interf...

42. Separate Views from Models. 161 Gain flexibility at low cost by designing your application i...

43. Use Blackboards to Coordinate Work.ow. 169 Use blackboards to coordinate disparate facts and agents, while maintaining independe...

44. Don't Program by Coincidence 175 Rely only on reliable things. Beware of accidental complexity, and don't confuse a happy...

45. Estimate the Order of Your Algorithms 181 Get a feel for how long things are likely to ...

46. Test Your Estimates. 182 Mathematical analysis of algorithms doesn't tell you everything. Try timing your...

47. Refactor Early, Refactor Often 186 Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.

48. Design to Test. 192 Start thinking about testing before you write a line of code.

49. Test Your Software, or Your Users Will. 197 Test ruthlessly. Don't make your ...

50. Don't UseWizard Code You Don't Understand 199 Wizards can generate reams of code. Make sure you understand all of it before y...

51. Don't Gather Requirements—Dig for Them. 202 Requirements rarely lie on the surface. They're buried deep beneath layers of assum...

52. Work with a User to Think Like a User 204 It's the best way to gain insight into how the ...

53. Abstractions Live Longer than Details. 209 Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from diff...

54. Use a Project Glossary 210 Create and maintain a single source of all the specific terms a...

55. Don't Think Outside the Box—Find the Box 213 When faced with an impossible problem, identify the real constraints. Ask yourself: "Does it have to be done...

56. Start When You're Ready 215 You've been building experience all your life. Don'...

57. Some Things Are Better Done than Described 218 Don't fall into the specification spiral—at some p...

58. Don't Be a Slave to Formal Methods 220 Don't blindly adopt any technique without putting it into the context of your deve...

59. Costly Tools Don't Produce Better Designs 222 Beware of vendor hype, industry dogma, and the aura of the price ...

60. Organize Teams Around Functionality 227 Don't separate designers from coders, testers from data modelers. Bui...

61. Don't Use Manual Procedures 231 A shell script or batch file will execute the same instructions, in t...

62. Test Early. Test Often. Test Automatically. 237 Tests that run with every build are much more effective than...

63. Coding Ain't Done 'Til All the Tests Run ...

64. Use Saboteurs to Test Your Testing. 244 Introduce bugs on purpose in a separate copy of the source to veri...

65. Test State Coverage, Not Code Coverage 245 Identify and test significant program states. Just testi...

66. Find Bugs Once 247 Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tes...

67. English is Just a Programming Language 248 Write documents as you would write code: honor the DRY principle, use metadata, M...

68. Build Documentation In, Don't Bolt It On. 248 Documentation created separately from code is less likel...

69. Gently Exceed Your Users' Expectations 255 Come to understand your users' expectations, then deli...

70. Sign Your Work 258 Craftsmen of an earlier age were proud to sign their w...

Architectural Questions page 55 Are responsibilities well defined? Are the collaborations well defined? Is coupling minimized? Can you identify potential duplication? Are interface definitions and constraints acceptable? Can modules access needed data—when needed?

Debugging Checklist page 98 Is the problem being reported a direct result of the underlying bug, or merely a symptom? Is the bug really in the compiler? Is it in the OS? Or is it in your code? If you explained this problem in detail to a coworker, what would you say? If the suspect code passes its unit tests, are the tests complete enough? What happens if you run the unit test with this data? Do the conditions that caused this bug exist anywhere else in the system?

When to Refactor page 185 You discover a violation of the DRY principle. You find things that could be more orthogonal. Your knowledge improves. The requirements evolve. You need to improve performance.

Cutting the Gordian Knot page 212 When solving impossible problems, ask yourself: Is there an easier way? Am I solving the right problem? Why is this a problem? What makes it hard? Do I have to do it this way? Does it have to be done at all?

Aspects of Testing page 237 Unit testing Integration testing Validation and verification Resource exhaustion, errors, and recovery Performance testing Usa...