Be standard in your development process

First of all I want to establish the context of where I am. Maybe that will make you read at least a couple of more paragraphs.

At DevGurus.io we are a startup that is continually improving and refining our development process in order to make it simple to follow but strong enough to cover all our needs.

Most of our dev staff are senior developers with a certain knowledge about what best practices should be followed to produce a high level quality code. The main problem is that these practices are not the same for everyone and that makes software development a bit confusing.

That’s the problem we want to solve here :)

Start simple

What you see above may look to you like too simplistic but it is our core and sometimes is good to be back to our roots.

Code review

This topic deserves its own article but it is something that we were leaving behind in some cases when we were in a hurry or when the change was so small that we thought it was not required.

Code reviews have only advantages:

• You learn from other’s code.
• It's the moment to verify best practices and set quality gates like “every code must have its unit tests”.
• Less experienced developers tend to acquire the good habits of more experienced teammates.

Unit tests

I’m a fan of unit testing, I think is the best tool not only to decrease the amount of bugs in your code but to create better code.

Everytime you need to test something, you’ll realize that the code you just made is not understandable or requires too many external dependencies to work.

Unit testing your code is the best way to document what the module does. Of course, this will depend on how clear the tests were written and the coverage of such tests.

Every time you face new code with unit tests is like walking through the tightrope … it feels much better if there’s a safety net. Of course your life will depend on how well the tightrope was made :)

CI

We encourage everyone to think about Continuous Integration from the very beginning.

There’s no need for everyone to know how to build our CI pipeline or to deploy a Kubernetes cluster. Though is not that hard.

Every check-in should consider the possible existence of multiple environments avoiding hardcoded variables that only work in production. Projects that do not have an environment where to validate prior to production must be avoided from the beginning.

V & V

Similar to CI, we want every developer to think about the next phase after their code is deployed. Verify and Validate.

Every little piece of code must have a purpose, a reason to exists. Maybe is a bug we need to fix. Maybe is a new label in a form. Maybe is a connector between two external services. The QA team needs to know about it.

They need to know how to Validate that your code does what is expected to do. There’s no point in doing a beautiful, testable and highly configurable code that is doing the wrong thing.

At the same time, our QA team must be able to Verify that the process you follow to generate the code was the correct.

Summary

This is the way we see our development process. This is our agreement:

• Ensure your code is reviewed, if possible by more than one person.
• Test it. Try to make a habit of unit testing.
• Build your CI pipelines from the beginning and separate environments.
• Involve the QA team from the beginning to avoid surprises once your code is done.

But as everything in life: it is a journey and we know that this may be imperfect or could be improved.

Feel free to share your thoughts about it, we learn from others as well.