불필요하다고 생각되는 코드 검토를 거부하는 방법?

존재하지 않는 문제를 해결하는 코드를 검토하라는 요청을 받았습니다.

나보다 나이가 많은 정착자는 그의 수정이 필요하다고 주장하지만 그것은 나에게 C ++ 궤변이 아닌 것 같습니다. 배포 프로세스의 일부는 코드 검토이며 소규모 회사에서 두 번째로 높은 엔지니어로서 변경 사항을 검토해야합니다.

본인은 리뷰어가 원래 코더와 마찬가지로 코드 변경에 대한 책임이 있다고 생각하며이 변경에 대한 책임을지지 않습니다. 이 검토를 거부하는 방법은 무엇입니까?

변경에 성공한 변경없이 실패한 테스트 케이스를 요청하십시오.

그가 생산할 수 없다면, 그것을 정당화로 사용하십시오.

그가 생산할 수 있다면 왜 테스트가 유효하지 않은지 설명해야합니다.

검토자는 객관적이어야합니다.

검토하기 전에 문제의 코드에 대한 의견을 작성했음을 분명히 알 수 있으며 귀하와 해결사가 위치를 파악한 것 같습니다. 그 때문에 있다면, 당신은 어려운시기에 나타나는 목표를 할거야, 그리고 훨씬 더 힘든 시간이 되는 목표. 그 중 어느 것도 프로세스에 도움이되지 않으며, 당신이 할 수있는 가장 객관적인 일이 문제에 너무 근접한 근거로 절을하는 것입니다.

팀 접근법을 고려하십시오.

자신을 제거 할 수없는 경우 다른 여러 엔지니어가 동시에 코드를 검토하도록 할 수 있습니다. 코드가 거부되거나 거부되지 않는다는 것에 동의합니다. 그들이 당신에 동의한다면, 그것은 더 이상 당신과 해결사가 될 수 없으며, 당신은 팀이 픽스를 객관적으로보고 그것을 받아들이지 않기로 결정했다는 더 강력한 사례를 만들 수있을 것입니다. 반면에 그들이 수정을 수락하기로 결정하면 팀 결정이 될 것입니다. 말할 수있는 한 열린 마음으로 참여해야하며 합리적 토론 이외의 다른 방법으로 다른 팀원의 의견에 영향을 주려고 시도해서는 안된다는 것은 말할 나위도 없습니다. 중요 사항 : 나중에 결과가 나쁘면 "Well I 항상 코드가 잘못되었다고 말했지만 다른 팀원보다 숫자가 많았습니다. "

거부는 코드 검토 프로세스의 자연스러운 부분입니다.

코드 검토 프로세스는 더 많은 노인들의 도장을 찍을 수있는 곳이 아닙니다. 코드의 품질을 보호하고 향상시킬 수 있습니다. 올바른 이유로 수정을 거부하면 아무런 문제가 없습니다. 즉, 수정으로 코드가 개선되지 않습니다. 공개적으로 코드를 검토 한 후에도이 수정으로 인해 입증 가능한 문제의 위험 및 / 또는 규모가 줄어들지 않는다고 생각되면 거부해야합니다. 개인적인 것이 아니라 정직한 의견입니다. 만약 해결사가 동의하지 않는다면, 그것도 괜찮습니다. 그리고 그 시점에서 경영진이 알아내는 것이 문제가됩니다. 정직하고 개방적이며 전문적인 태도를 유지하십시오.

책임은 두 가지 방법을 모두 삭감합니다.

당신은 문제가 있다고 믿지 않기 때문에이 변경에 대해 책임을지고 싶지 않다고 말했습니다. 그러나 틀렸고 문제 가 있는 경우 문제를 피할 수있는 코드를 거부 할 책임 이 있다는 사실을 알아야합니다 .

필기를하다.

검토 과정을 서면으로 기록하면 사실을 바로 잡는 데 도움이됩니다. 의심되는 문제 및 수정 사항 등을 측정하기 위해 실행할 수있는 테스트 결과, 설명 및 결과를 검토하는 동안 생각과 우려 사항을 기록하십시오. 위치. 나중에 문제가 다시 발생하면 (고정자가 자신의 견해에 첨부되어있을 것입니다) 기억을 뛰어 넘을 것입니다.

반대 주장에 대한 거부 및 방어 사유를 기록하십시오. 그런 다음 해결사와 합리적으로 논의하고 필요한 경우 경영진에게 이관하십시오.

충분한 문서 (코드 목록, 테스트 결과 및 객관적인 인수 포함)가 있으면 잘 다룰 것입니다.

해결사에 문제가 생길 수 있으므로 문제가 가치가 있는지 확인하십시오.

또한 수정 프로그램이 소유자와 관련이있는 경우이 답변을 잊어 버리십시오.

최근 LinkedIn 뉴스에서 오만한 것으로 보이지 않고 직장에서의 갈등 해결과 겸손에 관한 기사가있었습니다. 슬프게도, 지금은 링크를 찾을 수 없지만 일반적인 요점은 비 대립적인 방식으로 질문을 작성하는 것이 었습니다. 제발 당신이 오만하다는 것을 암시하는 것은 아닙니다. 기사가 쓰여진 방식 일뿐입니다.

어쨌든, 수석 프로그래머에게 자신의 가정이 잘못되었다고 말하면 방어 적 접근을 취하고 응답으로 당신을 다시 공격하게됩니다. 그러나 이해가 부족하다는 관점에서 문제가 존재한다고 생각하는 이유에 대해 의문을 제기하는 경우 문제를 논의하기에 더 개방적 일 수 있습니다.

따라서 "문제가 존재하지 않으므로이 문제를 검토 할 필요가 없습니다"라고 말하지 말고 "이 문제를 올바르게 검토하려면 문제를 이해해야합니다. 문제를 설명해 주시겠습니까?" 관점? "

