Quite often I am hired to perform modifications in other web projects done by someone else. This might be an unmaintained website bought ages ago, or when programmers mess up. It is tough to analyze your own code after couple of years from creation. It is much harder to analyze code of someone else. There are so many different programming styles. And most often the code is documented poorly. So, how to do it properly and save the time?
1. Gather all documentation of code if it is available. What framework or library was used? Was a CMS used? If so, you are in luck as these are more or less documented. Not always, though. If the basis used is branded as “software”, the documentation is typically lacking. It is assumed that you don’t need to modify ready to go software.
2. Try to map code on some known framework/pattern/approach. If there is clear separation from business logic, database tables and visual representation, you can try to approach the code using MVC. If there is separation between data processing and representation, then it is template based approach. Maybe the system is hook based? This will help to understand how programmers think. Worst kind of code is when business logic calls representation logic which calls some different business logic and so on. Then it might be a mess, especially if you can’t get why programmers decided to do so. Usually there is a different separation taking place between first and second layers of business logic, though sometimes this can be called “quick hack to output specific info” only.
3. Try to identify file deployment structure and write it down. Where are configuration files, templates, classes located? What is structure based on?
4. Draw a basic request scheme on paper. What files/modules the request passes till result is send to the user? This will help you to better understand the software.
5. Identify places you need to make modifications. The best help is simply stopping execution in various places of file and seeing what data you have at these places. Die(), echo and print_r are the best friends.
6. Stick to commenting out old code and commenting changes you make. Make it easy to undo your changes, and make it easy to understand what you have done.
7. Last, but not least, test everything.
Quite often I am hired to perform modifications in other web projects done by someone else. This might be an unmaintained website bought ages ago, or when programmers mess up. It is tough to analyze your own code after couple of years from creation. It is much harder to analyze code of someone else. There are so many different programming styles. And most often the code is documented poorly. So, how to do it properly and save the time?
- Gather all documentation of code if it is available. What framework or library was used? Was a CMS used? If so, you are in luck as these are more or less documented. Not always, though. If the basis used is branded as “software”, the documentation is typically lacking. It is assumed that you don’t need to modify ready to go software.
- Try to map code on some known framework/pattern/approach. If there is clear separation from business logic, database tables and visual representation, you can try to approach the code using MVC. If there is separation between data processing and representation, then it is template based approach. Maybe the system is hook based? This will help to understand how programmers think. Worst kind of code is when business logic calls representation logic which calls some different business logic and so on. Then it might be a mess, especially if you can’t get why programmers decided to do so. Usually there is a different separation taking place between first and second layers of business logic, though sometimes this can be called “quick hack to output specific info” only.
- Try to identify file deployment structure and write it down. Where are configuration files, templates, classes located? What is structure based on?
- Draw a basic request scheme on paper. What files/modules the request passes till result is send to the user? This will help you to better understand the software.
- Identify places you need to make modifications. The best help is simply stopping execution in various places of file and seeing what data you have at these places. Die(), echo and print_r are the best friends.
- Stick to commenting out old code and commenting changes you make. Make it easy to undo your changes, and make it easy to understand what you have done.
- Last, but not least, test everything.
0 Comments