코드 검토가 너무 어려울 때 어떻게합니까?

많은 코드 검토가 상당히 일상적입니다. 그러나 때때로 기존의 복잡하고 취약한 코드에 크게 영향을 미치는 변경 사항이 있습니다. 이 경우 변경의 안전성, 회귀 부재 등을 확인하는 데 걸리는 시간이 너무 깁니다. 아마도 개발 자체를 수행하는 데 걸리는 시간을 초과했을 수도 있습니다.

이 상황에서 어떻게해야합니까? 병합하고 아무 것도 미끄러지지 않기를 바랍니다. (권장하지 않음!) 최선의 방법은 명백한 결함을 발견하려고 노력할 것입니다 (아마도 이것이 코드 검토가 목표로해야하는 가장 많은 코드일까요?) 코드 검토보다 더 나은 대안으로 완전히 병합하고 테스트합니까?

이것은 코드 검토의 일부로 테스트를 수행해야하는지에 대한 질문이 아닙니다. 이것은 설명 된 상황에서 가장 좋은 옵션이 무엇인지 묻는 질문입니다. 특히 마감 기한이 지났거나 포괄적 인 단위 테스트 세트가 없거나 변경된 조각 코드에 대해 단위 테스트를 실행할 수 없습니다.

편집 : 나는 지금까지 몇 가지 답변 / 의견이 "광범위한 영향"이라는 문구에서 선택되었다는 인상을 받았으며 변경 사항이 많은 코드 줄과 관련이 있음을 의미했습니다. 나는 이것이 해석이라는 것을 이해할 수 있지만 실제로는 내 의도가 아니었다. "광범위한 영향"이란 예를 들어 코드베이스의 상호 연결성 또는 녹온 효과의 범위 때문에 회귀 가능성이 높다는 것을 의미합니다. 반드시 변경 자체가 큰 것은 아닙니다. 예를 들어, 개발자는 기존의 높은 수준의 루틴을 호출하여 여러 개의 낮은 수준의 루틴에 대한 호출을 캐스케이드하여 단일 라인으로 버그를 수정하는 방법을 찾을 수 있습니다. 버그 수정이 효과가 있는지 테스트하고 확인하는 것은 쉽습니다. 코드 검토를 통해 수동으로 모든 노크 효과의 영향을 확인하는 것이 훨씬 더 어렵습니다.

이 질문의 전제는 솔직히 놀랍습니다. 취약하고 복잡한 코드에는 큰 변화가 있으며 코드를 제대로 검토 할 시간이 충분하지 않다고 가정합니다 . 이것은 검토에 더 적은 시간을 소비해야하는 마지막 코드입니다 ! 이 질문은 코드 자체뿐만 아니라 변경 관리 방법에 구조적 문제가 있음을 나타냅니다.

이 상황을 어떻게 처리할까요? 처음에는 들어 가지 않는 것으로 시작하십시오.

• 복잡성의 원인을 파악하고 신중하게 검토 한 정확한 리팩토링을 적용하여 추상화 수준을 높입니다. 비즈니스 영역에 대해 알고있는 신입 직원이 코드를 이해할 수 있어야합니다.

• 취약성의 원인을 식별하십시오. 이것은 코드 자체의 검토, 코드의 버그 수정 이력 검사 등을 통해 가능합니다. 취약한 서브 시스템을 결정 하고보다 강력하게 만드십시오 . 디버깅 로직을 추가하십시오. 어설 션을 추가하십시오. 동일한 알고리즘을 느리지 만 정확하게 구현하고 디버그 빌드에서 두 가지를 모두 실행하고 동의하는지 확인하십시오. 디버그 빌드에서 드문 상황이 더 자주 발생합니다. (예를 들어, 항상 재할 당시 블록을 이동하거나 페이지 끝에서 항상 블록을 할당하는 메모리 할당자를 만드십시오 .) 컨텍스트가 변경 될 때 코드를 강력하게 만드십시오. 이제 더 이상 깨지기 쉬운 코드가 없습니다. 이제 버그를 일으키는 것이 아니라 버그를 찾는 코드가 있습니다.

• 자동화 된 테스트 모음을 작성하십시오. 명백하게.

• 크게 변경하지 마십시오. 일련의 작고 대상이 지정된 변경 사항을 작성하십시오. 각 변경 사항은 정확합니다.

