Modularization of legacy code

Modularization of legacy code

Modular programming: What is it?

Modular programming, as defined by Wikipedia, is a method of computer programming that divides an IT system into separate, swappable modules, each of which has all the components required to carry out a particular function.

What is contained in the module?

  1. The module is made up of two components: the interface and the implementation.
  2. The functionality of the module is specified by its interface.
  3. The module interface's implementation depends on how the module is put into use.
  4. Both the system user (client) and the person implementing the module (module's provider) greatly benefit from the module's partition into the interface and implementation.

What does legacy code mean?

A legacy code is a dated program with the following characteristics:

  • With its spaghetti-like code structure, it is around 20 years old.
  • It lacks documentation or only has obsolete, insufficient documentation.
  • The individuals who worked on creating this system are either no longer employed by the company or are working on other projects.
  • There is a lack of comprehensive information regarding the system's operation and its underlying presumptions.

How may the code be made to be of higher quality?

When adding new functionality to the system quickly, affordably, and without breaking existing functionality, we say that the code quality is good. By breaking the system down into modules, or by implementing code modularization, one (and possibly the only) way to improve the quality of legacy code can be accomplished.

The outcome of modularization is what?

  • Code is divided into libraries that contain logically distinct code pieces as a result of modularization.
  • The resulting libraries could be autonomous and independent on one another.
  • Suppose libraries are viewed as nodes in the graph and the connections between libraries are treated as edges in the graph. Then the libraries after modularization form a directed dependency graph, i.e the graph without cicles.
  • When the dependency graph is cycle-free, the system is simpler to maintain and expand.
  • Strong interdependence between libraries is indicated by the cycle in the dependency graph.
  • Cycles in dependency graphs should be avoided at all costs.

Why is modularization advantageous?

The code after modularization is substantially simpler to maintain since the process divides the code into smaller, often independent components that are easier to review.

Modularization makes it easier to develop the code and add new features, mostly because it divides the code into libraries.

It is easier to re-code the feature after modularization since the process of dividing the code into libraries provides relevant information about the dependencies in the code, which is very helpful when making decisions about future alterations in the code.

Modularization lowers the cost of onboarding a new employee. Because it takes less time for a new employee to become comfortable with the system, costs have decreased.

Modularization separates the system into sections, allowing the system to be sold separately.

A modular system allows you to dive the group of programmers who maintain the entire system into teams working on particular library. The division of the group into teams allows them to gain the deeper understanding of the maintained part of the system.

Using modularisation, it is possible to focus on tests within a library, which facilitates test maintenance and lowers development's costs.

As a result of modularization, unnecessary dependencies between files are removed, which are usually caused by excessive inclusion of files using the #include preprocessor directive. Removing these unnecessary dependencies leads to reducing the compilation time and building the system.

What are the assumptions of modularization?

The basic assumption of modularization is that the system after modularization and before modularization has identical functionality, and interfaces in classes were not changed or they were changed only slightly. It is only after modularization that steps are taken to change the code or re-factor the code. The division of the modernization (reconstruction) of the code into two stages (where the first stage is modularization) allows us to avoid introducing errors to a greater extent.

It is preferable that the modularized code be integrated with the continuous integration system, which is used to build code and run tests.

Modularization does not block the simultaneous development of the system.

The modularization process is significantly impeded when global variables or singletons are used in the implementation, which introduce strict global dependencies between classes.

How is modularization carried out?

Modularization is carried out on the existing system, which means that the alternative version of the system is not built.

The first stage of modularization is to define the most basic classes that will create a library (module). After creating the module, it is turned on and used in the system.

The next modularization steps involve selecting classes that only use modularized libraries and integrating them into the system. Thus, the system is transformed in a modularized systematic way.

References

  1. M. Fowler, Refactoring: Improving the Design of Existing Code, 2018
  2. A. Volkhover, Become an Awesome Software Architect: Book 1: Foundation, 2019
  3. J. F. F. Dooley, Software Development, Design and Coding: With Patterns, Debugging, Unit Testing, and Refactoring, 2017
  4. R. N. Taylor, N. Medvidovic, E. M. Dashofy, Software Architecture: Foundations, Theory, and Practice, 2009
  5. R. C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship, 2008
  6. K. Henney, 97 Things Every Programmer Should Know: Collective Wisdom From The Experts, 2010
  7. R. S. Pressman, B. Maxim, Software Engineering: A Practitioner's Approach, 2014
  8. J. Humble, D. Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, 2010
  9. P. Smith, Software Build Systems: Principles and Experience, 2011
  10. I. Crnkovic, M. Larsson, Building Reliable Component-Based Software Systems, 2002
  11. C. Szyperski, Component Software: Beyond Object-Oriented Programming, 2002
  12. K.-K. Lau, Component-Based Software Development: Case Studies, 2004
  13. M. Feathers, Working Effectively with Legacy Code, 2004

要查看或添加评论,请登录

社区洞察

其他会员也浏览了