How do you foster a culture of security and performance awareness and excellence in code review? (original) (raw)
Powered by AI and the LinkedIn community
Code review is a crucial practice for ensuring the quality, security, and performance of your software projects. However, it can also be challenging, time-consuming, and sometimes frustrating for both reviewers and developers. How can you foster a culture of security and performance awareness and excellence in code review? Here are some tips and best practices to help you achieve this goal.
Top experts in this article
Selected by the community from 7 contributions. Learn more
To start off, make sure that every member of the team comprehends the significance of both security and performance. Regular training sessions, workshops, and e-learning courses can help keep the team updated on the latest best practices. Another item that I like to indicate for my teams is "Peer reviews." Pair programming helps to detect and mitigate issues early.
The single, most crucial aspect of a code review is to keep in mind that regardless of your role (reviewee or reviewer) the other person is, first of all, a person. Mocking or demeaning someone is extremely easy but completely unhelpful: understanding the other person's perspective and way of thinking can go a long way to uncover hidden and often wrong assumptions which then propagate through the code.
To help with developer productivity, ensure that the coding standard is able to be supported by tools. For example, document functions and their parameters in such a way that your editor can provide tooltips showing the parameter documentation when you’re writing a function call.
Use tools and automation
Code review can be tedious and error-prone if you rely on manual inspection and testing. To make your code review process more efficient and effective, you should use tools and automation to help you identify and fix security and performance issues. For example, you can use static analysis tools to check for common vulnerabilities, code smells, and style violations. You can also use dynamic analysis tools to measure and optimize the performance of your code under different scenarios and loads. Additionally, you can use code review platforms and tools to facilitate collaboration, feedback, and tracking of code review activities.
- There is also a lot of intrinsic, long-term value in hackathons that make code toolable: many successful products have been around for many more years than a lot of most recent best-practices and unit testing is one of these, so there is a lot of value in transforming old code into new code that can be easily tested. Besides getting the code in better shape, such hackathons also spread knowledge across those invisible boundaries that invite mistakes.
Provide constructive feedback
Code review is not only about finding and fixing problems, but also about learning and improving as a developer. Therefore, you should provide constructive feedback that is specific, actionable, and respectful. You should explain why a certain code change is necessary or beneficial, and how it can improve the security or performance of the code. You should also acknowledge and appreciate the good aspects of the code, and encourage the developer to keep up the good work. Furthermore, you should avoid harsh or personal criticism, and focus on the code, not the person.
Be quick to praise, slow to criticise. Hold back criticism until you have fully understood the flow of thought behind a certain change. Remember that even the most junior of developers can be right and occasionally the change that has been made should be the reference for the rest of the code and it may make sense to go in and change old code to the new way.
I personally take this a step further. On more complex or nuanced change sets where the why is not clear I "review" my own pull request with comments to help the actual reviewers understand the idea behind the decision. The primary reason is that sure the reviewer could look at the story/ticket/issue, then read all the changed code, then all the affected code that was not directly changed, etc. but that simply takes a lot of time and burden on the reviewer that is top of mind and easy to convey. The cost of doing so is much lower than the reviewer has to pay.
There is a lot of value in group reviews as well: sometimes having more people "taking shots" at a piece of code can unlock amazing insights and dispel very bad assumptions borne out of no one talking about what the assumptions should be. Also, sometimes assumptions have an expiry date and it would be best to review those as well and make sure they still align to reality.
Thanks for your feedback
Your feedback is private. Like or react to bring the conversation to your network.
``
More relevant reading
``