Code Review

Effective code reviews whithout the pain

Remembering the Purpose

Their first purpose is to make sure that the code that is being produced has sufficient quality to be released.

The second purpose is as a teaching tool to help developers learn when and how to apply techniques to improve code quality, consistency, and maintainability.

Code reviews are a proven, effective way to minimize defects.

A Matter of Approach

1. Ask questions rather than make statements.

   1. "이 라인은 표준을 따르지 않았어" 라는 말보다 "이렇게 구현한 이유는 무언가요?"

2. Avoid the "Why" questions.

   1. 직접적인 "왜 표준을 따르지 않았나요?"라는 질문 보다는 "표준을 벗어나게 구현한 이유는 무언가요?"

3. Remember to praise.

   1. Human nature is such that we want and need to be acknowledged for our successes, not just shown our faults
   2. 칭찬이 가장 좋은 선생님이다

4. Make sure you have good coding standards to reference.

   1. Code reviews find their foundation in the coding standards of the organization
   2. 개발표준을 진화시켜라

5. Make sure the discussion stays focused on the code and not the coder.

   1. You're not interested in saying the person is a bad person. Instead, you're looking to generate the best quality code possible.
   2. 코드는 미워해도 사람은 미워하지 마라.

6. Remember that there is often more than one way to approach a solution.

   1. The goal is quality, maintainable code. and follows the coding standards.
   2. 돌아가기만 한다고 좋은 코드는 아니다.

What to Do If You're a Developer

1. Remember that the code isn't you.

   1. It's your responsibility to hear past the attacking comments and focus on the learning that you can get out of the process. You need to strive to not get defensive.
   2. 코드가 나를 대변할 수는 있지만, 나는 아니다.

2. Create a checklist for yourself of the things that the code reviews tend to focus on.

   1. Run through your code with the checklist and fix whatever you find.
   2. 메모하는 습관을 지녀라.

3. Help to maintain the coding standards.

   1. Offer to add to the coding standards for things discussed that aren't in the coding standards.

When Code Reviews Aren't Face-to-Face

In a face-to-face code review you, have to think on your feet.

In some ways, it can be much more effective than a face-to-face conversation. Even if you have the ability to do meetings, you may consider moving to an off-line review to make the process better.

1. Put a summary comment at the top—and be positive.

   1. Read through everything and make a summary statement at the top of the file.
   2. This will soften comments even if harsh at times and make them more palatable.
   3. Good to say about nearly every piece of code—even if it is only that it compiles. (It is syntactically correct.)

2. Use an electronic mechanism to record the comments.

   1. PDF file or Word using Word's commenting features.
   2. 되도록이면 구체적이고 상세한 코멘트를 달면 좋겠다.

3. Make an upfront agreement that not every question needs to be responded to.

   1. Include thinking questions.
   2. Questions such as "Would it be better to implement a provider pattern here?" don't necessarily need a response.
   3. 그에게로 하여금 다시 한번 생각하게끔 화두를 던져라.

Conclusion

Code reviews are often misused and painful for everyone, but they don't have to be. Some simple steps can convert torture into teaching and improve the long-term outlook for code quality in your organization.

How About

현재의 미팅의 내용을 일부 녹음하여 개선점을 찾는 방법 --> 위험하긴 하지만 때로는 스스로를 돌아보는 개기가 될 수 있다.