그러나 근본적으로, 당신의 시나리오는 "우리는 기술 부채의 구멍에 파고 들었고, 각각의 복잡하고 검토되지 않은 변화는 우리를 더 깊이 파고 듭니다. 어떻게해야합니까?" 당신은 그 구멍에 자신을 찾을 때 무엇을합니까? 파고 그만 . 채무가 너무 많아서 서로의 코드를 검토하는 것과 같은 기본 작업을 수행 할 수없는 경우 더 많은 채무를 중단하고 상환하는 데 시간을 소비해야합니다.

코드 검토의 기본 목표 중 하나는 품질 을 높이고 강력한 코드를 제공하는 것 입니다. 4 개의 시선이 일반적으로 2보다 더 많은 문제를 발견하기 때문에 강력합니다. 추가 코드를 작성하지 않은 검토자는 잠재적으로 잘못된 가정에 도전 할 가능성이 높습니다.

동료 검토를 피하면 코드의 취약성이 증가하는 데 기여할 수 있습니다. 물론 견고하고 반복 가능한 테스트 스위트로 테스트를 강화하면 품질이 확실히 향상 될 수 있습니다. 그러나 대체 검토가 아닌 동료 검토를 보완해야합니다 .

복잡성을 이해하고 숙달해야한다고 생각하며 전체 동료 검토는 지식을 공유 하고이를 달성 하는 기회 입니다. 취약한 코드의 강점과 약점을 더 많은 사람들이 이해하도록하는 데 투자하면 시간이 지남에 따라 더 나은 코드를 만드는 데 도움이됩니다.

결론 :

"빨리 가고 싶다면 혼자 가십시오. 멀리 가고 싶다면 같이 가십시오"

레거시 소프트웨어 개발의 세계에 오신 것을 환영합니다.

코드는 수십만, 수백만, 수천만 줄이 있습니다.

이러한 코드 라인은 가치가 있으며, 이는 수입원을 창출하고이를 대체하는 것은 불가능합니다.

귀하의 비즈니스 모델은 해당 코드 기반을 활용합니다. 따라서 팀 규모가 작고 코드 기반이 큽니다. 사람들이 새로운 버전의 코드를 구매하거나 기존 고객을 행복하게하려면 기능을 추가해야합니다.

완벽한 세계에서 거대한 코드 기반은 wazoo에서 단위 테스트되었습니다. 당신은 완벽한 세상에 살고 있지 않습니다.

덜 완벽한 세상에서는 기술 부채를 고칠 예산이 있습니다. 코드를 단위 테스트 가능한 부분으로 나누고, 광범위한 통합 테스트를 수행하고 반복하십시오.

그러나 이것은 새로운 기능을 생성하지 않고 부채를 상환하고 있습니다. "업그레이드 인센티브를 생성하기 위해 코드를 수정하면서 기존 코드의 수익을 거두는"비즈니스 사례와 일치하지 않습니다.

엄청난 양의 코드를 가져와 더 현대적인 기술을 사용하여 다시 작성할 수 있습니다. 그러나 기존 코드와 상호 작용할 때마다 가능한 브레이크 포인트가 노출됩니다. 시스템에서 해킹하면 다시 작성하지 않은 하위 시스템의 단점을 실제로 보상합니다. 항상.

할 수 있는 것은 신중하게 행동하는 것입니다. 실제로 이해하고 나머지 시스템과의 동작 및 상호 작용을 잘 이해하는 코드의 일부를 찾을 수 있습니다. 단위 테스트를 추가하고 동작을보다 명확하게 만들어 현대화 할 수 있습니다.

그런 다음 주로 앱과 상호 작용하는 나머지 앱 부분을 찾아 한 번에 하나씩 공격하십시오.

그렇게하면 고객이 지불하고자하는 기능을 추가하여 서브 시스템을 개선 할 수 있습니다.

요컨대 이것은 비즈니스 사례를 제공하는 것을 깨뜨리지 않고 변경하는 것이 가능한 기술입니다.

그러나 이것은 당신의 질문이 아닙니다. 귀하의 질문은 "거대한 일을하고 있고 물건을 부러 뜨릴 수있는 일을하고 있으며 모범 사례를 어떻게 따르나요?"입니다.

