[Updating] The Pragmatic Programming

ch7 Before the project

• digging for requirements

  • make the requirement the general statement , and give the developers the policy information as an example

  • discover the underlying reason why users do a particular, rather than just the way

  • documenting the reasons behind requirements

  • your dev has to solve the business problem, not just meet the stated requirements

  • propose the concept of use cases as a basis for discussions - the developers, the end users, and project sponsors

  • requirements are need

  • accurately reflects the business need

  • capture the underlying semantic invariants as requirements, and document the specific as policy

  • abastractions live longer than details

The Pragmatic Approach

• The evails of duplication adn othrogonality

The basic tools - tools amplify your talent

• Invest in your own basic toolbox

• Plain Text is that standard Our base material is knowledge. We express that knowledge in our designs, implementations, test, and documents. The best format for storing knowledge persistently is plain text.

• Power editing Using one Editor could manipulate text as effortlessly as possible. we should know it very well, and use it for all editing tasks.

• Debugging - fix the problem, not the blame

  • debugging is just problem solving, and attack it as such
  • visualize the data -> get a good look at the data it is operating on
  • Tracing -> the state of a program or a data structure over time
  • Don't assume it, prove it; and how to improve it
  • master one text manipulation language

TODO

reference

• The Pragmatic Programmer by Andrew Hunt & David Thomas