중요하지만 잘 안지켜지는거.....

훔....동감..but...잘 안지켜진다는....거...I can't...

Jazoon Reports: 97 Things Every Programmer Should Know by Kevlin Henney

Published June 3rd, 2010 Under Conferences | Leave a Comment

Methods & Tools is the sponsor of a large number of software development conferences, but I cannot find the time and budget to visit them. This year I managed to find some time spend some time at Jazoon, a major Java event located in Zurich, Switzerland. I will present in this blog some of the interesting things that I heard.

Nothing beats experience in software development and usually you learn the important things the hard way.  This presentation is based on an O’Reilly book with contribution from 73 different people and edited by Kevlin Henney. He presented for us 17 of them in his lively style.

1) Do a lot of deliberate practices
Kevlin added: “to make the task, not to complete the task”. He compared this with a cello player that will exercise for hours just to perform rarely on stage. The importance is not to realise things but to be confident when and how to use coding techniques.

2) Learn to estimate
This part deals with the difference between estimate, target and commitment. It is contributed by Giovanni Asproni, a Methods & Tools author. For a more detailed discussion, look at his article  “Fingers in the air: a Gentle Introduction to Software Estimation”

3) Know your next commit
It is a good thing to have a big picture of your current project, as in “I am working on this user story for my customer”, but developers should also be able to focus on the current task, as in “I am refactoring the CreateAccount code”.

4) Comment only what the code cannot say
If a program is incorrect, documentation matters little.

5) Code in the language of the domain
Use in your code names meaningful for domain, like AccountNumber or CreateAccount for a bank.

6) Prefer domain specific types to primitive types
DistanceInMeters is more meaningful than integer

7) Resist the temptation of the singleton pattern
You are never sure that there will always be only one instance of an object.

8) Don’t repeat yourself
Duplication is waste. Repetition in process calls for automation. Repetition in logic calls for abstraction.

9) Beware of the share
On contrast with the previous item, sharing code libraries creates dependencies for code that could evolve separately and that are just temporally coinciding.

10) The road to performance is littered with dirty code bones
Sometimes you just get better performance with less and cleaner code

11) The longevity of interim solutions
Try to avoid them… or take time to clean them after implementation.

12) The Boy Scout rule
You should leave the world just a little better than you find it and improve in little increments.

13) Two wrongs can make a right and are difficult to fix
Sometimes a bug is “corrected” by another bug further in the code. When you try to fix the second, the first one is revealed, but difficult to detect. It could be easier to leave things as they are.

14) Read code
We love to write code, but when it comes to reading it, we usually shy away. Reading code help us improve our writing abilities and increase our knowledge of programming styles.

15) Write test for people
Your tests are targeted at the person that is trying to understand your code. Tests are here to document the code and tell what it means to be right for the code.

16) Don’t be cute with your test data
because somebody else could see it ;o)

17) Ubuntu coding for your friends
This is not a reference to the Linux version, but means rather than your code might be used by your friends. If your code is bad, then their code will be bad.

The full list of 97 things is available on http://tr.im/97tepsk