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

Previously: http://shloemi.blogspot.com/2011/04/book-review-97-things-every-programmer_08.html

More Highlights... 

• Choose your tools with care... Keep in mind a few things when selecting tools for your application:
• Each tool have it's own assumptions, this can be in conflict with your architecture assumptions. This will lead to conflicts, workaround and will make your architecture and code more complex.
• Upgrading the selected tool or tools might not be an easy and automated task, this can lead to upgrade problems or complexity.
• Some tool's configuration is not an easy task, better keep than in mind.
• Heavy dependence on one tool will probably be a constrain in the end, leading to heavy price, slow maintenance, performance, can lock/kill your tool's ability to evolve, bad tool can lead to the anti-pattern 'lava flow'.. and more...
• Free doesn't totally mean free. Support costs, a lot. Check support agreements first.
• Free - GNU license means you have to distribute your source code!
• ISOLATE the tools by using Interfaces and Layers.
• Code in the Language of the Domain
• There is no functional difference between: 
• if (portfolioIdsByTraderId.get(trader.getId()) {.containsKey(portfolio.getId())) {...}} // AND
• if (trader.canView(portfolio)) {...}
• User domain names like: Trader and Portfolio... This will reveal secrets instead of creating ones.
• Domain names will make your code more obvious when a new programmer will do  reverse engineering to understand your code.

That's it for now.

Next: TBD...

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

Previously: http://shloemi.blogspot.com/2011/04/book-review-97-things-every-programmer.html

More Highlights... 

• Prefer code re-usability than rewriting chunks of code.
• Write tests to the code you want to refactor. This will give you an idea of the expected results, and will ensure you provide the same results after you'll refactor.
• Prefer many small changes than one big change!
• Test your code per development iteration.
• Review the old system tests, they probably hold some tests you don't even think of and can save lot of pain and time. Each test was probably added with a reason.
• Don't refactor / redesign because you think the code / technology is old! This is not a good enough reason to redesign / refactor!

• Do a cost-effective analysis and prove that the new technology will benefit over time.
• More share, less code, MORE DEPENDENCY!
• When you create a library, each change in it will require a lot of effort from the users of this API.
• If it depends on other shared code, each change in it will cause you to change will cause your users to change...
• Be smart before you release shared code!
• Always leave the region you touched cleaner than you found it.
• Many small improvements, in time, will make your code much better and much easier to read.
• Improve a name of a variable, write help if you understand something, repair typos found... split big function into two smaller ones...decouple...
• Care for your team's code!
• Check your code first before you blame others.
• Mature, widely used code are not likely to have many bugs.
• Version 0.1 release of something is likely to have many bugs.
• Compilers bugs are rare, you better try and check yours first.
• remember Sherlock Holmes’s advice, “Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth,”

Next: http://shloemi.blogspot.com/2011/04/book-review-97-things-every-programmer_09.html

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

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

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

• Google books (90% content)
• Amazon (Table of content + content)

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.

Highlights

• 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.

Next: http://shloemi.blogspot.com/2011/04/book-review-97-things-every-programmer_08.html