무엇을 먼저해야합니까 : 테스트 또는 코드 검토?

저는 프로그래밍 디자인 패턴과 라이프 사이클에 익숙하지 않아서 별도의 사람들이 수행한다는 점에서 코드 검토 또는 테스트가 무엇인지 궁금합니다.

한쪽에서 왜 코드가 작동하는지 확인하지 않으면 왜 코드를 검토해야합니까? 다른 테스트에서 테스트하기 전에 검토를 수행하면 일부 오류가 조기에 발견 될 수 있습니다.

어떤 접근법이 권장되며 그 이유는 무엇입니까?

먼저 개발자 단위 테스트를 한 다음 코드 검토를 한 다음 QA 테스트를 수행합니다. 때로는 코드 검토가 단위 테스트 전에 발생하지만 일반적으로 코드 검토자가 실제로 늪에 빠졌을 때만 가능합니다.

우리의 표준은 제품이 QA에 들어가기 전에 코드 검토를하는 것입니다. 그 이유는 일단 제품이 테스트되고 검증되면 리팩토링을 수행하고 코드 내부를 수정하는 인센티브가 적기 때문입니다. 그런 다음 모두 다시 테스트해야합니다. 대부분의 경우 단위 테스트도 수행합니다.

이상적으로는 민첩한 세계에서 :)

테스트 중심 개발은 실제 코드를 작성하기 전에 단위 테스트의 개발을 장려하는 방법입니다. 이렇게하면 코드로 사양을 캡처하고 테스트를 통과 한 테스트를 작성할 수 있습니다. 그 후, 다양한 구성 요소를 모두 맞추는 자동화 된 통합 테스트는 응용 프로그램의 기능이 예상과 일치하는지 확인하는 데 도움이됩니다.

코드 검토의 경우 페어 프로그래밍은 실제로 코드를 작성할 때 코드를 간과하는 또 다른 마음을 갖는 유용한 방법입니다. 그러나 이것이 반드시 실용적인 접근법은 아닙니다. 현재 회사에서 작동하는 방식은 개발자의 개인 컴퓨터에서 코드를 테스트 한 후 공유 개발 서버에 배포하기 전에 코드를 검토하는 것입니다.

코드 검토는 코드가 원하는 품질 수준을 유지하고 회사에서 정의한 코드 지침을 준수하도록하기 위해 이미 작동하는 것을 "고정"하기 위해 수행됩니다.

코드 검토는 이전 코드를 리팩토링하고 개선하는 향후 일반 최적화 활동의 일부로 발생할 수도 있습니다.

체크인하기 전에 코드 검토를 연습하면 코드 검토는 두 가지 테스트 단계로 나뉩니다. 개발자가 먼저 코드를 테스트하고 동료가 코드 검토를 수행 한 후 체크인하면 나중에 전담 테스터가 더 철저한 개인 및 통합 테스트.

먼저 테스트하십시오. 마지막으로 테스트하십시오. 테스트, 테스트, 테스트

코드 검토는 훌륭합니다. 그러나 어려운-성격이 관련되거나 의견이 다른 경우 고통스러운 과정이 될 수 있습니다.

테스트는 매우 명확합니다. 작동하거나 작동하지 않습니다. 테스트, 테스트, 테스트! 가능하면 코드를 검토하십시오.

마지막 작업에서 제품 수명주기의 여러 단계에서 수행 할 세 가지 유형의 코드 검토가있었습니다. 첫 번째 유형은 Sanity Review라고하며 개발자가 단위 테스트를 수행하기 전에 발생했습니다. 실제로 Sanity Review는 기능이 완료되기 전에도 수행되었습니다. 아이디어는 개발 과정에서와 같이 한 쌍의 팀원이 앉아서 임의의 코드 섹션을 통해 개발이 잘 진행되고 있으며 거대 기업으로 끝나지 않을 것이라는 생각이었습니다. 기능을 통합 할 준비가되면 TDWTF 항목이 추가되었습니다. 이는 추가 지침이 필요한 사람들 (주니어 개발자, 신입 사원 및 다른 팀 구성원보다 익숙하지 않은 작업을 수행하도록 지정된 사람들)을 위해 주로 수행되었으며 일반적으로 사용되었습니다. 심각한 문제만을 다루는 짧은 모임을 가졌습니다.

