You came up with a great idea, and did your research on it! The designers provide you with the design. Now, as a developer, your first task would be to set up a structured and scalable codebase. To implement this, as your codebase grows, you need to automate your processes and standards as much as you can!

In this guide, I will walk you through some of the best practices that we researched and implemented in our codebase to make it efficient, scalable, consistent, and readable. 

Let’s start from the very basics and help you make your code more readable! 

Implementing Linter

To get you acquainted with what Linter is, I’ll start with an example! Just like a lint remover assists you in removing dust and other particles from a fabric, ESLint analyses your codebase and looks for possible errors and reinforces best practices according to the rules set up by you. ESLint allows multiple configuration options, where you can add your own rules to identify bugs, and maintain standards for your codebase.

First, I’ll give you an overview of the power of Linter and how it can enhance your workflow! It can assist you by:

• Generating warnings if you have installed a debugger in your codebase
• Detect any unused variables
• Reinforce naming conventions of variables
• Make strings consistent
• Limit the maximum length of a line
• Sort or group props

...and much more!

To get a deeper insight, here’s the link to your Linter setup file, that you can incorporate in your codebase. 

Let’s dive into some of the rules that can make your codebase more efficient!

1. No-debugger Rule: When you’re working against deadlines, it’s possible to forget clearing up the debugger code from your codebase. It can then go into production and cause the browser to open the debugger. This Linter rule will create an error and warn you if there are any debugger statements in your codebase.
   
2. No-unused-vars: It’s usual to declare some variables, but end up not using them. This rule ensures that there are no unused variables, functions, and function parameters.
   
3. camelCase Rule: It is preferred to standardise the way you declare variables. This increases the code readability and maintains consistency. This rule ensures that all the declared variables are in camelCase.
   
   
4. Single quotes Rule: Sometimes, inconsistency when working with strings, can be visually unappealing. Some of your codebases have strings declared with a 'single' quote and some with "double" quotes. To keep it consistent, a rule for this can be added in the Linter.
   

5. Max-len Rule: Unlimited number of characters in a single line can make your code unreadable. This rule restricts the number of characters that can be used in a single line.
   
6. No-console Rule: If you’re using the traditional, unadvised way of debugging, and adding multiple console statements, you can sometimes forget to clear them up. The No-console Rule triggers a warning if you have a console statement in your codebase. 
7. Max-props Rule: If you are using a framework that allows passing props from a parent component to a child component, like React or Vue, this rule can increase the readability of your code by limiting one prop per line. 
8. Sort-props: Sometimes when a component is receiving a lot of props, it can be difficult to find a specific prop in just a glance. Alphabetically ordering them could solve the problem and this rule makes sure that all the props are alphabetically listed. 
9. Sort-import: Components might have multiple imports, and to make them more readable, you can add a rule to sort the imports alphabetically in your codebase.

Code Standards 

If you’re starting to build your codebase for a project, it is necessary that you maintain some standards to keep your codebase clean.

Let me start with a short story!

When we started working on our product, we researched the industry’s best practices and standards. We made sure that this will be a living document where we would keep on redefining the standards, to enhance the codebase and meet the company’s needs. At that point, we were unaware of the impact it would create. It assisted us to enhance our workflow in the following ways:

1. Saved us from pushing messy code.
2. Maintained consistency along with the codebase.
3. Increased the collaboration swiftly.
4. Mitigated the chances of buggy releases.

Messy code is difficult to read, test, and maintain. This makes the project buggier and makes it harder for the new developers to onboard.

Let’s talk about how did we maintain and set these standards. First of all, we created segmentations in the major areas and defined their standards accordingly. Some of them include:

1. Server-side Coding Standards
   These standards include the rules on coding styles and contribute towards keeping the codebase clean, concise, readable, testable, and DRY (Don’t repeat yourself). The folder structures and naming conventions have been stated in the standards, to maintain consistency with the codebase.  
2. Github
   It is of utmost importance to name your GitHub branches with consistency. We have broken down our tasks into multiple categories i.e. story, task, bug, hotfix and etc. The naming convention includes starting with the type of work you are doing and naming the branch with kebab-case along with the ticket ID. This helps all the developers in the team to easily navigate through the branches.
   Some standards also include rules regarding the release branches and the base branch with which the code should be up-to-date.
3. Postman
   Postman standards include rules on how to use the mock servers and a guide on how the Frontend developers can maximise their workflow by using the mock API from the postman.
4. Pull Requests
   Before creating a pull request, a standardised checklist has been added for the developer to make sure his code is in line with the current standards, which minimises the time for the reviewer and maintains consistency in the codebase. 
5. React-Redux-Sagas Standards
   These standards have been defined for the FE developers which include good practices which have been researched upon and adopted from the industry, and some company-specific standards to increase the code readability and quality.
6. Testing-Review Standards
   Testing and review standards hold prime importance in maintaining the quality of the code and how we ensure that the code we are shipping is top quality. This is elaborated further in this article and contains some key takeaway points, so hold on! 

Code Review Mechanisms

Okay. First of all, we created a pipeline of reviews before each pull request could be merged into the main branch. Following is the pipeline we created:

1. UI Review: To enhance the process of a UI Review and increase the automation, there are multiple tools like Argos CI, which can test your screens against a provided sample, to make sure everything is pixel perfect. We used a chrome extension “Designers Tool” to make sure our produced code is pixel perfect. 
2. Functional Review: According to our standards, it is mandatory for the developers to write the unit tests with 100% coverage, to minimise the occurrence of any functional errors. However, a QA manually tests for the functionality once the code has been sent in for review.
   Learn more about testing.‍
3. Development Review: This step of the review is unfortunately not automated because it depends on a developer to review the code for any inconsistencies, however, we have a checklist of standards for the reviewer to tally with when they are reviewing the code.

A pull request going through all these stages of pipelines ensures consistency, readability, and maintainability. 

Github Actions

Another optimisation in your codebase, which could automate the way you work as an organisation can be achieved through the efficient use of GitHub Actions. We have implemented some GitHub Actions to enhance our workflow by:

1. Building the Application: It is very common that your code could be working fine, but have some production errors, which could break your app once it has been merged with the production branch. To avoid this, we have written an action to build the app once a Pull Request has been created, and only allows the branch to be merged if the build has been successful. 
2. Unit and Integration Testing: While working in an isolated environment, a developer usually runs the tests related to his contribution. However, when a Pull Request is created, this GitHub Action runs all the tests to ensure nothing is broken.
3. Test Coverage Report: It is useful for the developers to see the coverage of the tests that has been increased or decreased after their contribution to further take action and write the missing tests.
4. Generate Preview and print URL: We have written a GitHub Action using the AWS amplifier which generates a preview for that specific branch for which a Pull Request has been created and prints its URL, making it easier for the tester to access and review just by using that link.

To sum it all up, it is of prime importance to optimise and automate your codebase to make your workflow smooth and your app scalable. If you’ve any questions or require any assistance, feel free to reach us out, we’d be happy to help!