프로그래머가 코드 검토를 처리하는 가장 좋은 방법은 무엇입니까?

저는 코드 검토를 처음 접했지만 박사 학위 과정에서 몇 년 동안 코딩을 해왔습니다. 항상 좋은 프로그래머가되는 것은 아닙니다!

검토자가 코드를 변경하고 한 줄씩 살펴보면 동의하지 않으면 어떻게합니까? 때로는 X를 선택하고 검토자가이를 Y로 변경하고 Y를 염두에두고 단점으로 인해하지 않기로 결정했지만 검토자는 이러한 단점이 중요하지 않다고 주장합니다. 의견 차이를 말로 표현해야합니까, 아니면 듣지 말아야합니까?

당신이 비판을 받아들이는 데 능숙하지 않고, 검토자가 조직의 상급자라면 어렵습니다. 너무 방어적인 태도를 취하는 것은 좋지 않습니다.

사실 방어적인 입장은 도움이되지 않습니다. 그러나 비난을 받고있는 것도 아니며, 이런 일이 발생한다고 생각되면 코드 검토가 조직 내에서 더 나은 코드를 작성하는 데 도움이되지 않는다는 우려를 표명해야합니다.

검토자는 실제 비준수 및 결함에 대한 코드를 검토 할 책임이 있으며 코드를 수행 한 방식으로 코드를 작성하는 수단으로 사용하지 않습니다. 이것은 리뷰가 당신이 어떻게 한 일을 검토하고, 실수를했거나 (우리 중 가장 좋은 일을하는) 영역 또는 표준을 이해하지 못하거나 일부 코드가 작성된 "역사적 이유"를 지적하기 위해 검토가 있음을 의미합니다. 그것이 당신이있는 곳입니다.

따라서 여러 가지 방법으로 무언가를 수행하는 경우 코드가 다른 방법으로 변경되어야하는 이유가 있어야합니다. 그렇지 않으면 단순히 비 구조적인 이탈이 도움이되지 않습니다.

또한 검토자가 완벽하지 않다는 것을 기억하십시오. 그들은 Y가 그것을 할 수있는 방법이라는 생각을 가지고있을 수 있으며 X가 더 낫다는 것을 깨닫지 못했습니다. X 방식으로 그 이유를 설명해야합니다. 검토자가 귀하에게 동의 할 수도 있고 Y가 더 나은 솔루션 인 이유를 알려줄 수도 있습니다. 다른 요인이있을 수도 있습니다.

간단히 말해, 검토는 팀 구성원이 코드 변경에 대해 알리는 방법입니다. 따라서 리뷰어와상의하십시오.

그것이 도움이된다면, 검토중인 코드의 작성자조차도 공정하지 않은 방식으로 이야기하십시오. 코드는 결국 회사 나 팀에 속하며 팀은이를 유지해야합니다. 당신은 방금 쓴 사람이되었는데, 그것은 많은 사람들이 믿는 것만 큼 중요하지 않습니다.

컴퓨터 코드 작성은 불확실한 결정을 내리는 가장 좋은 예입니다 . 항상 상충되는 압력이 있으며 주어진 질문에서 결정하는 방법은 어떤 압력을인지하고 얼마나 큰 압력을 고려하는지에 달려 있습니다.

따라서 검토자가 귀하의 결정에 동의하지 않으면 귀하와 다른 압력 / 위험을 보거나 귀하가하는 것보다 더 크거나 작은 것으로 간주합니다. 당신은 있어야합니다 절대적으로 일을하지 그래서 처음에 의견을 주도하는 문제를 영속하기 때문에, 이러한 차이에 대해 이야기.

검토자가 상급자 인 경우, 해당 경험에 따르면 이러한 위험이나 그 위험이 실제로는 관련이 없다고 올바르게 말하거나, 어떤 종류의 오류가 조직에서 오랜 역사를 가지고 있음을 알 수 있으며, 특히주의해야합니다. 그것을 피하기 위해. 반대로, 검토자가 아마 알지 못하는 것을 알고 있다고 생각한다면 반드시이를 표현해야합니다. 침묵하는 것은 당신의 의무의 제거에 달려 있습니다.