큰 일을 할 때, 안정적으로하고 싶다면 버그를 추적하고 작성하는 것보다 더 많은 노력을 기울이는 것이 사실입니다. 이것은 소프트웨어 개발의 일반적인 규칙입니다. 물건을 작성하는 것은 쉽고, 완벽하게 작동하는 것은 어렵습니다.

당신은 아마도이 거대한 변화가 진행될 것이라고 이해 관계자들에게 약속 한 비즈니스 사례를 머리에 걸었을 것입니다. 그리고 그것은 "완료"입니다. "좋아요"

권한과 예산이 있다면 실제로 변경 사항이 적용되었다는 확신을 가지도록 노력하거나 변경 사항을 거부하십시오. 이것은 친절하지 않고 정도의 문제가 될 것입니다.

그다지 힘이 없지만 여전히 약간의 힘이 있다면, 새로운 시스템 이 단위 테스트 가능 하다고 주장하십시오 . 일부 서브 시스템을 다시 작성하는 경우 새 서브 시스템은 올바르게 지정된 동작과 그에 대한 단위 테스트를 가진 작은 부품으로 구성되어야합니다.

그렇다면 최악의 경우가 있습니다. 당신은 빚에 깊이 들어가 있습니다. 현재 기능을 사용하기 위해 취약하고 더 많은 코드를 사용하여 프로그램의 미래에 대항하여 결과를 손상 시킵니다. 스윕 기반 QA를 수행하여 최악의 문제를 찾고 나머지는 무시합니다. 이것은 현재 가장 저렴하기 때문에 실제로 비즈니스 관점에서 정답입니다. 이익을 창출하기 위해 부채로 들어가는 것은 유효한 사업 전략입니다. 특히 파산을 통해 부채를 청산하는 것이 (코드 중단) 표에 있습니다.

큰 문제는 회사 소유자의 인센티브가 의사 결정자와 프로그래머와 거의 일치하지 않는다는 것입니다. '납품'해야하는 압력이 많이있는 경향이 있으며, 거의 보이지 않는 (상사에게) 기술 부채를 발생시킴으로써 그렇게하는 것은 단기적이고 때로는 중기적인 전략입니다. 모든 부채를 만들지 않으면 서 상사 / 이해 관계자에게 최상의 서비스를 제공 할 수 있습니다 .

코드 검토가 너무 어려워지는 더 큰 문제를 해결하십시오.

내가 지금까지 발견 한 것들 :

1. 단위 테스트 스위트 없음
2. 보다 합리적인 코드 구조와 코딩 업무 위임으로 피할 수있는 복잡한 코드 병합
3. 초보 아키텍처의 명백한 부족

1. 코드 검토를 다시 보내 개발자에게 더 작고 점진적인 변경 세트로 나누고 더 작은 코드 검토를 제출하도록 개발자에게 지시 할 수 있습니다.

2. 코드의 모든 세부 사항을 거치지 않고도 코드 냄새, 패턴 및 안티 패턴, 코드 형식 표준, SOLID 원칙 등을 계속 확인할 수 있습니다.

3. 전체 변경 집합의 전체적인 의도를 반드시 이해하지 않고도 적절한 수준의 올바른 입력 유효성 검사, 잠금 / 스레드 관리, 처리되지 않은 예외 등을 세부적으로 파악하기 위해 전술 코드 검사를 수행 할 수 있습니다.

4. 코드에 의해 영향을받을 수있는 전반적인 위험 영역에 대한 평가를 제공하고 개발자에게 이러한 위험 영역이 단위 테스트되었는지 확인하도록 요청하거나 자동화 된 단위 테스트를 작성하도록 요청하고 검토를 위해 제출할 수도 있습니다. ).

이 경우 변경의 안전성, 회귀 부재 등을 확인하는 데 걸리는 시간이 너무 깁니다.

코드 검토는 주로 정확성을 목표로하지 않아야합니다. 코드 가독성, 유지 보수성 및 팀 표준 준수를 향상시키기 위해 여기에 있습니다.

코드 검토 중 정확성 버그를 찾는 것은 버그의 부산물이지만 개발자는 검토를 위해 코드 를 제출하기 전에 코드가 완벽하게 작동하는지 (비 회귀 포함) 확인해야합니다 .

처음부터 정확성을 갖추어야합니다. 한 명의 개발자가이를 달성 할 수없는 경우 프로그램을 구성하거나 전체 팀과 계획을 세우도록하지만 나중에이를 추가 할 수있는 것으로 취급하지 마십시오.

