Mickaël’s Weblog

Today, I received a mail referencing this post from Llewellyn Faco.

My first though is: “does adding unit test on legacy code makes sense?”. I beleive it does not. You would like to refactore your code and be sure not to break any feature? Refactoring makes sense only to make your code evolve to change design or add feature and so on. Legacy code that support features you are not aware of (no unit test) … does not need to evolve…does need only to be replaced by other code (with test around this time). So I found this simply useless. 

The second issue I see is the feasibility of the solution proposed by Llewellyn. One nice side effect of unit testing is the decoupling. And usually, legacy code without tests around has a lot of coupling between classes, thrid parties and databases. Even if the legacy code was well written, you always have a damned coupling somewhere deep inside. So there is no way to instanciate the class you would like only for test purpose.

To summarize: you have some legacy code which works (new code has 99% of the bugs) but you don’t know what it does exactly. Why would you like to add test around? I usually add test to describe what I want tmy code to do and reuse these test to ensure evolution (refactoring, redesign…etc). In the case of legacy code: isolate it as much as possible, consider it as a black box and the only possible evolution is replacement!

I’m currently working on a modeling exercised for connected applications. Modeling an RDBMS schema for a standalone monolithic appliaction is not a real challenge. On top of a set of connected applications, this task start to raise some concept that requires some guidance.

The article Data on the outside vs. the inside from Pat Helland highlight some of this concept.

As I mentionned in this post about persistance, it’s very common to see RDBMS primary keys appearing in entity definition. This is a mistake for a couple of reasons. First, entities should be loosely coupled from the persistance type (RDMS, file, memoty…etc). Using a primary key is introducing technical details from the implementation in the model. The second reason I see is about the immutability of the key.

When i’m talking about key, it’s about the part of the reference of a business entity that identify it. For example, in a REST environement you could reference purchase orders using  this url : customer/C00123/PO/PO00112. In this case the key is the PO number (PO00112). 

The goal of a model (or schema) is to support business application in describing things. 2 things that may seam different are in fact the same from the business perspective. For example, from an asset management perspective, if a laptop already acquired is replaced by another one (of almost the same model) because of a technical problem/failure, the second laptop is concidered as the same. In this particular case, nothing change in the description of the laptop even if physically there are 2 distinc laptops.

So to define the key, you need to answer to this question: from the business perspective, what qualify/reference uniquely an entity type. In the case of laptop for AssetManagement it’s the AssetTag, in the case of employee in HR it will probably be the social number…etc.

Immutability of such key means that key of an entity can’t change. If you want to change it because you assigned a temporary one for example) that measn your application should expose a process for this and in fact you will create a new entity with the new key and look at all attributes and relationship to apply them on the new entity. And this process should trigger all audit system.

Communities, in general, are getting more and more traction.

O’Reilly is creating on line books that are “community centric” : dedicated to a community and community-authored”. Everyone can contribute to this books composed of articles that are rated by the community.

Having a look at the 97 Things Every Software Architect Should Know is worthy.

Je vous recommande les tutoriaux sur Spring MVC de Serge Tahé. Ce ne sont pas des Quick Start Guides, mais comme l’indique le titre: Spring MVC par l’exemple. Tout y est donc illustré avec des exemples et la couverture me semble exhaustive (pour l’instant je n’ai parcouru que la partie 2…mais elle fait déjà 99 pages).