How to Work with a Not so Perfect Codebase - Based on My Experience of Working in One!
Tags: discuss, programming, beginners, career
Published: 2019-07-25 19:10:07

---
title: How to Work with a Not so Perfect Codebase - Based on My Experience of Working in One!
published: true
description: There is a good chance we find ourselves working in a not difficult, not-so-perfect codebase at some point in our careers. Sure, it is frustrating but how to get the job done?
tags: discuss, programming, beginner, career
---

There is a good chance that at some point in our careers we find ourselves working in a **difficult**, **not-so-perfect** codebase. Maybe the code was initially written for an MVP with hacky code but now you have a _full-fledged product_ built on top of it, maybe the code was maintained for years by a number of people without a proper code owner and _code review_ process and now it is just _thousands_ of lines of code that nobody is there to own, maybe the requirements changed so _dramatically_ that most of the already written code became _obsolete_.

If you become part of a team which is dealing with a scenario similar to any of those mentioned above or in general you are dealing with a codebase that is not very _readable_, _consistent_ and _easy to tread through_, I have tried to put out a short list about how to manage through, bring sanity and actually actively improve such codebases along with developing features according to business requirements - **based on my experience with working on one such codebase**.

##1. Acknowledge the Issues :wrench:

After every member of the team has spent some time with the codebase, the first thing you want to do is to have a discussion among your team with everyone sharing their opinion and acknowledging the issues that exist with the current architecture, the way the code is written, the practices that are followed or the lack of such practices.
It is important to have all members of the team on the same page about **what is wrong** and **what needs to be fixed**.

##2. Tackle One Problem at a Time :hammer:

Do not try to fix everything in one night! When it took _years_ to get there, it is going to take you some time to fix it. 
Identify parts of the application or specific modules that need improvement, decide how much every area is **critical** to your operation and **prioritize** accordingly.

##3. Respect the Business Objectives :moneybag:

Most of the products/projects developed in professional settings contribute towards helping a business achieve its goals. For an organization, achieving those business goals is the first and foremost priority. 
As a developer, we need to respect those business objectives and make sure our quest to **'improve'** the code doesn't come in the way of achieving our business's goals. Always remember when you are there to cross the swamp and when to fight the alligators :crocodile: (<-- I know this is a crocodile)

{% twitter 1144647007627284481 %}

Showing respect for the business objectives also helps you build a relationship of **trust** with the product requirement and specifications teams. This will help you get more time assigned to **cleaning things up**.

{% twitter 1145052576167186433 %}

##4. Establish a Code Review Process :eyes: :eyes: 

Once you have agreed that you need to improve the codebase, the next step you want to do is to have a code review process. It is always better to put **multiple sets of eyes** on every piece of code that gets checked in. It is not necessary to have a senior resource review the code, initially, you could just start by **peer-reviewing**. This will also help the team eventually get familiar with different parts of the codebase.


##5. Integrate Refactoring in Your Regular Bug Fixing/Feature Delivery :arrow_up: :arrow_down:

Sometimes it becomes very hard for developers to get dedicated time assigned for **code refactoring** specifically especially in small to medium-sized projects with limited resources. 
Continue your little _**operation cleanup**_ along with every task, bug fix or feature you check into the code. This way every part of the code that gets touched will keep getting **cleaned up** without putting a **significant** effort at once.


All of my observations come as a junior engineer with 2 years of experience only, spending about a year with one such codebase and seeing it improve with each passing day. My opinions could also be biased only by the kind of teams and projects I have worked on.

Devs trying to find their way through such codebases, what do you guys think of this? Senior, more seasoned guys who have years of experience doing this correct me if I'm wrong or want to add something!