코드 검토가 너무 어렵다고 생각하면 깨지지 않고 변경하기 어려운 취성 코드를 변경했기 때문에 문제가 있습니다. 그러나 문제는 코드 검토와 관련이 없습니다. 취성 코드는 단위 테스트 할 수 없기 때문에 단위 테스트에는 문제가 없습니다! 코드가 단위 테스트 가능하다면 코드는 독립적 인 작은 단위로 나뉘어져 있고, 각각 테스트 할 수 있고, 잘 작동하며, 이것이 당신이 가지고 있지 않은 것입니다!

그래서 당신은 쓰레기 코드 (일명 "기술 부채")가 있습니다. 당신이 할 수있는 최악의 일은 쓰레기 코드의 힙을 수정하기 시작하고 더 큰 쓰레기 코드 힙을 얻을 수 있기 때문에 작업을 끝내지 않는 것입니다. 그래서 첫 번째 것은 당신의 관리가 고정으로 구입하는 얻는 것입니다 및 작업을 완료 할 수 있습니다. 또는 당신은하지 않습니다. 이 경우에는 손대지 마십시오.

그것을 고치면 코드에서 하나의 단위를 추출하여 잘 정의되고 잘 문서화 된 동작으로 만들고, 해당 단위에 대한 단위 테스트를 작성하고, 코드를 검토하고, 아무것도 깨지지 않도록기도하십시오. 그런 다음 다음 장치와 동일하게 수행합니다.

까다로운 비트는 버그가 발생할 때 발생합니다. 쥐의 코드 네스트는 어떤 경우에는 잘못된 일을 할 것입니다. 일이 너무 부서지기 쉽고 복잡하기 때문에 일이 잘못 될 것입니다. 단위를 추출하면 나머지 코드가 더 명확 해집니다. (일부 리팩토링 후에 함수가 "if (condition1 && condition2 && condition3) crash ();"로 시작한 경우가 있었는데, 이는 리팩토링 전의 동작과 정확히 같았습니다. 이상하고 원치 않는 행동을 명확하게 수정하면 문제를 해결할 수 있습니다. 반면 에, 기존 코드의 동작을 변경 해야 하므로주의해서 수행해야합니다.

불행히도, 다른 커피 한 잔을 얻는 것 외에 코드 검토 시점에서 할 수있는 일은별로 없습니다. 이 문제에 대한 실제 해결책은 축적 된 기술 부채, 즉 깨지기 쉬운 디자인, 테스트 부족을 해결하는 것입니다. 바라건대, 적어도 일종의 기능적 QA가 있기를 바랍니다. 당신이 그것을 가지고 있지 않으면 항상 닭 뼈를기도합니다.

당신이 버그 / 비 기능 소프트웨어와 함께 제공하고 나중에 수정 만족하지 않은 경우, V & V 노력은 해야한다 개발 노력보다 더 길어질 수 있습니다!

기존 코드가 깨지기 쉬운 경우 첫 번째 질문은 "변경해야합니까?"입니다. 경영진은이 코드를 재 설계하고 재 구축하는 데 드는 비용 / 리스크가 쓰레기 더미를 고치는 데 드는 비용 / 리스크보다 큰지 여부를 문의해야합니다. 일회성이라면 그냥 패치하는 것이 더 쉬울 수 있습니다. 미래에 더 많은 변화가 필요할 것으로 예상되는 경우, 앞으로 더 많은 고통을 피하기 위해 지금 당장 히트를 취하는 것이 더 나은 결정일 수 있습니다. 당신은 당신의 관리자에게 좋은 정보를 제공하는 것이 작업의 일부이기 때문에, 당신의 관리와이 문제를 제기해야합니다. 그들은 당신의 책임 수준보다 높은 전략적 결정이기 때문에 결정을 내려야합니다.

내 경험상 문제의 시스템을 변경하기 전에 단위 및 통합 모두에 대해 상당한 양의 테스트로 코드를 다루는 것이 좋습니다. 요즘에는 그 목적을 위해 매우 많은 도구가 있으며 개발중인 언어와는 상관이 없다는 것을 기억하는 것이 중요합니다.

또한 통합 테스트를 작성하기위한 모든 도구의 도구가 있습니다. 예, 컨테이너와 특히 Docker 및 Docker Compose에 대해 이야기 하고 있습니다. 인프라 (데이터베이스, mongodb, 대기열 서버 등) 및 응용 프로그램으로 복잡한 응용 프로그램 환경을 신속하게 설정할 수있는 방법을 아름답게 제공합니다.

도구를 사용할 수 있습니다. 사용하십시오! :)

