|
|
| Monday, 06 February 2012 |
| Lessons Learned |
Don't reinvent domain patterns that already exist
Posted 1 June, 2002
In two projects at different companies, I worked on teams that developed their own classes to represent money. These classes not only needed absolute accurary (no pennies could be lost or gained in transactions), but also needed to represent amounts in different currencies. Finally, in both cases we needed to handle the allocation issue: if $10 is shared between 17 people, who gets $0.58 and who gets $0.59?
After doing this work, I found that Martin Fowler and others had already created analysis patterns and, in some cases, bits of code to handle these problems.
The lesson: we should have searched for existing solutions before spending the time to build our own. At the worst, we would have had good starting points.
Pay Attention to Syntax When Switching Between Languages
Posted 12 August, 2002
The subtitle to this lesson is: keep the few crucial syntactical quirks of a language at the front of your mind when programming in that language.
As an illustration, as a user primarily of Java, and feeling most at home using C-derived languages, I am used to the construct "A = B" for assigning a value. When I code in Tcl, I need to check repeatedly to be sure that I am using "set A B" (or "set A $B", if B is a variable rather than a value). This is a particular problem as my scripts are interpreted at run time, rather than precompiled, so that errors may show up as inexplicable behavior.
Remembering the syntax for commands which are peculiar to a specific language (e.g., upvar in Tcl) is less difficult for me, because I have no underlying pattern in mind.
|
|