Saturday, April 2, 2011

BOOK REVIEW: 97 Things Every Programmer Should Know - Part I

I'm reading the book and would like to share my opinion about it.

Version read: February 2010: First Edition.
Free review links:

My first impression reading the book
   My first impression was very good, the book started with ideas I've learned to understand by bad experience and good books advices.

  • Don't take your time, no matter how easy it looks.
    • When given a project/job/work-item, don't 'take your time', be fast - especially at the beginning of the project and don't tempt to do shortcuts to save time it'll cost you with great interest ('lava flow' anti-pattern) later on. 
    • If you have debt's - manage them (excel / notepad ... any way) and repay them as soon as possible.
  • Apply functional programming principles.
    • Less mutable depandancy will make your functions more durable to variables state (especially in multi-threaded domains (see immutable definition).
  • Ask yourself 'what will the user do', talk to him, interview him, show him basic GUI behavior, include him, watch him in action.
    • Most of the user behave in the same basic way to complete a given task.
    • They also make the same mistakes.
    • Prefer obvious way of doing things than faster (shortcut) ways.
    • What the user request and what he really wants usually have a big gap.
      • Watching a user for an hour might save you a lot of redesign later on.
      • Watch the user work is better than guessing what he needs.
  • Automate your team's codding.
    • Use auto generated code tools.
    • Creates code templates for reuse.
    • Use formatting tools.
    • Use static code analyzers to find anti-patterns and break them if found.
    • TDD your code, measure test coverage.
    • Apply written guidance for important things you can't automate.
    • Guidances should be dynamic according to the project evolution.
    • Do the above for the important things.
  • KISS principle!! 
    • Simplicity
      • Readability
      • Maintainability
      • Speed of development
      • 'Sounds good' / beautiful design/solution/code.
    • Read others code
      • Find a good open source expert code and read it, refactor 'Microsoft.Net' code for example.
    • Simple objects with single responsibility.

No comments:

Post a Comment