예를 들어, 기사는 성인이 성인을 향한 얼굴을 제외하고 얼굴이 모두 한 가지 색의 입방체를 들고있는 어린이에게 실시 된 테스트를 설명했습니다. 어린이들에게 성인이보고있는 얼굴의 색을 물었을 때, 5 세 미만의 사람들은 성인이 자신과 다르게 볼 수 있다는 것을 이해할 수 없었기 때문에 거의 항상 그들이 볼 수있는 색을 말할 것입니다.

C / C ++는 정의되지 않은 동작으로 가득 차 있습니다. 한 손으로는 예상치 못한 행동으로 이어질 수 있기 때문에 나쁘다. 반면에 적극적인 최적화가 가능하며 일반적으로 C / C ++를 사용하는 경우 속도에 관심이 있습니다.

테스트 케이스 작성이 어려울 수 있습니다. 더 이상 존재하지 않는 이상한 아키텍처 또는 컴파일러가 포함될 수 있습니다. 또한 현명한 아키텍처에서는 "문제를 일으키지 않아야합니다"처럼 보일 수 있습니다 .

그러나 어느 시점에서나 플랫폼을 변경합니다 (예 : 모바일로 이동하여 ARM으로 포팅하거나 작업 속도를 높이고 GPU를 사용하려고 함). 이 시점에서 상황이 깨지기 시작하고 디버깅해야합니다. 컴파일러를 최신 버전 으로 업데이트하는 것만 큼 간단하지 않을 수 있습니다 (필요할 수도 있습니다).

문제가되는 코드는 다음과 같습니다.

int d[16];

int SATD (void)
{
   int satd = 0, dd, k;
   for (dd=d[k=0]; k<16; dd=d[++k]) {
     satd += (dd < 0 ? -dd : dd);
   }
   return satd;
 }

마지막 반복 중에 d[++k] => d[++15] => d[16]액세스됩니다. 일반적으로 다음 요소는 합법적 메모리 (C 메모리 모델이 아닌 페이징 측면에서)이기 때문에 사소한 컴파일러조차도 이상한 동작을 가진 실행 파일을 생성하지 않았습니다. 테스트 사례를 작성하는 유일한 방법은 C (아마도 VM)와 정확히 동일한 메모리 모델을 가진 플랫폼을 찾는 것입니다.

그러나 gcc 4.8 prerelase d[++k]는 모든 루프에서 실행되는 것으로 나타났습니다 . 그래서 k < 16그렇지 않으면 액세스 불법 것 및 컴파일러에 공급 프로그램의 적법성 계약의 일부입니다. 따라서 루프 조건은 가정을 고려할 때 항상 참이므로 무한 루프입니다. 이것은 이상하게 들릴 수도 있지만 완벽하게 합법적 인 최적화였습니다. 방출 system("dd if=/dev/zero of=/dev/sda"); system("format c:")은 루프를 올바르게 대체 할 것입니다. 행동을 나타 내기 위해 선택할 수있는 더 미묘한 방법이 있습니다. 예를 들어 트랜잭션 메모리 에 대한 강의 중에 발표자가 두 스레드가 동일한 값을 증가 시켰을 때 잘못된 값을 얻으려고 여러 번 시도했음을 기억합니다.

그러나 일부 언어와 달리 C / C ++는 표준화되어 있으므로 객관적인 소스를 참조하여 이러한 분쟁을 해결할 수 있습니다.

• 이것이 문제가 아니라고 생각되면 C / C ++ 표준을 사용하여 증명해보십시오 (즉, 정의 된 가치와 행동으로 이어짐)
• 만약 이것이 문제 라고 생각한다면, C / C ++ 표준을 사용하여 그것을 증명해달라고 요청하십시오 (즉, 정의되지 않은 가치 나 행동으로 이어짐)

일반적으로 팀이 C / C ++로 작성하는 경우 표준을 보유하는 것이 유용합니다. 팀 전문가조차도 가끔 이상한 점을 찾을 수 있습니다.

이는이 특정 검토보다 팀 정책에 문제가있는 것 같습니다. 9 명의 팀으로 구성된 대규모 소프트웨어 상점에서 일할 때, 평론가는 코드에 대한 거부권을 행사했으며 이는 우리 모두가 존중하는 표준이었습니다. 우리는 재능 있고 정통했습니다. 즉, viz. "성숙"하지만 "시즌"보다 "유치하지 않다"는 의미에서 팀 리더는 신중한 기간 내에 논쟁을 벌이지 않고도 합의에 도달 할 수 있다고 합리적으로 기대할 수 있습니다.

귀하의 게시물에있는 귀하의 언어에 근거하여, 귀하가 논쟁을 불러 일으킬 수있는 방식으로이 상황에 접근하는 것처럼 들린다는 경고가 표시 될 수 있습니다. 아마도 "지적 자위 행위"일 수도 있지만 아마도 그 일을 한 이유가있을 것입니다. 그러한 문제를 해결하는 더 간단한 방법을 생각해 내야 할 것입니다. 자위 행위 코드는 실제로 필요했습니다.

제출자가 자신의 코드가 문제를 해결했다는 증거를 보여 주도록합니다. 그가 시험을하고 증거를 보여줄 수 있다면, 당신은 틀린 사람이며 당신의 불평을 그만두고 그것을 처리해야합니다. 그가 자신의 주장을 뒷받침하는 증거를 보여줄 수없고 문제가 있음을 보여주고 그의 패치가 문제를 해결했다는 증거를 보여 주면 다시 보드로 보냅니다.

물론 주변에는 민감한 내부 정치가있을 수 있습니다. 그러나 이것은 내가 갈 길입니다 (선택적으로).