I must first state that I have never been this tired from working on any programming projects, except when I started working on an enterprise Angular web application.
This post is a reflection of what it was like working on a legacy application, which is not my first time working on legacy web apps.
Imagine reading through thousands of lines of code with absolutely zero documentation and no real hints as to how to actually deploy any changes other than "FTP it up to the server".
Some days I questioned my career choice and craved alcoholic beverages, other days I cursed so much, the other occupants in the house became concerned about my mental health.
Firstly, the backend is built with ColdFusion (CF) and I admit I had to Google it to know what exactly it is. I have no desire to learn how CF works, because I do not see any benefit for my career, and I want to specialise in other technologies. Reading the documentation is not a fun experience, even though it is not too badly written. I managed just fine by utilising Claude.ai to help me build basic methods and understand how I need to accomplish certain things in ColdFusion. Searching on Google to find answers to questions I had proved quite difficult to accomplish. I assume it is due to the fact that CF isn't a popular web framework.
The backend files are mostly just one single file with over 50 000 lines of code. This is not CF's fault, any program is at the mercy of its programmer and their skill level. Trying to find something in this spaghetti is not easy, a file search gives multiple instances of the same thing, reused everywhere. Ever heard of reusable functions?
It's like this application was built quickly without any long term plans and the lead architect just said yes to every client request.
Publishing any updates to the QA or Production servers is an absolute nightmare. It's how I used to work when I just started out in web development, but worse. There are hundreds of backed up files on the server, never cleaned up. I understand why this was done, but the mess is disturbing. No wonder the server keeps running out of disk space. These files are also publicly accessible, so imagine a programmer leaves a commented out piece of sensitive information in that file.
Speaking of sensitive information in publicly accessible places, I discovered text files, one of them just over 20GB in size that contained personal information of system users and a third-party integration's API keys. I tried to authenticate with this information to see what data I have access to on the third party's platform and it worked. Scary shit.
These dump files were apparently generated to debug stuff, however I find this practice utterly irresponsible. Don't ever do this.
Publishing any patches or features to live and QA is done with FTP, you would create a copy of the server code, save it with a .bak suffix or something like that, download it to your computer just to be safe, and finally upload the new files.
If something breaks, just delete the new files and rename the backup. I have so many problems with this, because it's slow and the potential for human error is extremely high. The website I manage uses Github Actions to publish merges into the production branch after they've been tested on a staging branch.
There are no guides/documentation about how to set up the ColdFusion backend locally (and I couldn't be arsed to figure it out), all local dev and testing is done in QA, which is not in any way in sync with the production app. Some data is also missing, so the app throws so many errors due to inconsistent data.
Some features were directly implemented in the live environment, so not they're not available in QA, which makes debugging extremely difficult.
The git commit history is also poorly managed. Many commit messages are vague and childlike, with no proper indication of what exactly was fixed. To me it looks like there wasn't any technical leadership on this project, just a cowboy way of building software. There are also so many spelling errors, which is probably just me being asinine, but it looks quite unprofessional, and international corporations use this software.
Let's talk about the front end where I spent most of my time fixing and implementing new features.
It is basically a collection of HTML pages with sparse elements, all being generated by a couple of tightly coupled 10 000+ line Javascript files. I showed some of the code to a friend who is a React developer and he kept asking me what framework this is, and the more I told him it's a homebrewed monstrosity, the more he kept telling me to put it into an LLM and ask it what framework it is. I know for a fact that this isn't any known framework, but a homebrewed one.
If you've worked with any web application framework, there is usually a routes file or page directory that gives one some idea of the general structure of the app. Not this one. The function to fetch page data is quite bizarre, but I can see some method in the madness. The app doesn't use URLs to navigate, but click handlers that load specified HTML pages and hydrate elements on the respective page fetched by backend calls.
The way the app keeps track of where you are, is with using indexedDB values in the client.
The most difficult part of working with this app is figuring out the naming convention of files and functions. It is procedural and functional. I get PTSD flashbacks just thinking about it. The JavaScript file that they call when logging in as an admin is called "adam.js" and the one that is for candidates is called "candi.js". Cute, isn't it?
The number of console.logs everywhere leaking data is staggering. In the admin file I noticed over 180 console.logs in the browser developer console.
Memory leakage errors could also be found while doing a performance analysis.
Thinking about this application makes me feel utterly miserable and the perfectionist in me cringes like crazy when I have to imagine someone built this and felt good about this code and general architecture.
Webpack build times are ridiculously slow, and every time I made a change to a file in the front end, the app would recompile, and log me out of the app. Remember when I said how the app doesn't use URLs to render pages? Yeah... So after being logged out, I need to log in again and navigate to the page I was working on by clicking a sequence of buttons.
When the app refreshes, it clears all data from the client. It saves user details in cookies and gets cleared every time you refresh the page, and I might mention that these cookies are not secure. It's as if these people have no concept of what a browser session is.
I've found thousands of lines of commented out code that should have just been removed, scrolling through hundreds of lines just to try and get to the next function to understand how this spaghetti works! Just remove the code that you comment out, you can always look at your commit history if you need this code again.
The contractor didn't provide any readme file and documentation and verbally told me how to do things, "it's quite simple." No, it's not, this is why you comment code, organise things like pages and core app functionality and include a readme file. Don't keep this knowledge in your head expecting every single web developer to have the same workflow. Documentation is essential if you're not using a framework nor well-known patterns.
I feel exhausted just recalling this application and the burnout I felt after working on it for months, so the final thing I want to discuss is the database.
The first time I looked at the ERD, I asked the other developer who had to work on documenting this spaghetti "What the fuck am I looking at?".
Many data is duplicated, and the database itself is not in any normal form that I could discern. For example, a course's title language doesn't match course description language, and all of the tables are prefixed with either an "h" or "DD". I cannot remember why, but someone told me and it didn't really make sense. It was one of the bizarre mental models of the architect.
All I can take away from this project is that using a framework is not necessarily a bad thing and that one should write code for a human to understand in the future, not so much for the computer.