Though several useful answers have been posted here for awhile, I believe there is room for one more. My suggestion is, as others have said, to do code reviews. But it is worth mentioning again because the term "code review" is so vague... almost as vague as "clean code" :-). I have spent a lot of time and effort myself in working toward that elusive goal. And particularly in the last couple years, fueled by colleagues who shared my passion, I distilled my notions, blended with key ideas from prominent developers, into a series entitled the Zen of Code Reviews.
My articles are unique, so far as I know, in that I cover both sides of the aisle: doing a code review as an author and doing a code review as a reviewer. Though related, the skills for each are somewhat different. And being able to do both well will lead to better code quality. Reviewing code is just as important as writing code. Really. It promotes knowledge transfer, it encourages team consistency and communication, it helps you improve your craft, and last but not least, it reduces buggy software very cost effectively--from as close to inception as possible.
The first two provide tips and techniques for preparing a code review. In a nutshell:
- You as the author have intimate knowledge of why each changed line is in your code review. Many are obvious to an educated reviewer, but many are not. Convey those points by annotating your code review before you send it out to reviewers.
- Even before that, consider carefully what comprises your code review: make sure you include all relevant changes for an issue and try not to include more than one issue.
- Make sure you do a source control checkout (to resync your code with main) before you send it.
- Review your own code before you send it--line by line!
Part 1: Pre-Review Comments: Empower your colleagues to give you
better feedback on your code review
Part 2: Best Practices:
Guidelines for preparing a code review
And the other two articles provide practical advice on how to be a better reviewer:
- Read the Jira/issue/ticket/requirement (whatever you call it) first.
- Ensure the unit tests cover the requirements.
- Review the unit tests for equivalence class and boundary value completeness.
- Ensure each unit test does just enough, not testing multiple things.
- Review the code for adherence to SOLID principles.
- Watch out for re-inventing wheels, over-complicated code, and just complicated code.
- Eschew magic (magic strings, magic ints, and, yes, even magic booleans).
- Catch the butterfly effect--are there ripples that were missed (e.g. naming inconsistencies).
Part 3: The Reviewer's Tale: Guidelines for performing a code review
Part 4: Review As If You Own the Code