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