Poor Code Quality
Poor code quality is something you want to avoid. Learn what can be the reason for the poor performance of your team.
What Is the Poor Code Quality
Poor code quality describes buggy code or code with high coupling and low cohesion that is difficult to maintain.
Source: xkdc: Code Quality
Poor code quality is an umbrella term for multiple issues with the codebase:
- code that exhibits buggy behavior
- slow implementation
- messy code with high coupling and low cohesion (a.k.a. spaghetti code)
- unmaintainable code
- usage of obsolete libraries/frameworks
- code repetition that leads to costly refactoring
If left unchecked, poor code quality can lead to issues in software delivery. It can bring the development to a halt. If the root causes are not addressed, it can lead to long periods of refactoring or a complete rewrite.
Reasons of the Poor Code Quality
- Poor code quality can be caused by a team that "doesn't give a shit". Make sure that the team knows their purpose.
- Another reason may be a lack of senior expertise within the team.
- Poor code quality can be caused by a long-term technical debt accumulation. Give the team some time for refactoring the code and pay-off the technical debt.
Processes Non-existing or weak quality assurance practices can lead to poor code quality rather quickly.
- Ensure that your team does code reviews and pull requests.
- Introduce Unit Tests and Code Coverage to catch bugs early in development.
- Implement CI/CD so that code has to pass all the tests before it can be merged. For more information, see Continuous Integration and Continuous Delivery.
- Add testers into the team and employ manual testing.
- Ensure that your software development methodology (Scrum/Kanban) leaves enough time for refactoring and writing a production quality code. Decrease the team workload and see if the code quality improves.
- Architecture that has a bad fit with the requirements of the software being written can be the cause for poor code quality.
- If you have a problem with code repetition, ensure that your architecture supports code reuse.
- The particular functionality you try to deliver can be difficult to implement within your current architecture. It can lead to verbose/buggy/hard to maintain code. Try to modify the architecture so it fits the use case.
Want to write for DXKB?
Feel free to contribute. People from DXKB community will be more than happy.
Pull requests tell other team members that you changed something in the code and pushed the change to a branch in a git repository. Then other members can review and discuss the changes before the changes are merged into the master branch.Read more
A Bus Factor measures the minimum number of team members who have to be hit by a bus to put the project in jeopardy. The goal is to increase your Bus Factor as much as possible.Read more
A retrospective meeting is an opportunity for the team to inspect itself and create a plan for improvements to be included in the next Sprint.Read more
Code Review is an important practice for checking each other's code. The reviewers are other developers from the team. The goal is to uncover potential mistakes that could slip through testing.Read more
Continuous Integration is a software development practice that makes developers integrate code changes into a shared repository routinely and frequently. Usually, each person integrates at least daily and that ensures them that their code changes do not break anything.Read more