아직 언급되지 않은 이유는 모르겠지만이 두 가지가 가장 중요한 부분입니다.

• 변경 목록을 여러 개의 작은 변경 목록으로 분할 한 다음 차례로 검토합니다. *
• 변경 목록을 검토 한 후에도 변경 목록이 양호하다고 판단되지 않으면 변경을 분명히 거부합니다.

* 예 : 라이브러리 A를 라이브러리 B로 교체합니다. 하나의 변경 목록은 라이브러리 B를 소개하고, 다양한 변경 목록은 A를 B 단위로 사용하는 것을 대체합니다 (예 : 모듈 당 하나의 변경 목록). 마지막 변경 목록은 라이브러리 A를 삭제합니다.

최선의 방법으로 명백한 결함을 발견하려고 시도하십시오 (아마도 이것이 코드 검토가 목표로 삼아야 할 가장 많은 코드 일 것입니다)?

코드 개정의 잠재적 가치를 과소 평가하지 마십시오. 버그를 잘 감지 할 수 있습니다.

• 테스트를 통해 감지하기 어려운 버그 찾기
• 테스트를 통해 식별 / 수정하기 어려운 버그 찾기

다른 이유로도 유용합니다.

• 팀원 간 교육 지원
• 코드가 다른 품질 메트릭을 충족하는지 확인하는 데 도움이됩니다 (예 : 코드가 이해 가능하고 유지 보수 가능하며 버그가 없음)

이 상황에서 어떻게해야합니까?

가장 좋은 / 이상적인 경우, 코드 검사를 통과한다는 것은 "명백한 버그 없음"을 의미하는 것이 아니라 "명확하게 버그가 없음"을 의미합니다 (물론 테스트하고 싶음).

코드 검사를 통해 새 코드 기반을 확인할 수 없으면보다 광범위한 "블랙 박스"테스트가 필요합니다. 검사를 통과 한 후 코드를 생산에 투입하는 개발주기에 익숙 할 수 있지만 "검사를 통과"할 수없는 경우 "생산에 투입"할 수 없으며 더 긴주기가 필요합니다. 예 : 통합 테스트 시스템 테스트, 알파 테스트, 승인 테스트, 베타 테스트 등

사용 가능한 포괄적 인 단위 테스트 세트 또는 변경된 조각화 된 코드에 대해 단위 테스트를 실행할 수 없음

통합, 시스템 및 승인 테스트는 어떻습니까?

어쨌든 프로젝트 관리자와 제품 관리자에게 알 수없는 버그로 코드가 거의 버그가 있음을 알려야합니다. "예상 한 것"을 얻는 대신 "검사 한 것"을 얻을 것입니다. 즉, 코드 품질이 테스트보다 나쁘지 않습니다 (코드 품질이 코드 검사에 의해 보장되지 않았고 보장 할 수 없기 때문에) .

이 메시지를 고객이나 사용자에게 전달할 수 있으므로 베타 테스트를 수행하거나 (일찍 채택자가된다면) 새 버전이 베타 버전이 아닐 때까지 (이전 버전이 아닌 경우) 이전 버전을 사용해야합니다.

적절한 코드 검토없이 많은 코드가 작성되고 병합됩니다. 작동 할 수 있습니다. 그것이 "악성 코드" 가 아니라 코드 냄새 라고 불리는 이유가 있습니다 . 코드 검토가 부족하다는 것은 경고의 표시이며 운명의 선구자가 아닙니다.

이 문제에 대한 해결책은 StackExchange 스타일 답변에 포함시킬 수있는 모든 경우에 맞는 솔루션이 없다는 것입니다. 코드 검토가 중요한 "모범 사례"라는 것은 소프트웨어 개발 커뮤니티의 강력한 합의입니다.이 경우에는 건너 뜁니다. "모든 모범 사례를 따르는"좁은 채널에 더 이상 개발이 없습니다. 자신의 길을 찾아야합니다.

