- 막연히 ‘하면 좋겠지?’ 라는 생각이 든다. 그런데 정말로 좋을까? 하나 마나라면? 오히려 악영향을 준다면? - 좀 더 본질을 고민해볼 필요가 있다. - 읽기 좋은 코드 - 변화에 대응하기

- 막연히 ‘하면 좋겠지?’ 라는 생각이 든다. 그런데 정말로 좋을까? 하나 마나라면? 오히려 악영향을 준다면? - 좀 더 본질을 고민해볼 필요가 있다. - 읽기 좋은 코드 - 변화에 대응하기 쉬운 코드 - 공부해야 한다. - 무엇이 읽기 좋은 코드인지, 변화에 쉽게 대응하는 코드는 무엇인지 알아야 한다. - 사실이나 논리적인 근거가 뒷받침 되지 않은 견해가 존중되어져서는 안된다. - 하급자는 상급자를 설득할 수 있어야 하고, 상급자는 하급자에게 설득당할 수 있어야 한다. - lint로 확인할 수 있는 부분은 리뷰하지 않아도 된다. - 명명법은 토론이 필요 - 기획, 디자인을 잘 따르고 있는지는 테스트 코드, QA를 통해서 확인되므로 리뷰하지 않아도 된다. - 성능 향상, 디자인 패턴, 아키텍쳐 - 이름에 걸맞는 행위를 하고 있는가? - 동작에 맞는 이름이 명명되었는가? - 아키텍쳐 - 코드 리뷰 하지 말자. - 어떤 게 잘 읽히는 코드인지, 어떻게 변화에 쉽게 대응 가능한 코드를 작성할 수 있는지 공부해야 한다. - 공부한 내용을 공유하고 논의해보는 시간을 갖는 게 리뷰에 시간을 할애하는 것보다 훨씬 나을 것 같다. - 시간이 되는대로 아키텍쳐와 관련해서 공부한 내용을 공유해주자. 그리고 작성되었던 코드를 어떻게 개선할 수 있는지 구체적인 방법을 제시하자. - 코드를 작성하는 와중에 의문이 드는 점을 옆 팀원과 상의했으면 좋겠다. 코드리뷰 시간을 따로 가지지 말고.