---
title: Project Quality handbook
tags: handbook,project,quality,WIP
---

Project Quality handbook
===

## Introduction

## Base Requirements<a name="base-requirements"></a>

To ensure the quality of the software project, the following are the ideal base requirements for every project.

- The website of a particular project should be able to load completely at the maximum of 4 seconds page-load.
- Each functionality of the project should be able to complete it's process within 3 seconds mark with the exception of following: download, upload, and other long-term processes.
- The software should be able to log errors on application logs and slack channel logging.
- Mobile ready and performance is optimized for mobile devices

## Source Code Quality<a name="source-code-quality"></a>

To ensure the quality of the software source code, the following coding design principles must be observed in implementation from the order of highest precedence to lowest precedence.

- SOLID
- Single Responsibility Principle
- A class should have only a single responsibility (i.e only one potential change in the software's specification should be able to affect the specification of the class)
- Open/Closed Principle
- A software module ( it can be class or method) should be open for extensions but closed for modification
- Liskov Substitution Principle
- Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program
- Interface Segregation Principle
- Clients should not be forced to depend upon the interfaces that they do not use
- Depedency Inversion Principle
- Program to an interface, not an implementation
- KISS
- Keep it simple and succinct
- DRY
- Don't repeat yourself

should any of the principles conflict with one another the order of precedence is to be followed unless permitted by lead-developer.

# Code Review

Generally when develop code, the developer should make sure of the following:
1. The code is well-designed.
1. The functionality is good for the users of the code.
1. Any parallel programming can be done safely.
1. The code isn’t more complex than it needs to be.
1. The developer isn’t implementing things they might need in the future but don’t know they need now.
1. Code has appropriate unit tests.
1. Tests are well-designed.
1. Usage of clear and concise names.
1. Comments are clear and useful, and mostly explain why instead of what.
1. Code is appropriately documented.
1. The code conforms to style and convention guides.

The following are the common things to look for when reviewing code:
1. Font used ( Avoid using web downloaded fonts )
2. Confidential Information
3. Hard coded configuration must be done through environment configuration, commonly these are the following
- URL
- Secret/Access keys