When working on a big project, it is not always easy to keep track of what exactly the code is doing, especially if it is a project that you inherited from other developers that are no longer working on the project.
It can indeed be stressful and can lead to a lot of problems in the long run if you are not careful.
In this article, we will be going over the best practices on handling such situations. But first, if you are not too familiar of what you should and shouldn’t do when testing and reviewing code, you will need to read the following articles:
Table of Contents
Implementing New Code and Handling the Old
When you have been tasked to handle an already established project, you will clearly need to be onboarded on what the project is about and what it is currently doing. Once onboarded, you will be able handle any bugs or change requests from the client.
When implementing new changes to the project, you will need to make sure that your implementations will not cause any problems for the project once you have deployed to the live site.
As mentioned in the Testing Practices For Developers article, you will need to be very thorough with your testing and review any documentation that consists of the change request details to make sure that everything is as according to the client’s requests.
If there are some details that you’re not fully sure of, you can confirm with the client what specifically needs to happen. If the change request consists of long process or a process that includes other components that has already been implemented in the code, you will need to breakdown the entire process into steps so that it is easier for the client to follow.
When the client has given you the information you need, you will then need to go through the entire process of what the client has requested and what they have confirmed so that you can be absolutely be sure that there isn’t any missing code or any steps that you have missed while you have implemented your new code.
If you had to replace an existing function in the project, be sure to only comment it out and check if the function was being used in the project. If you have found instances of the commented-out function, go through the code and test if the function had an important role in the project. This also applies if you are adjusting a function to match with the change request.
The Reviewing & Deployment Process
When you have developed your new code or adjusted existing code, it is fully recommended that you test your code adjustments. It is extremely important that you do a thoroughgoing review of your code to make sure that the solution is compatible with other existing code and won’t cause any major issues.
For instance, if the project consists of code that would send emails and SMS messages to clients, it is extremely vital that you ensure that your code would not send the wrong information or be sent to the wrong people – That is the recipe for chaos.
After you have thoroughly gone through your testing, you would then need to create a pull request for a git branch.
When creating a pull request, it’s wise to get at least one reviewer to go through your code and make sure that there aren’t any gaps in your code or spelling mistakes that could give you and possibly the client a headache in the future.
If your code consists of a new functionality, it is best that you first get it deployed to a testing site, so that the client of the project can test the solution and approve it for the live site. If the code is for a bug fix, it’s first recommended to explain the basic idea of what the fix is doing and possibly give some screenshots from your testing sessions to the client to confirm if the fix is satisfactory or not.
Once all the checks and balances have been done, you can proceed to deploy your code to the live site.
Documenting Messaging and CRUD Processes
It is always important to have documentation for a project – Documentation for a user manual, a technical manual and other types of documentation that relates to the project. It makes it easier to keep track on what is currently happening in the project.
In my personal experience, if you are working on a project that has changed hands so many, it can become difficult to keep track of what code is still being used and what code is not. It is then recommended to create additional documentation to accompany the user and technical manual, that specifies when certain emails and SMSs are being used and sent, and when a scheduled command is being run.
It might sometimes feel a bit redundant when you have a technical manual, but it is useful in the long run. Especially if the client wants a list of what commands are going to be run in the near future since some of these commands can affect thousands upon thousands of database records.
The client does not have enough time to learn code jargon, so it’s best to make it comprehensible. This way, there will be no room for misunderstandings between both the developer and the client.
I hope that this article has been useful and that it will help prevent a pandemonium from erupting.
