내 회사에서 프로젝트를 진행하기 전에 상사는 내 선배에게 나와 다른 팀원이 작성한 프로그램을 검토하도록 요청하거나 때로는 상사도 검토를 위해 우리와 함께 앉아 있습니다.
지식을 얻는 좋은 방법이라고 생각하지만 때로는 프로그램이 제대로 작동하면 검토 후에도 작동하지 않으므로 프로그램을 다시 살펴 봐야합니다.
그들은 검토가 프로그램과 쿼리 실행을 최적화하는 데 도움이되지만 실제 프로그램 기능보다 최적화를 선호 할 수 있다고 말합니다.
답변
“정상 작업”은 실제로 훌륭한 척도이지만, 팀에서 유일하게 작성한 내용을 해독하여 유지할 수 있다면 코드는 중장기 적으로 가치가 없습니다.
좋은 코드는 최소한 :
- 의도 한대로 작업
- 사람이 읽을 수있는 / 명확한
- 쉽게 유지 보수 가능
- 향후 변경을 위해 쉽게 확장 가능
- 안전한
- 불필요한 의존성없이
- 명목이 아닌 경우를 올바르게 처리
- 기타
(이러한 요구 사항 중 일부는 실제로 중복되지만 개별적으로 고려하는 것이 좋습니다 …)
코드 검토는 자동 테스트를 통해 수행 할 수있는 “작업”부분을 넘어 목적을 제공합니다.
나는 개인적으로 이것이 무언가가 찢어지고 그것을 처음부터 다시 만들어야한다는 것을 귀찮게 알고 있습니다. 그러나 종종 이것은 수석 / 기술 책임자의 잘못된 통신으로 인한 것입니다. 따라서 다음 번에 너무 자주 다시 작성해야한다고 생각되면 한 줄을 작성하기 전에 검토 자에게 가서 가능한 모든 정보를 최대한 상세하게 얻으십시오. 코드 검토 자 팀이 모든 개발자가 참조 할 수있는 공식 문서로 기대치를 요약하면 좋을 수도 있습니다.
더 긍정적 인 측면에서, 세션은 훌륭한 사례 / 디자인을 공유 할 수있는 기회가 될 수도 있습니다.
답변
귀하의 질문을 “기능 코드가 더 이상 컴파일되지 않는 지점까지 검토 할 수 있습니까?” .
예, 그럴 수 있습니다. 일반적으로, 검토 중에 당신이 보는 방법 당신의 코드가 무엇을 수행합니다. 코드를 제출하고 싶을 때 프로그램의 특정 부분을 마쳤다고 말합니다.
당신은 그것이 작동한다고 말합니다. 그런 다음이를 확인하기 위해 테스트가 수행됩니다. 테스트를 통과 한 모듈이 모듈을 다시 만지지 않아야한다는 의미는 아닙니다.
작동하는 것처럼 보이는 모듈은 런타임시 또는 사용자 또는 다른 사람이 유지 보수를 수행해야하는 몇 개월 동안 발생할 수있는 재난 일 수 있습니다. 리뷰에서 코드를 변경하고 무엇이 잘못되었는지 지적함으로써, 리뷰어는 (희망스럽게) 실제로 무언가를 가르치려고합니다.
답변
동료 리뷰는 의심 할 여지없이 훌륭한 학습 방법입니다. 누군가 다른 것을 볼 수도 있고, 다른 경험을 가지고 있으며 개선에 기여할 수 있어야합니다. 이것은 혼란스러워해서는 안되며, 개발자가 누군가의 코드를 주석하고 건설적으로 비판 할 수 있기를 기대합니다!
이 “개선”중 일부는 리뷰 개발자가 저자보다 소프트웨어에 대한 경험이 적기 때문에 실제로 변경을하고있는 것처럼 들립니다.
이 추세는 자체 피드백이며 코드를 따르거나 유지하기 어려울 수 있습니까? 당신의 리뷰는 가치가 있습니까? 물론! 어떻게하면 실망 스러울 수 있는지, 동료들이 깨뜨리는 것처럼 보이는 작업 코드를 갖는 것이 마음에 들지 않아야합니다. 이러한 변경으로부터 코드를 보호하기 위해 노력해야합니다.
질문은 프로그램의 기능을 보호하는 방법이되어 검토를 마친 후에도 기능이 여전히 작동하고 있음을 알 수 있습니다. 내 제안은 괜찮은 단위 테스트 범위를 보장하는 것입니다. 그렇게하면 귀하 / 검토 자 / 후임자가 코드를 변경할 때마다 변경 사항이 안전하다는 것을 확신 할 수 있습니다.
ETA : 귀하의 의견 중 하나를 발견했습니다. 아무 말없이 진행될 것이지만 테스트 팀이 직접 검토하기 전에 코드 검토를 수행해야합니다. 그렇지 않으면 최종 제품을 테스트하지 않습니다.