Program Code Refactoring

Jan Burse, created May 31. 2009 The development of the sales system is progressing. The mechanism for the order, the account, the download and the activation of products and licenses has been completed. What is still missing is the online modification of orders, as well as the batch processing of marketing evaluations and bookkeeping functions. In addition we will have to invest into the preparation of the product itself, as well as in its integration into the sales system. The current advancement corresponds to 70% of the functionality targeted for the current year. Hopefully we will be able to integrate the product for testing purposes towards the end of quarter 2. We would then have archived 73% of the functionality. The project plan foresees that the main functionality is developed first. Not only to provide room for the preparation of the product itself, but also to better understand the requirements. Let’s consider the distribution of the past work over the different modules. The source text is held in a version management system. Since the version management system stores a historical cut of the source text, it can provide us the necessary data. The analysis shows the number of updated or inserted program lines during the period from September 2008 to May 2009, distributed over the different modules. The analysis does not draw any distinction between program lines that were manually modified or automatically generated. Remarkably the result has the shape of an s-bend for all modules. The modules of the framework are detailed in the first diagram. They were subject to changes from the beginning since the generator functions needed enhancements. Further it has been identified to implement a library for the account and the activation inside the framework. This is however normal development and not refactoring. Such costs resulted only, when we shifted parts of the CRM into the framework. Among the affected parts we find the template management. The reason for this refactoring, these parts are not only used by the CRM, but also for the online orders. In the second diagram we have detailed the application level modules. Among these modules the CRM dominates the sales system. This can be explained by the performed refactoring. When parts are moved, not only costs for the new place arise. Additional costs incur from the fact that the old place must be adapted as well. The tool support as we know it is however limited. Within a module the support is very good. But between modules we are forced to work with cumbersome change lists, if these are developed in the form of independent streams. Therefore for extensive refactoring our diagrams show the manual effort.