A few months ago I realised that I'm missing something as a developer (leaving apart my weakness on DataBases... quite keen on keeping this weakness for a while more... promise to work on this though)... It is Refactoring
Most of the project I've been involved with, I've started from scratch and after some support and maintenance time, handed over to some support guys. The most critical change I've made has been moving from prototypes or "tracing bullet" projects to production, but this has nothing to do compared with the complexity that Refactoring a 5 years big old program means.
So the main driving point of nTPV migration personally is understanding the last lifecycle stage: Refactoring... and as result of this tedious process of revisiting and being ashamed by some things I've coded, I'm expecting to learn valuable software lessons. Today I've got the first...
I think the most difficult software to write (in this order) are:
- middleware (multilenguage, multicompiler, multiOS libraries - bricks to build other programs)
- libraries & API's.
- GUI's
- rest of programs.
Thanks god and as you may guess there is no middleware on nTPV refactoring, but there are a few libraries that in the past were used by other of our programs. While testing ntpvxml (previous libbslxml), I realised that Jordi and I took a wrong decision on the API naming convention and argument ordering of that library...
At that point in the past the whole library was "domain" centric so the objective was trying to hide underlaying Xml QT components (QDomElement / QDomDocument / QDomNode) complexity by representing xml element trees on a "stringified" domain fashion, so any element of the tree could be reached with a string tag in the form "x[n].y[n]". Therefore a common factor of most of the methods and the most important argument was this domain tag, which means that most of the ntpvxml methods have this TagDomain as first argument.
And that was so wrong! ... Would you blame Jordi (as he was the one designing the library) ? don't think so, probably common sense would make us use the same naming and argument convention! And yet it would be wrong!
The thing is that keeping the "common factor" or main argument of the library as the last argument of our APIs allow us to pass default values (at least on our beloved C++)...
Writing some more unittest for ntpvxml I've had to create a few methods to make sure that the API was consistent, and the user could write on the default (current) domain, and this inevitably has come to writing methods twice (createAttribute and createAttributeHere)... and that seems so wrong!, doesn't it?
Worst thing is that there's nothing to be done now if I want to keep backward compatibility and make the migration process smoother... The API would expose twice the number of methods (making it more difficult to use) until the whole migration has been done, and a second refactoring review could be performed.