다음으로 유닛 리뷰를했습니다. 이들은 일반적으로 세 명의 개발자와 함께 수행되었으며 단위 / 기능이 테스트되고 메인 트리에 병합 될 준비가되었을 때 수행됩니다. 이것은 가장 철저한 검토였으며 꽤 자세하게 설명했습니다. 코드의 원래 작성자, 코드를 병합하기 전에 사인온해야하는 트리 관리자 및 원래 개발자의 백업으로 선택된 세 번째 개발자가 있었기 때문에이를 위해 세 명의 개발자가있었습니다. (한 번 코드 섹션이 완성 된 아이디어는 다른 팀원에게 완전한 지식 이전이 있어야하므로 팀에는 코드 기반의 어느 부분에도 완전히 익숙한 직원이 항상 2 명 이상 있어야합니다.)

마지막으로 프로젝트 검토가있었습니다. 여기에는 전체 팀이 포함되었으며 약 1 주일이 걸렸으며 QA 및 제품 출시 후에 완료되었습니다. 모든 사용자가 할 수있는 마지막 릴리스주기 동안 모든 사람이 전체 코드베이스에 대한 모든 변경 사항을 확인하고 진행하도록하는 것이 목표였습니다. 아키텍처 변경, 문제에 대해 이야기하고 다음 버전의 프로젝트에서 개발을 시작하기 전에 리팩터링하고 수정해야 할 사항을 결정하십시오.

먼저 개발할 코드에 대한 자동화 된 테스트를 작성하십시오. 알려진 모든 요구 사항이 테스트되고 있는지 테스트를 검토하십시오. 코드를 작성하십시오. 원하는만큼 자주 검토하십시오.

수동 테스트가 필요한 경우 수동 테스트를 수행 하기 전에 코드를 검토 해야 합니다. 그렇지 않으면 수동 테스트를 다시 실행해야하기 때문에 코드 검토에서 제안 된 설계 개선이 거부됩니다.

계란이나 닭고기 중 어느 것이 먼저입니까?
따라 다릅니다.

당신이 새롭고 자신이하는 일을 잘 모를 경우, 동료에게 약간의 도움을 요청하십시오. 이것은 비공식적이지만 매우 진지하고 귀중한 코드 검토입니다.

일반적으로 먼저 더러운 작업을 먼저 수행 할 것을 제안하지만 코드를 다림질하고 올바른 장소 (예 : 명백한 비트가 아닌 까다로운 비트)에서 잘 주석 처리했는지 확인하십시오. 적어도 기본적으로 작동합니다 ( 최소 일반 사례와 일부 제한 사례 또는 예외에서 테스트). 그런 다음 동료에게 가져갑니다.

코드를 너무 빨리 검토하면 동료의 시간을 낭비 할 수 있습니다. 너무 늦게 검토하면 시간이 많이 걸릴 수 있습니다. 최고의 효율성을 위해 올바른 균형을 찾아야합니다. 따라서 일부 테스트가 먼저 수행 된 다음 검토 후 더 많은 테스트가 수행됩니다. 잠재적으로 복잡성과 반복에 따라 목적과 초점이 ​​다른 여러 코드 검토가있을 수 있습니다.

더 많은 리뷰가 있는지 확신 할 수 없습니다 (초기 학습 단계에있을 때는 정상입니다). 더 많은 리뷰를 더 많이 확신할수록 (자신을 확신하는 것은 결코 좋지 않습니다. 즉, 일반적으로 팀 선수가 아니고 다른 사람을 곤경에 빠뜨릴 수 있음을 의미하므로 코드를 이해할 수 있어야합니다. 다른 사람이 사용). 당신이 중간에있을 때 리뷰가 일부 간격을 둘 수 있습니다.

내 두 센트 만

소프트웨어 개발 프로세스의 결과 효율성과 품질을 연구하고 측정 한 Capers-Jones는 다음과 같은 결함 제거 활동 시퀀스 를 권장합니다 .

• 설계 검사
• 코드 검사
• 단위 테스트
• 새로운 기능 테스트
• 회귀 테스트
• 성능 테스트
• 시스템 테스트
• 외부 베타 테스트

테스트 전에 코드 검사를 수행하는 이유 중 하나는 검토 과정에서 코드 자체뿐만 아니라 코드의 테스트 가능성도 고려할 수 있기 때문입니다.