어쨌든 "모범 사례"란 무엇입니까? 바로 내려 가면 사람들이 일반적으로 코드를 더 잘 만든다고 생각하는 관행입니다. 그들은 코드를 올바르게 작성합니까? 안돼! 인터넷에는 "모범 사례"를 따랐던 회사의 이야기가 흩어져 있습니다. 아마도 "모범 사례"에 대한 더 나은 관점은 이들이 소프트웨어 세계의 "화재와 잊어 버린"솔루션이라는 것입니다. 회사, 프로젝트, 팀에 대해 전혀 알 수 없으며 "모범 사례"를 도움이 될만한 것들로 그만 둘 수 있습니다. 그것들은 일반적인 "해를 끼치 지 마십시오"조언입니다.

이 계획에서 분명히 벗어났습니다. 다행히도, 당신은 그것을 인식합니다. 잘 했어! 그들은 지식은 반전이라고 말한다. 그렇다면 인식은 절반 이상입니다! 이제 해결책이 필요합니다. 설명을 통해 현재 비즈니스 환경이 "코드 검토를 수행하고 모범 사례"라는 지루한 조언이 그것을 삭감하지 않을 정도로 진화 한 것은 분명합니다. 이를 위해 소프트웨어 모범 사례와 관련하여 사용하는 주요 규칙을 권장합니다.

비즈니스 요구를 능가하는 소프트웨어 개발 모범 사례는 없습니다.

솔직히, 그들은 당신의 월급을 지불하고 있으며, 비즈니스의 생존은 일반적으로 소프트웨어의 품질보다 훨씬 중요합니다. 우리는 그것을 인정하고 싶지 않지만 완벽하게 작성된 소프트웨어를 유지하려는 노력으로 죽어 회사의 몸에 갇혀 있으면 완벽하게 작성된 소프트웨어는 쓸모가 없습니다.

그래서 어디로 가니? 힘의 흔적을 따르십시오. 알 수없는 이유로 인해 일부 작업에 대해 코드 검토를받는 것은 무리가 있다고 지적했습니다. 내 경험상 그 이유는 항상 일시적입니다. 항상 "시간이 충분하지 않습니다"또는 "시간을 보내는 동안 급여를 계속 유지할만큼 돈이 부족합니다." 이것은 사업이다. 괜찮아. 쉬웠다면 누구나 할 것입니다. 코드 검토가 선택 사항이 아닌 이유 를 이해하는 데 도움이되는 관리를 찾으십시오 . 언어는 어렵고, 종종 법령이 고위 경영진을 속여서 왜곡 될 수 있습니다. 문제에 대한 해결책이 그 왜곡에 숨겨져있을 수 있습니다.

이에 대한 답은 반드시 특정 사례 시나리오입니다. 동전 던지기가 머리인지 꼬리인지를 예측하는 것과 비슷합니다. 모범 사례에서는 100 번 뒤집기를하고 머리는 대략 50 머리, 꼬리는 50 번이지만, 1 번 뒤집을 시간은 없습니다. 여기에서 상황에 대한 세부 사항이 중요합니다. 동전이 일반적으로 시간의 약 51 %에서 던져진 것과 같은 방향으로 착륙한다는 것을 알고 있습니까? 동전을 던지기 전에 어떤 방식으로 시간을 보냈습니까? 차이를 만들 수 있습니다.

사용 가능한 일반적인 솔루션 중 하나는 코드 검토 프로세스를 작성하고 비용을 절감 할 수있는 방법을 찾는 것입니다. 코드 검토 프로세스의 많은 비용은 모든 사용자가 코드 검토에 100 % 헌신하는 것입니다. 일단 코드 검토가 완료되면 코드가 축복되기 때문에 이는 사실입니다. 아마도 코드를 다른 브랜치에 넣고 메인 트렁크의 개발과 병행하여 코드 검토를 수행 할 수 있습니다. 또는 소프트웨어가 테스트를 수행하도록 설정할 수도 있습니다. 고객이 이전과 병렬로 "새로운"코드를 실행하고 결과를 비교할 수있는 비즈니스 환경에있을 수 있습니다. 이를 통해 고객은 다양한 사용 사례 작성 장치로 전환됩니다.

이러한 "어쩌면"실행의 핵심은 코드를 쉽게 조각화하기 위해 노력해야한다는 것입니다. 덜 중요한 프로젝트에서 공식 코드 검토에 의존하지 않고 코드 조각을 "증명"할 수 있습니다. 변경 사항의 합계가 너무 커서 동료 검토에 비해 변경 사항이 더 작은 경우이 작업을 수행하는 것이 더 쉽습니다.

