I’m going on an adventure
Three months ago I quitted my job as a Java developer and move out of desktop development for the first time.
Currently, I’m working as a web developer, both backend and frontend, at an university in my hometown. A lot of new things to learn, an environment completely new.
In this project, we are a team of two developers. The application is almost 15 years old and the source code is a disaster. All the developers that used to work in this project left the company almost at the same time.
When I decide to accept the job, our initial idea was to modernize the frontend stack, that was besides from using old technologies and have a completely messy code; and to restructure the backend code to better separate the responsibilities.
After we start to dig into the old code, we realized that our primary plain wasn’t possible to realize. We now need to rewrite the entire application, the only part that we’ll be able to maintain is the database, because it’s shared with some desktop applications.
I have a professional experience with languages like: Assembly, Delphi, Visual Basic 6, Java and a bit of C#. This is the first time I work with PHP and now I understand why almost everybody hate it, but I don’t. Like any other language, the root of all problems are the developers and not the technology.
There’s no doubt PHP has some inconsistencies, but the main problem of the source code of this application is what the old developers did with it. Given the flexibility of PHP, they used it to make horrible things, plus the fact that they configure it to hide every error. It’s without any doubt the uglier code base I ever saw.
As I said earlier, the primary plan was to rewrite the frontend and reorganize the backend, but at this point we decided to rewrite it entirely. I’ll give just one example of the kind of situation we are facing.
A query that should be simple, show some user data, had around nine variations distributed in various PHP files. The other developer that are working with me in this project analyzed every variation, and came up with the conclusion that only two queries should exist for this. Then, he wrote this two queries, fixing some bugs from the older versions, and now it replace the nine old queries in the new application.
The business rule are now cleaner and maintained in a single file, depending on the type of the user, one or other query is used. It’s gonna be a great adventure. :)
To simplify our task we choose to adopt a MVC framework, we tried a few (Silex, Slim, Laravel, Symfony, etc) and decided to pick CodeIgniter. Oh the irony of modernized a web application using CodeIgniter, but keep in mind that just the fact that we’ll be separating the responsibilities in the Model-View-Controller architecture will be already a huge improvement for the health of the code base.
CodeIgniter is a really simple framework, with it we are being able to rewrite the application’s modules by chunks, keeping the new code working integrated with the old code. The login part was already rewrote and deployed in production, and after the user authenticate it fills sessions variables and redirect the user to the old application. Some side functionalities was already rewrote and deployed.
We decide to adopt Twig to simplify our code in the templates, I think it’s really easy to extend, I already added a range of helper functions and tags to streamline the exhibition of form’s validations errors, CSRF token generation etc.
The application have a bad security history, with this new application we won a range of improvement in this area without needing to do much. We configured Twig to autoescape everything, CodeIgniter gives us a simple way to escape every query and to protect our forms from CSRF.
Every configuration of the old application like, database connection, FTP credentials, and others, was kept in various PHP files, with different values for development and production environment, this files must not be deployed to production, no matter what. This characteristic add very big point of failure to our deploy, if a developer deploys this files to production, bad things will happen.
For the new application the configuration files are the same for every environment, development, the staging environment we are trying to create, and the production environment. The values for each configuration are chosen by a single variable in the CodeIgniter’s “index.php”. Because this file is kept in a separated file tree, it’s less probable that someone deploy it by mistake.
As you have already imagined, the frontend code of the application has it’s own bag of problems.
The new frontend code uses Bootstrap, this way we can focus our time rewriting application more quickly, because almost every functionality we need are already builtin in Bootstrap. And this way we can also make the application looks a lot better in mobile devices. Besides the only important pages of the application rewrote until now are the login pages, the mobile usage already started to grow, I found this to be a very interesting fact if we keep in mind that only a few pages are responsive.
I organize every static file in a common directory tree, before this they was spread across almost every subdirectory of the old application.
I’m using Grunt, and created a bunch of tasks, from linters to autoprefixers, minifiers etc. The frontend code evolved a lot compared to the old version, the legacy application’s static files are served without even being minified.
Even the indentation was not made correctly in the legacy code. Recently, reading an old file, a line with an ‘if’ was indented with nine spaces, the line below it was using 45 spaces. What would be the justification for it?
The past team of developers treated the users in a very special way. They remained isolated from the users, it was extremely hard for users to get in touch and submit feedback. We decide to change it too.
At the new application’s footer, we add two links that open a modal for feedback and bugs reports. The messages can be sent anonymously, this way it’s more confortable for users to tell bad things about the system. :)
Using the user’s feedback messages we were already able to identify and help solve a lot of problems, even in the process of other departments inside the institution.
We start using Google Analytics to monitor the usage of the application, to know what is the most used parts, what browsers our users have access to, this way to have a guidance of what we need to be improved.
Because our login process is not very conventional, there a few type of users, each with their own login credential pair, I created some events in the login pages using Google Analytics. Now I know if the layout is working good enough, if the help message is really helping our users. For instance, almost every user faced with the help text are able to successfully login in the application in the second try.
From now on, I plan to write my posts in English, at least the post with some technical nature.
Beside the new job, I’m trying to be more involved with web development in my free time, from courses to books. I’m sending some contributions to the Kuma project, it’s the project that powers the Mozilla Developer Network. I’m also maintaining an open source website developed with Django.
If you, dear stranger, find some kind of error in my publications in English, please let me know. :)