How clean is your code? Are you sure?
Between deadlines, new product launches and routine maintenance, it’s easy to see how vetting new code can get pushed down a busy team’s to-do list. Yet blazing ahead without thoroughly testing code can lead to substantial issues — if not in the short-term, then in the future through technical debt.
So, how can teams make clean code a priority?
Unfortunately, said Mike Williams, a lead software engineer at Alteryx, there’s no one simple solution.
“In order to get clean, quality code, it takes a commitment from everyone on the team,” Williams said. “There are no magic bullets.”
Instead, tech teams have to build their own processes for writing, testing and reviewing code and decide what works best for them. To better understand how teams can find that perfect balance, Built In Colorado talked to Williams and Aaron Berlin at Invitae (Formerly ArcherDX) to learn how they produce reliable code that lasts.
No engineer wants to spend more time fixing code than writing it. Berlin said upholding high standards throughout the product lifecycle reduces time spent untangling messy code later. His team leans on automated tools, shared libraries and rigorous code reviews to ensure implementations go smoothly.
When it comes to writing clean code, what are some best practices you follow?
Our software group uses coding standards and automated tooling that enforces those standards. This allows us to keep a maintainable codebase where any developer can support and contribute, not just the original author. The use of linters and other automated tools allow code reviews to focus on implementation rather than poorly formatted or structured code. Additionally, our codebase has a large library of reusable components that reduces the opportunity for duplicated or divergent code.
The software group prioritizes clean code in all aspects of the software lifecycle, including development, testing and deployment.”
What are some bad coding habits that you wish every developer would stop doing?
The worst coding habits come from working in a silo away from the rest of the group. It invariably leads to code that’s difficult to understand and maintain by other members of the team — including the original author.
Also, when a developer chooses the newest technology without vetting it or considering how it fits into the current technology stack, we generally see code that fits poorly into existing expectations and paradigms.
On the code review side, pull requests with a large number of files are difficult to review and typically lead to lower-quality reviews and thus, lower-quality additions to the codebase.
How does your team make clean code a priority?
The software group prioritizes clean code in all aspects of the software lifecycle, including development, testing and deployment. During development, we use shared libraries, automated tools and multi-person review cycles. Our testing is automated and contained in our source code. The automation of the tests through continuous integration tools help keep the merged code accurate and bug-free, leading to less churn and fewer edits in the codebase.
Finally, our DevOps team uses tools like terraform fmt and predefined templates to ensure consistent formatting. We’ve even extended the clean-code mantra to our documents, which all live in-source next to the code and are rendered automatically with each build. Incorrectly formatted documents will block a merge in the same way as a failing test.
Clean code doesn’t just make other engineers’ lives easier but can also have a significant bearing on how customers respond to new products, Williams said. To keep customer — and engineer — satisfaction high, the data analytics software company relies on frequent testing and code reviews to check their work while they’re building new products.
When it comes to writing clean code, what are some best practices you follow?
We focus our attention on understanding how the code works in code reviews, which helps trap logic errors. New features get an architectural review early on. Any new architecture or modifications needed can then be diagrammed and accounted for in planning and provides clarity for developers.
We put a strong emphasis on using unit tests to validate the code. This is sometimes called test-driven development (TDD) or red-green-refactor. The tight loop of the TDD cycle — write test, make the test pass, refactor — enables our developers to discover edge and error cases faster and trap them at our desk. This speeds up development because it prevents future delays caused by finding errors later down the road.
By closely following best practices and processes we have in place, we have high confidence in our code when we send it out.”
What are some bad coding habits that you wish every developer would stop doing?
The most harmful development practice I have seen is deadline-driven development. This is a practice where a company specifies that a given set of features must be delivered by a specific date. Sometimes, the work is simply not ready when the date comes around.
When that happens, the company needs to either move the date for the entire release or release the majority of the new features on time and push back the features that are not ready. Cutting corners to meet a deadline results in serious customer-found defects. This can erode the trust that the customer has in the product and leads to a terrible customer experience.
How does your team make clean code a priority?
By closely following best practices and processes we have in place, we have high confidence in our code when we send it out. It is uncommon to find a defect in the happy path. If a defect is found, it usually results from unexpected use cases, integration failures or surprise edge cases — but these are easy to fix because of our high-test coverage.