상황을 처리하는 데있어 가장 중요한 부분은 디자인 결정에 대한 비판이 사실상 항상 누군가의 성격에 대한 비판이 아님 을 이해하는 것입니다 . (실제로 드문 경우에, 당신은 곧 그 사실을 알게 될 것입니다. 그리고 누군가를 진정으로 기쁘게 할 수 없다면, 당신은 아무런 변화를 만들지 않습니다. 따라서 모범 사례를 따르는 데있어 해로운 부분은 어디입니까? 컴퓨터 코드와 관련된 많은 위험과 보상에 대한 인식이 다르고 현대 컴퓨터 코드가 얼마나 복잡한 지에 따라 다른 사람들이 예상 한 결과 일뿐입니다. 차이점에 대해 이야기하면 코드 를 개선하고이 경우와 향후의 경우 협력을 향상시키는 데 도움 이됩니다.

다른 답변에는 이미 매우 좋은 정보가 포함되어 있습니다. gbjbaanb가 암시 한 몇 가지 측면에 대해 조금 확장하고 싶습니다 (그의 답변에 대한 내 의견 참조).

내 경험상 코드 검토 중에 다른 종류의 피드백을 관찰했습니다.

1. "솔직히 말해서 이것이 잘못되었거나 차선책이라고 생각합니다. 이런 식으로 바꾸어야합니다." 나는 보통 이런 종류의 피드백을 진지하게 받아들이고, 그것에 대해 강한 지적이 있다고 생각되는 경우에만 제안 된 변경에 반대 할 것입니다.
2. "나는 당신의 해결책을 찾았습니다.이 대안을 고려하십시오. 그러나 당신이 변화를 받아 들일 것인지 아닌지는 당신에게 달려 있습니다." 나는 이런 종류의 피드백을 진지하게 받아들입니다. 검토자는 해결책이 더 낫다는 강한 의견이 없지만 대안을 제안하고 있습니다. 나는 무언가를 배울 기회가 있으며, 더 좋아지면 변화를 받아들입니다. 그렇지 않으면 리뷰어가 내 취향에 따라 코드를 유지하면 괜찮습니다.
3. "나는 그것을 다르게했을 것이다. 그래서 당신은 그것을 바꾸어야한다." 다음 작업으로 넘어 가야하므로 세부 사항을 논의 할 시간이 많지 않다는 힌트와 함께 변경에 대한 간단한 설명이 제공됩니다.
4. 검토자는 코드를 개선하지 않고 단지 다르게 만드는 사소한 자연의 작은 변화를 제안합니다. 제안 된 변경 사항에 대해 논의하라는 요청을 받으면 검토자는 소진을 포기할 때까지 사소한 세부 사항에 대해 긴 토론을합니다.

옵션 3, 4는 1과 2로 위장 할 수 있습니다. "내가 제안한대로하는 것이 정말 중요했습니다." 또는 "실제로 원하면 변경을 거부 할 수 있습니다."라고 말하면서 실제로 말하는 것과 반대의 의미로 사용됩니다. 불필요하다고 생각되는 변경에 반대하는 경우, 공유 코드 소유권은 이러한 태도를 정당화하는 데 사용될 수 있습니다. "코드는 귀하의 것이 아니며 팀의 것입니다!" 검토자가 토론에 대해 공개적이지 않고 자극을 받고 모든 비용으로 솔루션을 푸시하려고 시도하면 검토 자의 의도가 정직하지 않은시기를 알 수 있습니다. 기본적으로 그들은 이미 결정했으며 더 이상의 논의는 시간 낭비입니다.

IMO 옵션 1과 2는 정직한 검토 자의 표시로, 도움을 주려고 노력하고, 업무를 존중하면서 무언가를 가르치려고 노력하며, 또한 스스로 배우기에도 열려 있습니다. 이 시나리오에서는 리뷰어로부터 건설적인 피드백을받을 때 너무 자랑스러워하지 않습니다.

옵션 3, 4는 몇 가지 강력한 게임이 진행되고 있음을 시사합니다. 중요한 것은 내 방식이든 아니든, 두 가지를 모두 만족시키는 훌륭한 솔루션을 찾는 것이 아니라 중요합니다. 이는 검토 자의 자아와 관련이있을 수 있지만 사고 방식을 따르지 않는 코드를 이해할 수없는 경우와 관련이 있습니다. 그것들은 일반적으로 그들에게 친숙하지 않은 코드에 의해 혼란을 겪고 전체 코드베이스에 길을 가길 원합니다.

상황 3과 4가 너무 자주 발생하면 팀 작업이 매우 불쾌해질 수 있습니다. 그런 상황에서 나는 팀을 떠날 것을 고려할 것입니다.

동의하지 않을 때해야 할 일에 대한 문제를 해결하기 위해 ...

그것을 이야기하는 것은 대부분의 사람들이 이미 지적했듯이 갈 길입니다.

이미 한 번 이상 수행 한 경우, 우리가 사용하는 유용한 기술 중 하나가 여전히 일부 영역에서 의견이 일치하지 않는 경우 '그렇습니다. 리팩토링하는 것이 좋습니다.

별도의 티켓을 넣을 수 있습니까?

별도의 티켓을 사용하면 일부 장소에서 잘 알려진 끔찍한 '이동 및 이동하지 않음'모드 대신 코드를 입력 할 수 있습니다. 이는 가능한 한 적은 양을 수행하고로드를 분산시키는 민첩성과 잘 맞습니다. 때때로 yagni는 신청을 끝낼 것입니다. 때때로 제품 관리자는 클라이언트, 마감일 및 리소스에 대한 가치 측면에서 리팩터링보다 더 시급한 요구가 있다고 결정합니다.

코드 검토는 일반적으로 좋은 일이지만 내 경험으로는 새로운 코딩 가이드 라인을 사용하거나 중요한 버그를 수정하는 새로운 팀의 개발자를위한 도구로 사용하는 것이 가장 좋습니다. 따라서 오류 발생 위험이 줄어 듭니다. 검토 자보다 더 잘 알고 있다고 생각하는 경우, 제안한 솔루션이 더 나은 이유를 물어보고 해당 사안에 대한 통찰력을 주장해야합니다. 아무도 모든 것을 가장 잘 알지 못하므로 코드 검토는 두 가지 모두에게 귀중한 학습 경험이 될 수 있습니다.

코드 검토는 검토 자와 코더 모두에게 잠재적 인 문제를 포착하고 지식을 전달할 수있는 기회입니다.

코드 검토 자로서 책임은 가능한 위험 영역, 표준 관행에 대한 부적합, 개선 및 일반적으로 동일한 코드 영역에 대한 또 다른 관점을 강조하는 것입니다.

이로 인해 개발 시점의 코더 결정에 대해 논의 / 이해하지 않고 코드를 변경해서는 안됩니다.

검토자가 변경 작업을 수행하는 경우 다른 사람에게 작업을 위임하는 데 어려움이있을 수 있으며, 이는 많은 똑똑한 사람들이 수행하기가 어렵습니다.

검토를받는 코더는 배포시 발생 가능한 문제로부터 보호 받고 새로운 것을 배울 수있는 기회와 검토 자와 지식을 공유 할 수있는 기회를 얻게됩니다.

선임에 관계없이 당신의 사고 방식은 일부 사람들에게는 일어나지 않는 해결책을 내놓을 수 있으므로, 당신이 옳다고 믿는 것을 행함으로써 검토가 빛을 발할 수 있습니다.

코더와 검토자가 둘 다 잘못 될 수 있음을 인정하고 잘못되었다는 것을 인정하는 한, 검토는 솔루션에서 함께 작업하기 때문에 팀을 강화시키는 무언가가됩니다.

아직 코드를 검토하지 않은 것 같습니다 :-)

