PHP application development process often suffers from ineffective code reviews. Why? One of the main reasons why code review can get off track proves to be the participants’ attitude to this procedure as if it was intended to demonstrate who the best programmer out there is. Instead of holding mental matches, the developers whose code is reviewed should assume a learning approach to this activity and take their code’s review as a counsel and chance for improvement.
If you are the person in charge for reviewing somebody’s code, your major challenge must be creating an open and educational character of this process for that other person.
Consider the 6 following things you should always remember to ensure your code review approach is developer-friendly.
- Questions Over Statements
Statements often sound accusatory. Pointing at the developer’s failure to follow the standard, for instance, may seem like an attack while asking about the reasoning of the used approach is like seeking more information. If asked not in a condescending or sarcastic tone, this can persuade the developer to state his thinking and then admit there was some better way.
- No ‘Whys’
Though too difficult at times, trying to exclude the “Why” questions from your review can improve the developer’s mood greatly. It makes sense to paraphrase these questions to avoid an accusatory tone just as well.
- Need for Praise
Human nature needs the acknowledgement of personal success by others, not just pointing out the faults. Since PHP development or any other is creative activity developers put their soul into, there’s no surprise they take their code’s review so close to the heart which makes praise even more valuable.
- Coding Standards As Reference
The foundation of code reviews is in the company’s coding standards. These standards are the shared agreement the developers have to produce high-quality and maintainable code. When you’re having discussion over an item missing from your coding standards, there’s some work for you to do in order to get that item in your coding standards.
- Focus on Code
Focusing on the employee’s code rather than on the employee himself keeps the procedure from getting personal. In this way your remarks will signify your efforts to help the developer to generate more quality code than demonstrate he’s not good enough.
- Alternative Solutions
Remember there are cases when the developer has coded something in a different way and this doesn’t necessarily mean he’s wrong. Your common goal is quality and maintainable code. If the developer met this goal and followed your standards, there’s nothing more you can demand.
Code reviews are frequently misused and painful, but they mustn’t be like this if you want them work. Use the simple steps above to turn torture into teaching as well as improve your company’s long-term approach to code quality.