Not best code but worth code
Your code is not good!
How many times do you listen this and feel bad?
This can be difficult because as developer we can put a ton of effort but sometimes follow the best coding practices is a path which is not that easy to follow and becomes challenging with the software product for many factors.
But the code is always upgradable, it can change to met best coding practices and even language improvements.
How to improve?
Before jumping into best coding practices, let’s focus into something with same importance as the code improvement, let’s focus in how we reach our current solution: Software Development Process and Product Definitions.
The first thing is have definitions about the job that need to be done in terms of the product we need, producing a Product Requirements Document (PRD) with the following key elements:
- Purpose of the Product.
- Features.
- Release and Acceptance Criteria
- Timeline
Once we have this elements, is time to define how are we achieving them with technology, this is where a Technical Specification is created. It contains in terms of technical elements, how are we gonna reach the goals defined in the PRD.
As developers we need to include which are those practices and baselines that we are targeting to follow. It becomes and interesting element of the design phase because is complicated to fully complete a Solution Specification (Due reviews, missed requirements, updates to PRD, etc) and is almost impossible to complete this definition before start coding, so we must start developing the solution while the Spec is completed (Because we may not reach the timeline if we didn’t start).
Fun fact: It may take as much as the solution is implemented to become a fully complete Technical Solution Specification.
Pro Tip: As this is the scenario we may found a lot, focus in Foundations, because if we have great foundations we are going to be nearly to be aligned with those practices and baselines we define first.
Foundations: All elements that can help us to keep in good track to meet the requirements and best coding.
Best practices
When writing the solution specification is recommended to evaluate it by using an evaluation matrix like the following to early identify possible flaws in our software.
By identifying and measuring the state would be easier to find the blind spots in our software and lead to pay more attention in the technical decisions we are through delivering on next iteration with more solid foundations.
The next scenario occurs while we are releasing small deliverables to meet timelines and fulfill product expectations but what’s the problem so far? Technical Debt and Code Smell.
Let’s be clear, Tech debt and code smells aren’t bad at all, they are just remaining items that may not be done at their time, it can be technical decisions to complete deliverables or just things with “tricks” to work (Don’t forget to annotate a TODO or FIXME for the future developer to remind it) and needs resolution.
The elements which fill this characteristics needs to be tracked otherwise we’ll miss them and in the future become painful to solve them, tracking is the best thing to do.
Once we track them, the way to solve it must be defined in order to pay tech debt or fix the smells and improve our code quality to meet industry standards, the following are suggestions based in scenarios i’ve been through:
- Refactor code to remove code smells.
- Replace code blocks to avoid having security flaws.
- Integrate recommendations from analyzers.
- Evaluate technical decisions and update them to remove tech debt.
- Update linter rules to re-evaluate code and track new findings.
- Improve Coverage, over 70% is a good sign.
- Make code readable and is not all about documenting.
- Reuse as much as you can but don’t fall in over-engineering or become reuse monster.
- Convert code in modular components.
- Choose anti-pattern algorithms while possible to optimize code.
Actions may be different according to the programming language you are using and even the product that you are building, ex: it may not be bad to have a code smell in a general use mobile app for release but no for health software.
That’s all for today post, more tips and trick on the next one.
In the meantime, i’ll share you one of my favorites videos to explain more things about code quality and best practices.
Keep Coding