코드 검토의 목표는 적절한 품질의 코드를 얻고 적절한 품질의 코드를 가지고 있음을 아는 것입니다. 경험이없는 개발자의 코드를 검토 할 때 개발자를 실망시키지 않으면 서 더 나은 코드를 작성하는 방법을 가르치는 데 사용할 수 있습니다.

검토자는 코드를 변경 해서는 안됩니다 . 코드 변경 방법에 대해 어느 정도 강력한 제안을 할 수 있으며 코드 수락 여부를 결정할 수 있습니다.

검토가 올바르게 진행되면 / 코드를 검토하면 얻을 수있는 것은 내가 배울 수 있거나 무시할 수있는 코드를 작성하는 방법에 대한 의견입니다. 이의. 내 영역에서는 함수, 변수 등의 올바른 이름 지정이 중요하므로 이름 지정을 개선하기위한 제안을 얻을 수 있습니다. 일반적으로이 경우 변경해야합니다 (때로는 더 나은 이름을 찾아서). 때때로 나는 버그를 발견 할 것이다. 당신은 그들을 고칩니다. 때때로 나는 내가 버그 인 것을 찾아 내고 틀렸다. 코드가 올바른지 확인하기 어려운 경우보다 정확한 코드를 작성하십시오. 방금 틀렸다면 말해줘

디자인이 일반적으로 옳지 않다고 생각한다면, 이전에 논의 했어야합니다. 그런 다음 변경 작업에 소요되는 작업의 양을 고려하여 디자인이 충분히 좋은지 또는 내가 잘못하고 디자인이 더 나은지 고려해야합니다. 우리는 합의로 끝나야합니다.

검토 자와 검토자가 동의 할 수 없으면 문제가있는 것입니다. 그것은 우리 중 하나가 팀워크를 할 수 없거나 우리 중 하나가 좋은 디자인과 나쁜 디자인 또는 둘 다를 구별 할 수 없다는 것을 의미하기 때문입니다. 이것은 반드시 당신의 잘못이 아닙니다. 불행히도 선임적이고 우둔한 개발자가 있으며 이는 회사와 사용자에게 문제가 될 것입니다.

이런 일이 발생하면 매우 열심히 생각하십시오. 근거가 분명한 비판을 받아들이는 데 문제가 있습니까? 이 경우 태도를 바꿔야합니다. 리뷰어가 왜 옳은지 알기에는 너무 경험이 없습니까? 이 경우에는 문제가 없습니다. 검토자를 신뢰하고 배우십시오. 리뷰어보다 더 잘 알고 있습니까? 검토를 수락하되 신뢰할 수있는 세 번째 개발자에게 자신의 의견을 물어보십시오. 자신을 확신하고 옳을 수는 있지만 자신을 확신하고 잘못을 저지를 수도 있습니다.