Code maintenance: Code fragility and coupling
Jalmaraz
667
Like
Share
ReportThere are programs that are hard to change and maintain, you know what I mean: sometimes we have afraid to modify a program. Then we talk about fragility, but experts divide this problem in many symptoms: Rigidity (difficult to change), Fragility (some change breaks many other parts of program).
And the question is: What makes a code difficult to change and maintain?
The obvious answer
The prophets of paradigms quickly found the answer: clean code, readability and TDD. Yes, that is the base and source of many problems, but beyond the practices issues there are other places to search problems in application design.
Duplication and coupling
I my opinion, the two main problems to change code are:
- Duplication. When we repeat code that do the same all over the application. This is hard to change, because to make a change you must review all code duplications.
- Coupling. Parts of code are so related, that if you touch one of them, you must fix many problems in the other parts of application.
It´s easy: avoid duplication and coupling……. isn´t it?
Many people before me, said “avoid duplication and decouple and your code will be flexible”.
But it´s not so easy, because many times duplicate and coupling, work in opposite directions. Sometimes avoiding coupling you can duplicate, and sometimes avoiding duplicate you can couple code.
We live in a complex world plenty of compromise solutions: if you ask me, when you must to make this decision, choose duplicate:
- Duplication, most of times it´s a programming trouble, and you can refractor this issue technically, with a painless amount of cost.
- Coupling it´s a design mistake. Most times it´s very hard to fix. And sometimes you refuse to fix it and take the decision to assume this technical doubt forever.
Coupling and Reservation Entry lessons. (opinion).
After NAV 3.00, Navision includes in Reservation Entries the lot tracking. Before then, these two managements were in separate tables.
I suppose, avoiding duplicate they put lot tracking management there. In my opinion since then, is too hard to make a change in lot tracking.
I know, some people have published patterns about change reservation entry to include new fields, but I think anyway that this should not be necessary. If you customize item tracking adding a new field to edit, you notice how unnecessary complex is this design: The simple way to do it was 3.00 version way with separate reservation and item tracking.
This only my own opinion. Many people, even in my company disagree.
Liskov to the rescue.
The problem isn´t relating things, the problem is relating things that are not related. Lot item tracking is a different (and easier) management than item reservation, and when we put it together, we have problems.
We are coupling in NAV all the times we use something for a use out for his real purpose:
- When we use a master (customer, vendor, Item) for another non-related entity.
- Using sales, transfer or purchase documents, for movement that isn´t a sale, purchase or transfer.
The question before relating two objects is: “the new object related is a true subtype of the original object?”
This question has a somewhat like the principle developed by the computer scientist Barbara Liskov:
“if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program”. The Liskov question here: is the lot tracking a reservation entry?
*This post is locked for comments