Practices for Existing Codebases - MAliKhatri/Ali-khatri-Knowledge-Base GitHub Wiki

image

Practices for Working & Reworking on Existing Code-bases for Professional Development.

Abstract

In this article we will learn What are the practices for working on and reworking of existing codebases, languages, frameworks, platforms and etc. in web development & design projects.

Introduction

In an organization and for professional development there might arise a need when a person has to use or take over another persons code and start working on the code from that specific breakpoint.

This could be due to many conditions, joining a job in the middle of an on-going project or working on an existing project file which might have been found on the Internet. In this condition the code which is already present should be studied thoroughly and understood such that addition to the code could be done.

The various things a person should look for in the code base is the file structure, the dependencies, the various plug-ins etc.

One way to understand the code is to create characterization tests and unit tests. You can also run a static analyzer over your code to identify potential problems. This will help you understand what the code actually does. And it will reveal any potentially problematic areas. Once you understand the code, you can make changes with greater confidence.

How to work with an Existing code base?

Working with an existing code base could be easier if broken down into steps. The steps which should be followed are:-

  1. Review Documentation- Reviewing documentation of the original requirements will help you understand where the code came from. Having that documentation handy will help you improve the code — without compromising the system. Without this information, you could accidentally make changes that introduce undesirable behavior.

  2. Only Rewrite Code When It’s Necessary- Rewriting an inherited codebase can be tempting. But it’s usually a mistake. It takes too much time and too many programmers to rewrite everything. And even if you do it, rewriting code can introduce new bugs. Or it can remove hidden functionality.

  3. Try Refactoring Existing Code Instead- It’s better to try refactoring existing rather than rewrite it. And, it’s best to do it gradually. Refactoring is the process of changing the structure of the code — without changing its functionality. This cleans the code and makes it easier to understand. It also eliminates potential errors.

When refactoring existing code, it’s best to:

  • Refactor code that has unit tests — so you know what you have.
  • Start with the deepest point of your code — it will be easiest to refactor.
  • Test after refactoring — to make sure you didn’t break anything.
  • Have a safety net — e.g., Continuous Integration — so you can revert to a previous build.
  • Make Changes in Different Review Cycles.
  • Don’t make too many changes at once. It’s a bad idea to refactor in the same review cycle as functional changes.
  • Plus, this makes it easier for code reviews. Isolated changes are much more obvious to the reviewer than a sea of changes.

  1. Collaborate with Other Developers- You may not know the codebase very well. But some of your fellow developers probably do. It’s much faster to ask questions from those who know the codebase best. So, if it’s possible, collaborate with someone who knows it better than you do. A second set of eyes on the code may help you understand it better.

  2. Keep New Code Clean- There’s a way to avoid making the code more problematic. And that’s by ensuring new code is clean. It ought to be written to adhere to best practices. You can’t control the quality of the inherited code. But you can make sure that the code you add is clean.

  3. Do Further Research- Working with an inherited codebase gets easier with time. A junior developer may not understand why a codebase hasn’t been refactored (and may be keen to refactor it). But a senior developer will know when to leave it alone.

Bibliography/References

image