Post mortem on major upgrade of application

Well, its october and we finally got all that re-factored code through our staging and production environments. It was a pretty big move. There were about 70 files to move around between the domain and presentation layers. About 10 were simply moved to a new location, away from the domain objects. this is a mach-ii application, which explicitly uses listeners. since the listeners are part of the application and not part of the domain, i felt it warrented to move away from the *model folder.

Some of the other components (cfcs) were moved from the model root into a specific folder that represented the object.

I updated coldSpring with new definitions to some of the objects and updated paths to existing objects, to their new locations.

I was also able to remove a couple object instantiations and use the coldSpring provided object reference. this simplifies a bit and removes a little memory overhead but more than that it cleans up and organized the code base better. I already had one new developer who is starting work on this application comment on how she likes the organization better, easier to find things etc.

I also ended up splitting up some presentation code into smaller more singular entities. Reuse in the presentation layer is overrated. I had a single view file that was responding to 4 different types of data, which was cool, but in the end, became too difficult to maintain. that reminded me of the fact that 75% of all programming or time that a developer spends is maintaining existing apps. To that end, creating additional view files for each subject is a tradeoff worth taking. The tradeoff is more code to maintain, but less complex, fewer dependencies. In the domain, i did the same thing. There was one of two functions that were responsible for getting lots of different variations of similar data. Again, this is good programming to think re-use and not have 40 different functions that are all doing similar stuff, but as time goes by, you start to appreciate the ease of maintenance - which is supported by more functions that do less or even a single thing. I can tell you that the trade off is worth it. I always appreciate it when i enter the domain into a gateway query that is very specific and not loaded down with 8 arguments, where 4 are required and 4 are not packed with lots of conditional code in case arguments are passed in....where if you make one small change you worry about effecting the other 10 instances of how this function is called.

Part of this move to staging then production also included the removal of deprecated files that were wither moved to a new location or re-factored.

As i said, i think about 70 new files were moved and about 25 were deprecated.

this move also included many updates to the central controller, where i was removing calls to old functions that had been re-factored or removed and updated paths to listeners, that are registered in the controller and removed references to view files that had been deprecated. view files are also referenced in the controller.

Thats it for now. What a move, really minor problems while moving - biggest issues where keeping the labels, thats how we manage deployment, current and on the tip version of files. I ended up missing a couple files, no label and did not move the tip of the label on a couple others. these problems only took a few minutes to correct. The most grueling part was when our testing general was looking real critically at the layout and recordsets of the views that i had re-factored that were being feed by re-factored queries.

Good experience. Looking forward to the next one, thought it be smaller.