Project: Flowey
Maintaining a legacy application An interview conducted with David, one of the founders of TenTwentyFour1024
- Interviewer:
- What is Flowey CMD?
- David:
- Flowey CMD is a PHP-based project for L.C.I. Flowey S.A., one of the largest producers for car-wash products in Europe, that was begun in the 1990s and has since seen its fair share of developers "fiddling" with its code-base. In 2014, the current developer was no longer available to look after the project and thus the company that had until then be maintaining the application was looking for experienced PHP developers to take on the job. In their eyes it was very important that the next developer of the application be more than just your standard eight-to-five developer, instead bringing passion and a solid programming experience into play. In fact, since the 1990s, the code had never really been refactored or brought up to speed, which means in essence it was, and largely still is, what we call "spaghetti code", a chaotic mixture of PHP and Javascript code, alltogether with badly formed HTML markup throughout its almost one-hundred, uncategorized files. The project also didn't have any namespaces of course, no classes, except where – rarely, external libraries were used – and almost no functions either. Most of the code flow used to be linear with conditional statements throughout the files, often thousands of lines long, determining which code to execute, what to print, etc.
- Interviewer:
- What is TenTwentyFour1024's task on this project?
- David:
- TenTwentyFour1024's job in this project is two-fold: First, maintaining the application, upgrading those parts that need urgent replacement (e.g. replacing the php-mysql database driver with php-mysql-nd and MySQLi or PDO), fixing bugs and adding new functionality. New functionality however, is added by using a Silex-based application completely rewritten from scratch. The second job is to gradually migrate the legacy code to new, PHP5.6/PHP7 based code using the same silex application as a backend, and relying on REST APIs wherever possible, to integrate the new parts with the existing legacy code.
- Interviewer:
- Faced with this "spaghetti code" nightmare, how did you proceed to make it more manageable?
- David:
-
The first steps that TenTwentyFour1024 took were to bring the entire project under version control, add code-style and mess detection checks and add additional software metrics, such as coupling, stability, cyclometic complexity… to get an initial understanding of how problematic the code was and how much effort would be required to tame it. Using the Behat BDD tool, TenTwentyFour1024 gradually started covering most functionality of the application, first and foremost the parts that needed to be refactored, extended or otherwise improved. Having the support of these tools, TenTwentyFour1024 could finally start to modify the code's application without fear of inadvertedly breaking existing functionality. More than 216 scenarios and 3530 steps currently cover the application, all of them passing with flying colors in Jenkins, our continuous integration tool. Whereas the application was previously developed in a separate folder structure on the production server, TenTwentyFour1024 has introduced a reproducible build process including database migrations using ant and flyway. We are developing the application locally using a docker ecosystem and deploy a new revision continuously using capistrano in a matter of just seconds.
- Interviewer:
- What problems arose during development and how did you solve them?
- David:
- Due to the structure of the project, it is extremely difficult to grasp the entire control flow and keep it in one's mind during development. Parts of the application were sometimes only working due to errors that had the desired side-effects. The HTML througout the application was generally broken, so was its encoding. TenTwentyFour1024's concern was to introduce a proper MVC pattern to separate the various concerns and quickly understand what is going on. The functional tests we keep adding help us stay sane while moving around the code, gradually replacing parts of it and fixing really old bugs.