경로 적용 팀에서 로봇 공학 스타트 업에서 일하고 있으며 풀 요청을 제출하면 코드가 검토됩니다.
1 년 이상 팀에 근무한 팀원은 내가 필요하다고 생각하는 것보다 훨씬 더 많은 작업을 수행 할 것을 제안하는 내 코드에 몇 가지 의견을 제시했습니다. 아니요, 저는 게으른 개발자가 아닙니다. 나는 좋은 주석, 변수 이름, 들여 쓰기가 있고 케이스를 올바르게 처리하는 우아한 코드를 좋아합니다. 그러나 그는 동의하지 않는 다른 유형의 조직을 염두에두고 있습니다.
예를 들어 보겠습니다.
나는 내가 만든 전환 발견 알고리즘으로 변경하기 위해 테스트 케이스를 작성하는 데 하루를 보냈다. 그는 내가 일어날 가능성이 거의없는 불분명 한 사건을 처리 할 것을 제안했다. 실제로는 그것이 일어날 가능성조차 확실하지 않다. 내가 만든 코드는 이미 모든 원래 테스트 사례와 내가 찾은 일부 새로운 사례에서 작동합니다. 내가 만든 코드는 이미 야간에 실행되는 300 개 이상의 시뮬레이션을 통과합니다. 그러나이 모호한 사례를 처리하려면 로봇 성능을 개선하는 데 더 많은 시간이 소요될 수 있습니다. 분명히, 지금까지 우리가 사용했던 이전 알고리즘은이 모호한 사례를 처리하지 않았으며 생성 된 40k 보고서에서 한 번도 발생하지 않았습니다. 우리는 신생 기업이며 제품을 개발해야합니다.
나는 이전에 코드 검토를 한 적이 없으며 너무 논쟁 적인지 확실하지 않습니다. 내가 조용히하고 그가하는 말을해야합니까? 나는 시간을 잘 활용한다는 것에 강력하게 동의하지 않더라도 머리를 쓰지 않고 변경하기로 결정했습니다.
나는 동료를 존중하며 그를 지능적인 프로그래머로 인정합니다. 나는 단지 그 점에 동의하지 않고 코드 검토에서 의견 불일치를 처리하는 방법을 모른다.
선택한 답변이 주니어 개발자가 코드 검토에서 의견 불일치를 처리하는 방법을 설명하는이 기준을 충족한다고 생각합니다.
답변
일어날 가능성이 거의없는 불분명 한 사례-사실 나는 그것이 일어날 가능성조차 확신하지 못한다
코드에 테스트되지 않은 동작이없는 것이 매우 중요합니다. 코드 조각을 초당 50 회 실행하는 경우 약 5.5 시간의 런타임마다 100 만 번의 기회가 발생합니다. (귀하의 경우 확률은 더 낮아 보입니다.)
당신은 당신의 관리자 (또는 당신이 일하는 부서의 상급자 인 사람)와 우선 순위에 대해 이야기 할 수 있습니다. 예를 들어 코드 성능 작업이나 방탄 코드 작업이 최우선 순위인지 여부와 그 모퉁이 사례가 얼마나 어려운지 더 잘 이해할 수 있습니다. 검토자가 우선 순위에 대한 왜곡 된 아이디어를 가질 수도 있습니다. 담당자와 이야기를 나눈 후에는 검토 자의 제안에 동의하기가 더 쉬워지고 참조 할 것이 있습니다.
검토자를 두 명 이상 보유하는 것이 좋습니다. 한 동료 만 코드를 검토하는 경우 해당 코드를 알고있는 다른 사람이나 일반적으로 코드베이스를 살펴 보도록 요청하십시오. 두 번째 의견은 다시 검토 자의 제안에보다 쉽게 동의하지 않는 데 도움이됩니다.
여러 코드 검토 중에 반복되는 주석이 여러 개 있으면 일반적으로 더 큰 내용이 명확하게 전달되지 않고 동일한 문제가 반복해서 발생합니다. 더 큰 것을 찾아서 검토 자와 직접 논의하십시오. 충분한 질문 왜 질문. 코드 검토 연습을 시작할 때 많은 도움이되었습니다.
답변
재난의 원인이 될 수없는 코너 케이스의 예를들 수 있습니다.
때 아리아 4 측면에서 값을 개발되고 있었다 가속도계 (A) 내로 맞게 조정 된 16 비트 부호있는 정수 와 가속도계의 최대 가능 출력을 스케일링 할 때, 수 있기 때문에 결코 32,767을 초과하는 초과하지 않고 최소가 있었다 절대 아래 빠지지 – 32768“범위 확인 오버 헤드가 필요하지 않습니다”. 일반적으로 모든 입력은 변환하기 전에 범위를 확인해야하지만이 경우 불가능한 코너 케이스를 잡으려고합니다.
몇 년 후 Ariane 5 가 개발되고 측면 가속도계 스케일링을위한 코드는“사용이 입증 된”최소한의 테스트로 재사용되었습니다. 불행히도 더 큰 로켓은 더 큰 측면 가속을 기대할 수 있으므로 가속도계가 업그레이드되어 더 큰 64 비트 부동 소수점 값을 생성 할 수 있습니다 .
변환 코드에 “랩”이 더 큰 값은 기억하지 아니 범위 검사를, 그리고 1996 년 첫 출시에 대한 결과는 좋지 않았다. 회사에 수백만 달러가 들었고 프로그램에 큰 어려움을 겪었습니다.
내가 만들려고 노력하고있는 점은 같은 테스트 케이스를 무시하지 말아야한다는 것입니다 결코 , 일이없는 매우 : 등, 가능성 그들은의 범위 검사를 요구 코딩 된 기준을 모두 외부 입력 값을 설정합니다. 그것이 테스트되고 처리 되었다면 재난을 피했을 수 있습니다.
참고 아리안 4에서이 버그 아니었다 (모든 가능한 모든 값에 대해 잘 작동으로) -이 표준을 준수하기 위해 실패했다. 다른 시나리오에서 코드를 재사용 할 때 코드가 크게 실패한 반면 값 범위가 잘 리면 정상적으로 실패 했을 수 있으며 테스트 케이스 가 있으면 값을 검토 할 수 있습니다. 또한 코더와 테스터가 폭발 후 수사관들로부터 비판을 받았지만 경영진, QA 및 리더십은 대부분의 책임으로 남았습니다.
설명
모든 소프트웨어가 안전에 중요하지 않거나 실패했을 때 너무 훌륭하지는 않지만, “불가능한”테스트는 여전히 가치가있을 수 있음을 강조하고자했습니다. 이것은 내가 아는 가장 극적인 경우이지만 로봇 공학은 또한 비참한 결과를 낳을 수 있습니다.
개인적으로 누군가 누군가 테스트 팀에 모퉁이 사건을 강조한 후에는이를 확인하기 위해 테스트를 실시해야한다고 말합니다. 구현 팀장 또는 프로젝트 관리자 는 발견 된 모든 오류를 해결하려고 시도하지 않지만 단점이 있음을 알고 있어야합니다. 또는 테스트가 구현하기에 너무 복잡하거나 비용이 많이 드는 경우 사용중인 추적기 및 / 또는 위험 레지스터에서 문제가 발생하여 테스트되지 않은 사례임을 분명히하기 위해 문제를 해결할 수 있습니다. 사용을 변경하기 전에 또는 부적절한 사용을 방지하십시오.
답변
이전에 처리되지 않았기 때문에 사용자의 노력 범위를 벗어납니다. 귀하 또는 귀하의 동료는이 사건을 다루는 데 가치가 있는지 관리자에게 문의 할 수 있습니다.
답변
복잡한 알고리즘을 사용하면 실제 환경에서 발생할 수있는 모든 테스트 사례를 생각했다는 것을 증명하기가 매우 어렵습니다. 실제로는 테스트 케이스가 제공되지 않기 때문에 의도적으로 테스트 케이스를 중단 한 경우 아직 생각조차하지 않은 다른 테스트 케이스가 파손 된 상태로 남아 있을 수 있습니다.
종종 발생하는 다른 효과는 추가 테스트 사례를 처리 할 때 알고리즘이 더 일반적이되며,이를 단순화하고 모든 테스트 사례에 대해보다 강력하게 만들 수있는 방법을 찾는 것 입니다. 따라서 유지 보수 및 문제 해결 시간을 절약 할 수 있습니다.
또한 야생에서 발생하는 “이것은 절대로 발생해서는 안됩니다”라는 버그가 있습니다. 알고리즘이 변경되지 않을 수도 있지만 처리되지 않은 유스 케이스에 대해 아무도 기억하지 않으면 입력이 수년 동안 변경 될 수 있기 때문입니다. 그렇기 때문에 숙련 된 개발자는 마음이 신선 할 때 이러한 종류의 일을 처리합니다. 당신이하지 않으면 나중에 물린 다시 돌아온다.
답변
이것은 기술적 질문이 아니라 비즈니스 전략 결정입니다. 제안 된 수정은 거의 발생하지 않는 매우 모호한 경우에 대한 것입니다. 장난감을 프로그래밍하거나 의료 장비 또는 무장 드론을 프로그래밍하는 경우 큰 차이가 있습니다. 드문 오작동의 결과는 매우 다릅니다.
코드 검토를 수행 할 때 드문 경우 처리에 투자 할 금액을 결정할 때 비즈니스 우선 순위에 대한 기본 이해를 적용해야합니다. 비즈니스 우선 순위를 해석 할 때 동료와 의견이 맞지 않으면 비즈니스 측면에서 누군가와 토론하고 싶을 수 있습니다.
답변
코드 검토는 순전히 코드 정확성에 관한 것이 아닙니다. 실제로, 이는 지식 공유와 팀 스타일 / 디자인 컨센서스를 만들기위한 느리지 만 꾸준한 프로세스라는 이점 아래에 있습니다.
당신이 경험하는 것처럼, “올바른”것으로 간주되는 것은 종종 논쟁의 여지가 있으며, 모든 사람들은 그것이 무엇인지에 대한 자신의 각도를 가지고 있습니다. 내 경험상 제한된 시간과주의로 인해 코드 검토가 일관되지 않을 수 있습니다. 동일한 개발자가 다른 개발자와 다른 시간에 따라 동일한 문제가 발생하거나 그렇지 않을 수 있습니다. “이 코드를 어떻게 개선 할 것인가?” 종종 자연스럽게 자신의 노력에 추가하지 않을 변화를 제안합니다.
경험이 풍부한 코더 (개발자로서 15 년 이상)로서 저보다 경험이 적은 코더들에 의해 종종 리뷰를받습니다. 때때로 그들은 저에게 약간 동의하지 않거나 중요하지 않다고 생각되는 변화를 요구합니다. 그러나 나는 여전히 그 변경을합니다. 나는 최종 결과가 제품에 약점을 초래할 수 있다고 생각 될 때, 시간 비용이 매우 높거나 “정확한”관점이 객관적으로 될 수 있다고 생각할 때만 변화에 맞서 싸운다. 사용중인 언어로 작동하지 않거나 벤치 마크에 따르면 성능이 개선 된 것은 아닙니다.
따라서 전투를 신중하게 선택하십시오. 필요하지 않다고 생각되는 테스트 케이스를 코딩하는 이틀은 싸울 시간 / 노력의 가치가 없을 것입니다. GitHub 풀 요청과 같은 검토 도구를 사용하는 경우 반대 의견을 지적하기 위해인지하는 비용 / 혜택에 대해 의견을 말하지만 여전히 작업을 수행하는 데 동의합니다. 이것은 완만 한 푸시 백으로 간주되므로 검토자가 경계를 치고 있음을 알고 더 중요한 근거를 포함하여 교착 상태에 빠질 때 이와 같은 사례를 확대 할 수 있습니다. 서면 의견 불일치가 커지는 것을 피하고 싶습니다. 업무 차이에 대한 인터넷 포럼 스타일의 논쟁을 원하지 않기 때문에 먼저 문제를 논의하고 토론 결과에 대한 공정한 요약을 기록하는 것이 도움이 될 수 있습니다.친절한 토론은 당신을 위해 결정합니다).
이벤트 후 스프린트 검토 또는 개발 팀 계획 회의 등에 유용한 주제입니다. 예를 들어 “코드 검토에서 개발자 A가이 추가 테스트 케이스를 식별했습니다. 작성하는 데 2 일이 더 걸렸습니다. 팀은 추가 비용이이 비용으로 정당화되었다고 생각합니까? ” -이 접근 방식은 실제로 작업을 수행하는 경우 훨씬 더 효과적입니다. 작업을 완료했으며 위험 회피 및 기능 개발을 위해 팀을 폴링하려고합니다.
답변
적어도 모호한 사건에 대해 주장하는 것이 좋습니다. 그렇게하면 미래의 개발자들에게 당신이이 사건에 대해 적극적으로 결정한 것을 볼 수있을뿐만 아니라 이미 실패한 핸들링이 잘되어 있다는 사실도 놀라워 질 것입니다.
그런 다음 실패를 일으키는 테스트 사례를 만듭니다. 이런 식으로 동작이 더 잘 문서화되고 단위 테스트에 표시됩니다.
이 답변은 “가능한 한 극도로 가능하지 않다”는 당신의 판단도 정확하고 우리는 그것을 판단 할 수 없다고 가정합니다. 그러나 그것이 가능하고 동료가 동의한다면, 사건에 대한 명백한 주장은 두 사람 모두에게 만족스러운 해결책이 될 것입니다.