One of my pet projects at the school of public health has been to try to bring my team to use enterprise grade development techniques and processes. It was made a lot easier by our move to AWS, giving us a good excuse to start using code versioning and continuous integration and Harvard’s IT Academy which was promoting and training us at using AGILE software development. It was a fantastic opportunity and a great experience. We started from scratch and worked it all out as a team. I will not cover the entire process as this would take several posts, I will rather focus on one specific topic that I researched a lot and I think is a too often overlooked while being critical: Code Quality.
What follows is a curated list of articles and blog posts about Code Quality that, I hope, will help you understand how critical it is for any team that wants to become truly AGILE.
Why Code Quality matters?
- The Cost of Bad Code, and Preventing it – Pedro Esperança – Hackernoon
- Why I changed the way I think about Code Quality – John Cobb – Freecodecamp
- Make Yourself Dispensable – Lihsuan Lung – 8th Light Blog
- The Outrageous Cost of Skipping TDD & Code Reviews – Eric Elliott – Javascript Scene
How to improve your Code Quality?
Bellow are 3 types of improvements you can implement that will greatly improve your code quality. I listed them by difficulty of implementation ( both technical and human).
Style-guides and coding standards
TL/DR: Take some time to find a style-guide/coding standard that you like, follow it to the letter, enforce it using a linter/sniffer tool. Your entire code-base should look like a single developer wrote it.
I’ve read a lot of arguments in favor and against coding standards. I’m all in favor. Having your entire team follow the same syntax is the first step to code that is easy to understand, review, modify and optimize.
- Why Coding Style Matters – Nicholas C. Zakas – Smashing Magazine
- Why You Need Coding Standards – David Mytton – Site Point
- 15 Rules for Writing Quality Code – Rule 1: Follow the Style Guide – Diomidis Spinellis – InformIT
Some examples of Coding standards:
- Mozilla
- jQuery Core Style Guidelines
- Google JavaScript Style Guide
- GitHub Style Guide (Ruby, HTML, CSS and JavaScript)
Code/peer reviews
TL/DR: Evidences are overwhelmingly in favor of code reviews, so please make them an essential part of your workflow.
Peer reviews have so many benefits that I wont list all them there. However I will point out that to be efficient and not a waste a time, everyone needs to take code reviews seriously.
- Code Reviews Q&A – Sakis Kaliakoudas – The babylon blog
- How About Code Reviews? – Mark Christian and Duretti Hirpa – Slack Engineering
- Code Reviews: Just Do It – Jeff Atwood – Coding Horror
- Crafting Better Code Reviews – Vaidehi Joshi – Medium
Architecture, design patterns and general methodologies
TL/DR: This is going to be harder to implement, but is the final required step to create truly enterprise-grade software.
That’s where, IMO, it gets a little more complicated. Because the cost vs benefit of these techniques and methodologies may vary depending on the project. This will also require some discussion at the team level and will require your entire team to do some research, learning and more importantly change the way they develop. Finally they are a million of them: List of software development philosophies.
I think the key here is to pick one or two, implement them and slowly add new paradigms as your team matures and your project grows.
Some of my favorites:
- One function one purpose
- Don’t repeat yourself (DRY)
- Keep it simple, stupid (KISS)
- You aren’t gonna need it (YAGNI)
Finally embarrassing Object Oriented Development and Test Driven Development is probably a good idea too.
A few good reads to give a little more context:
Conclusion
If you are starting from scratch, there is a lot to be done, but take it easy. One step at a time, don’t try to refactor everything on day one. Remember that is is supposed to help you to be more efficient on the long run. Yes it will take you some extra efforts and time at the begging and yes there is never a good time to do this…Do this incrementally, test new ideas on smaller projects.