In today’s competitive software development landscape, organizations are actively looking to optimize their Software Development Life Cycle (SDLC) to deliver faster, with better quality, and reduce friction. The rise of Generative AI amplifies this trend even more. Teams that know how to leverage these tools and practices achieve unprecedented velocity.
At Workleap, we decided to take a step back to analyze where we could improve our SDLC as well, in order to reduce friction and help our developers deliver value for our customers faster, without compromising on quality.
Previously, we talked about our improvements in local development with .NET Aspire and how we enforce web APIs standards and guidelines. In this article, we will focus on how we enforce C# code style, quality and performance standards at scale with our open source .NET coding standards NuGet package.
Identifying problems and possible improvements
Many of our services are made of several .NET solutions and hundreds of C# projects. While going through the different code repositories, our platform engineering team found a recurring pattern. Every time developers create a new solution, they are inspired by existing ones and copy some boilerplate code. This boilerplate includes .editorconfig files with dozens if not hundreds of rules, the inclusion of certain packages such as StyleCop, and .csproj properties affecting compiler/MSBuild behavior. Over the years, a certain drift occurred between different projects, resulting in inconsistencies in code style, quality and performance.
We also analyzed more than a hundred pull requests across different repositories, looking for patterns that would influence how long it takes to merge a pull request. We found that a significant number of review comments were related to code style issues. Interviews with developers confirmed that these comments had a negative impact on cycle time, as the back-and-forth could delay the merge to the next day or worse. We also noticed a certain degree of nitpicking, which proved harmful to productivity and relationships among developers. Finally, we detected multiple performance, quality or security issues in these pull requests that went unnoticed, which could be attributed to various factors, such as an overwhelming number of minor style comments that distracted reviewers from more important issues, or too many changes in a single pull request.
Digging deeper in these projects, we also found out that several warnings would pop up at build time, but nothing would prevent the associated code from being merged. This was the beginning of other related MSBuild-related findings, such as:
Nullable reference types being disabled by default in some places
Roslyn analysis level kept to the default, minimal value
Style code not enforced at build time
... continue reading