#25. For a less painful development

I was repairing a component that automatically historifies changes in datasets through an abstraction, found out some problems with wrong assumptions in a rushy development. As this code was not made by me, it felt like in this comic, and repairing the component give me the inspiration to take some guide patterns for future developments in our current project at work.

- make functions as test friendly as possible, decompose when you can
- use tests to assure you do not break anything and even it costs more, make tests that build the data they use, don't depend on a DB that may change in the future, so favor functions that receive simple data so they can be easily testable.
- favor composition over inheritance, it gets simpler to make a change of behaviour and extend it
- put code where should go, if you use an instance in a function too many times to access its fields maybe you should consider to put this function inside the class of the instance, if it is your code.

Follow these simple rules and you will be happier at your work also read Refactoring: Improving the Design of Existing Code, a must read.

No comments:

Post a Comment