Codebase Chef (Legacy code)

Tackling codebase for new changes, refactoring, and features

Introduction
This guide is helpful for anyone who is new to coding, handling codebase, or being handed over a new project. In the previous article where I talked about Getting Started on any codebase. I will share with you how to handle the codebase.

Set up your environment

Setting up your environment is basically the first approach to the codebase, setting up a workflow that will be efficient and useful to the project is key, you are probably going to spend a long time with your code editors, so configure it to be engaging and productive to you by installing all the necessary tool and extensions. Every developer has their own preference for their choice of editors.

Version Control Kits

You’ll need these tools if you’re going to develop anything worth using: a method for keeping track of your code modifications (Versioning) and a place to store your code (a repository manager).

Git | Version control

Git was created by the same dude that developed the Linux operating system, and it’s the best version control system available now. Setup your Git locally using the link below.

Server Environment and Package Manager

Node.js is built on the same JavaScript engine used by the Chrome browser. It can serve files and connect to your database using nothing but good JavaScript, or if you prefer, a scripting language that adheres to the ECMAScript Language Specification. NPM or Yarn. These are the two common package managers. You will have to choose and install the right manager for the project.

Database

If you need a place to store your application data. There are a ton of configurations that can be done. Setting up a database for (testing, development, and production). Take time to configure your environment

VPN and Network Protocols | SSH Config

Most companies have a network infrastructure and protocols configured with VPNs. VPN stands for Virtual Private Network and describes the opportunity to establish a protected network connection when using public or private networks. If you turn to have such issues or services over VPNs. Request for the correct guidance and credentials, since VPNs config varies among them

Run test

The next step in tackling the codebase is to run a lot of tests. To see the behavior or pattern of the code. Most codebases have scripts and tests written along with them. Most programming tutorials and resources neglect writing tests, but the test is one of the key components in the software development life cycle.

Extra

So on running the test you have to configure local and production development servers. Populating the database with a local instance of the database. Setting up deployment pipelines. Configuring and modifying computer host files for redirecting URLs, and all other key configs for the project.

By running the test cases being marked as passed. You are on a good path.

Follow the style guide and comments

A style guide contains a set of standards for writing and designing content. It helps maintain a consistent style, voice, and tone across your documentation, whether you’re a lone writer or part of a huge docs team. A style guide saves documentarians time and trouble by providing a single reference for writing about common topics, features, and more. It can provide guidelines for different documentation deliverables, such as API reference manuals, tutorials, release notes, or overviews of complex technical concepts.

A consistent tone and style make your content easier to read, reducing your users’ cognitive load and increasing their confidence in the content’s authority.

If there is already one in place, use the style guide if not read through the already written comments and comment as you write new features too. You can adopt any of the popular style guides. e.g Airbnb Style Guide

Extra.

Configure linting tools, and code formatting tools to give you a cleaner code view.

Keep changes small. Incremental changes

Alright, alright. So in an attempt to understand the code and get things done. It might look suggestive to write the code to your understanding. But wait, you don’t have the time to do that, so I strongly advise you to make the minimum viable change first. This means you should make the least disruptive change that completely fixes the problem before attempting to clean and refactor any code. This gives you an escape hatch.

Worst-case scenario, if you get pulled away to address some other priority or if you’re on a tight deadline at least you’ll have pulled together some working code that you can fall back on. Once you’ve gotten your code working, if you still have time left, you can start making small, incremental improvements and refactor the codebase.

Code like everybody is watching.

Now you will be handling the codebase, so it’s best to write cleaner and best code to your understanding.

Use all clean techniques (design pattern, data structures, style guides, commenting, linting, wiki, and docs). To make your code easy to pick up.

Ask Questions

This is one of the most important and crucial factors in working on any codebase and remote. As a new developer on a team or an old project. As many questions as you can. Ask for clarification and know what you are supposed to work on. Get functional requirements right, otherwise, you might have difficulties in completing the task, or reaching the stated deadline. As a developer don’t be shy to ask for help or get clarification.

Use the opportunity to learn from the senior developers on the project. Ask for key terms you don’t understand used in the project. You might get errors along but know where the error is actually coming from. (Never forget to ask important questions)

Know the code

In the previous article where I talked about Getting Started on any codebase. I talked about knowing the code. But I would like to elaborate on what knowing the code actually means. Now start with reading the code from the level of the variables, functions, and files structure, if possible, and you have enough time. Destructure code by reading it in modules, and running separate scripts to see results. Know the repercussions of changing a small part of the code since they are all bundled up.

Run debuggers take a closer look at generic error messages and custom error messages and log messages

Sometimes error messages might be different from the general error handler we might know. So ask for clarification if you don’t understand the message. So take enough time to know your code before any change is done.

Stay positive

Sometimes, you turn to develop a little push-up against the developer who worked on it, but you are there to make it better. That’s not the end of the world, you can, trust in your unique abilities. Do your best..

Key takeaways

1. Never judge legacy code or change it until you’ve taken the time to fully understand it.
2. Prefer small, incremental improvements over wholesale re-writes or changes.
3. Each change should attempt to leave the code a little better off than it was when you found it.
4. If you need to make big changes, make a business case and get approval first.
5. When adding new features, try to “go with the flow.”
6. If you need to take the code in a new direction, isolate your changes(if possible) and rewrite them into the main line.

Conclusion

Thank you for your efforts in taking the time to read. Based on my experience and extensive research, this article will really come a long way to help startup any codebase. Have fun. Share and connect.