scribble

Scribble

About Blog Email GitHub
‹
›

01 May 2014
The Pragmatic Programmer Checklist

Last year, I read a great book on Programming and development (The Pragmatic Programmer). Here is a gist of checklist you must do in case you are developer. These are very good and for sure will help you evolve as a better developer.

Architectural Questions

  • 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?
view raw architecture.md hosted with ❤ by GitHub

The debugging checklists

  • 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?
view raw debugging.md hosted with ❤ by GitHub

How to Program Deliberately

  • Stay aware of what you're doing.
  • Don't code blindfolded.
  • Proceed from a plan.
  • Rely only on reliable things.
  • Document your assumptions.
  • Test assumptions as well as code.
  • Prioritize your effort.
  • Don't be a slave to history.
view raw delibrateprogramming.md hosted with ❤ by GitHub

Cutting the Gordian Knot

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?
view raw guradianknot.md hosted with ❤ by GitHub

Languages to Learn

  • Golang
  • Dart
  • Core Python
  • JavaScript
  • C
  • Lisp
  • Haskell
  • Rust

Note: This is my personal languages checklist, Feel free to replace it with your languages of choice.

view raw languages.md hosted with ❤ by GitHub

Law of Demeter for Functions

  • An object's method should call only methods belonging to: Itself
  • Any parameters passed in
  • Objects it creates
  • Component objects
view raw law of demeter.md hosted with ❤ by GitHub

How to maintain orthogonality

  • Design independent, well defined components
  • Keep your code decoupled
  • Avoid global data
  • Refactor similar functions
view raw orthogonal.md hosted with ❤ by GitHub

Things to prototype

  • Architecture
  • New functionality in an existing system
  • Structure or contents of external data
  • Third-party tools or components
  • Performance issues
  • User interface design
view raw prototype.md hosted with ❤ by GitHub

Aspects of Testing

  • Unit testing
  • Integration testing
  • Validation and verification
  • Resource exhaustion, errors, and recovery
  • Performance testing
  • Usability testing
  • Testing the tests themselves
view raw testing.md hosted with ❤ by GitHub

When to Refactor ?

  • 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.
view raw whentorefactor.md hosted with ❤ by GitHub

The Wisdom Acrostic ( Customer specific)

  • Why do you want to learn them?
  • What is their interest in what you have got to say?
  • How sophisticated are they?
  • How much details do they want?
  • Whom do you want to own the information?
  • How can you motivate them to listen to you?
view raw wisdom.md hosted with ❤ by GitHub

Til next time,
Nancy at 08:35

scribble

About Blog Email GitHub