일반적으로 프로젝트, 회사, 팀에 특정한 솔루션을 찾으십시오. 일반적인 목적의 대답은 "모범 사례"였습니다. 당신은 그것들을 사용하지 않기 때문에 이번에는이 문제에 대한 더 맞춤형 맞춤형 솔루션을 찾아야합니다. 이것은 사업이다. 모든 것이 예상대로 진행된다면 IPO는 값을 할당하기가 훨씬 쉬울 것입니다.

코드 검토를 교체하는 것이 어려운 경우 코드 검토에서 작동하는 것으로 입증 된 단일 코드가 없었 음을 기억하십시오. * 모든 코드 검토는 코드에 대한 자신감과 수정을 할 수있는 기회를 제공합니다. 그들이 문제가되기 전에 이러한 코드 검토의 귀중한 제품은 모두 다른 방법으로 얻을 수 있습니다. 코드 검토는 특히 그것을 능숙하게 인정받는 가치가 있습니다.

* 거의, L4 마이크로 커널은 자동 증거 시스템에 의해 코드 검토를 거쳤으며, 이는 해당 C ++ 컴파일러에 의해 컴파일 된 코드가 문서의 기능을 정확하게 수행 할 수 있음을 증명합니다.

@EricLippert 그의 훌륭한 대답에서 지적한 것처럼, 변화 이런 종류의 필요가 더 관심을하지 이하 . 작업중인 변경 사항이 그러한 변경 사항이 될 것임을 알고 있다면 다음과 같은 몇 가지 전략이 도움이 될 수 있습니다.

• 버전 관리를 자주 수행하십시오. 커밋별로 검토가 진행될 수 있으며 커밋이 작을수록 이해하기 쉽습니다.
• 각 변경 사유를 가능한 한 명확하게 설명하십시오.
• 만일 그럴듯하다면, 이런 종류의 변화에 ​​페어 프로그래밍을 사용하십시오. 2가 아닌 문제에 대해 세 가지 눈을 갖는 것은 일반적으로 놓칠 수있는 문제를 피하는 데 도움이 될 수 있으며 작업하는 동안 한 쌍을 갖는 것은 분명 하다고 생각 했지만 덜 분명한 코드에 대한 주석을 개선하는 데 도움 이 될 수 있습니다 당신이 생각한 것보다 나중에 검토자를 도울 것입니다. (a) 개발 중 오류 감소 및 (b) 개선 된 문서의 도움은 실제로 더 많은 사람들이 참여하더라도이 작업에 소요되는 인력 시간이 줄어드는 것을 의미 할 수 있습니다.

이 시점에 도달 한 방법에 대해 더 많은 답변이 있습니다. 그들 중 많은 사람들이 상황을 해결하기 위해 몇 가지 제안을하지만 짧은 대답을하기 위해 내 대답을 던지고 싶습니다.

코드 검토가 "너무 어려울 때"어떻게해야합니까?

1. 메인 라인 코드 브랜치로 돌아 가기
2. 리팩토링 한 기능에 대한 테스트 작성 (예 : 기능 테스트)
3. 통과 할 테스트 받기
4. 테스트하기 어려운 코드로 테스트를 병합
5. 테스트가 여전히 통과합니까?

예

당신은 개발자가 훌륭했습니다! 모두를위한 고양이 귀환!

(또는 미국 TV에서 " 심슨 가족 " 을 보지 않고 자란 사람들 : 테스트가 통과되면 차이점 을 보지 말고 개발자가 변경 사항을 안내하도록 유도하십시오)

아니

테스트가 통과 될 때까지 리팩토링하고 테스트 범위를 추가 하십시오 .

곱셈과 마찬가지로 코드 검토는 0에 적용될 때 0의 결과를 제공합니다. 그러한 경우에는 값을 증가시키지 않지만 다른 대부분의 경우에는 값을 증가시킵니다.

작업해야하는 코드는 추가 개발 중에 코드 검토 프로세스의 이점을 얻지 못할 정도로 잘못 설계되었습니다. 코드 검토 프로세스를 사용하여 리팩터링하거나 재개발하십시오.

코드가 여전히 견딜 수 있지만 작업이 좋지 않을 수도 있습니다. 너무 넓어서 조금씩 증가시켜야합니다.