We’ve all had to cut corners when writing code. Maybe a corner case came up and we implemented a kludge workaround. Looming deadlines can lead us to choose expedient solutions over elegant ones. I hope you are weighing cost, schedule, quality, and risk when you are making these decisions. Over time, these shortcuts accumulate technical debt. This debt manifests itself as poor performance, code smells, and low maintainability.
I’ve discussed how testing and analysis can help us identify and address areas where we are accumulating technical debt. Any sufficiently dedicated developer can use these tools to improve and refactor their project and improve quality. Once you have set the bar sufficiently high for your project, how do you keep the quality from slipping back. This becomes a team effort.
I believe code reviews are the number one tool for maintaining high quality. A code review allows senior developers to ensure that junior developers are following project standards. It also allows junior developers to ask questions to better understand both the standards, and the "dark corners" of your code. This approach works well in the middle of a development push (as many developers are working on interconnected functionality), or in maintenance mode to allow your team to review parts of the system to identify improvements.
In addition to socializing project standards, code reviews allow you to publicize standard library functionality. Every team build utility libraries, or domain specific functionality. Code reviews give everyone a chance to see how they should be used, or identify areas for "coding by subtraction", by replacing code with standard, tested library calls. This allows your team to take advantage of the testing you have been performing on your libraries as well as reduce duplication.