코드 검토 목록

http://blog.smartbear.com/wp-content/uploads/2015/09/Creating-Your-Code-Review-Checklist.jpg
나는 내 블로그에 우리가 코드 심사를 어떻게 하는지에 관한 글을 발표하고 이를 배합 프로그래밍과 비교했다.
내가 주의한 것은 모든 팀과 팀원들이 코드 심사를 할 때 서로 다른 명세서를 가지고 있다는 것이다.이 문장에서 나는 내가 원하는 것을 열거할 것이다.이것은 절대로 완전한 명세서가 아니다.검사가 부족하다고 생각되면 댓글에 추가해서 알려주십시오.

설계

사용자가 사용하는 프로그래밍 언어나 플랫폼에 따라 새 코드가 정확한 설계를 따르는지 확인하십시오.
무엇이 정확한 설계인지는 팀의 동의 여부에 달려 있습니까?새로운 추상을 도입하고 새로운 디자인을 따를 때 개발자들 사이에서 미리 논의하는 것이 좋다.코드 심사는 토론한 대로 실현될 수 있도록 일종의 방법으로 확보할 수 있다.이것은 많은 재작업이 없을 것을 확보할 것이다.그러나 새로운 것을 실시하고 피드백을 받고 싶을 때 면제된다.생각을 전달하기 위해 충분히 많이 쓰도록 하세요.
다음은 체크해야 할 사항입니다. (이 목록에서 대부분의 내용을 제공해 주셔서 감사합니다.)

일관성과 모범 사례를 유지하기 위해 지정된 스타일 가이드의 인코딩 규칙을 따랐는지 확인합니다.

개발자가 무의식중에 도입한 중복을 검사한다. 예를 들어 기존 재사용 가능한 구성 요소에 대한 인식 부족, 논리/직책 착오, 유니버설/재사용 가능한 코드를 추출하지 않고 다른 곳에 복사/붙여넣기 등

초기 기술 채무와 코드 심사 기간에 놓치거나 지연된 재구성 기회를 확정한다.일반적으로 개발자가 이 분야에서 일하면 상하문이 많기 때문에 일부 재구성 임무를 이야기/공관의 일부분으로 하는 것이 더욱 쉽다. 전문적인 시간을 찾아 재구성하는 것이 아니라.

개발자와 다른 개발자 코드의 잠재적 의존 관계나 충돌을 발견하고 경고한다. 예를 들어 코드 라이브러리와 같은 구역의 여러 기능이 개발 또는 심사 중일 때

비표준 기능이나 해커가 도입된 경우 #TODO 또는 #FIXME 태그를 사용하여 주석을 작성하고 합리적인 코드 세그먼트/패치를 참조하는 것과 이상적인 해결 방안이 무엇인지 등 적절한 주석을 첨부해야 합니다.e, g.#프레임#링크#의 빈틈을 수정합니다.고정 버전으로 업그레이드한 후 삭제합니다.

도입된 새 라이브러리가 필요한지, 최신 버전인지 주의해야 한다.더 좋은 대안이 있습니까?

테스트

상기 모든 코드에 대한 검사표도 테스트 코드에 적용된다.

모든 코드가 각 단계에서 테스트를 작성했는지 확인 — 유닛, 통합 및 기능

모든 테스트가 통과되었는지 검사한다.

테스트가 테스트 코드의 의도를 설명하는 문서로 되어 있는지 확인합니다.

테스트 실패 시 정확한 오류 메시지가 있는지 확인합니다.예:

expect(subject).to include(:customer) #is better than:
expect(subject.key? :customer).to be\_true

QA 모자를 쓰다

This is something which most people miss or probably think not as important. Working of the code is as important as its quality. Even if you have a testing team, catching bugs at code review will reduce the cost of fixing it.

이야기 설명을 읽고 BA나 제품 담당자에게 모든 검수 기준이 상술한 요구에 따라 집행되는지 물어본다.나는 이 수표만 있으면 대부분의 구린내를 잡을 수 있다고 생각한다.

이야기에서 언급한 이외의 장면을 생각해 보자.새 변경과 관련된 일반적인 사용자 흐름이 예상대로 작동하는지 확인하십시오.

다양한 기능 요구 사항 (비기능 요구)

성능, 보안, 분석, 로깅, 경고 등 다양한 기능에 대한 요구 사항도 고려됩니다.

코드가 N+1 쿼리 문제나 전체 데이터베이스를 메모리에 불러오는 등 성능 문제를 가져올 수 있는지 확인합니다. 생산 환경에서 이 코드를 실행하고 발생할 수 있는 문제를 예측하는 것을 고려합니다.물론, 코드만 보면 모든 오류를 찾을 수 없지만, 과거의 경험에서 흔히 볼 수 있는 오류를 식별할 수 있습니다.고객이 되는 것을 좋아하다.전부

안전성은 조기에 식별할 수 있다.승인된 사용자만 데이터에 액세스하는지 확인합니다.흔히 볼 수 있는 안전 예방 조치를 읽고 팀과 같은 이해를 나눌 수 있다.

일부 분석 시스템과 통합되어 있다면 새로운 기능이 통합되어야 하는지 확인하십시오.

응용 프로그램을 디버깅할 수 있도록 충분한 로그 기록을 완성했는지 확인합니다.

장애 발생 시 경고 추가 여부를 확인합니다.

연속 제공

연속적인 교부를 따를 때, 새로운 변경이 생산 데이터와 기능을 파괴하지 않도록 확보해야 합니다.

데이터 마이그레이션 스크립트가 추가되었는지 확인하고 예상대로 실행되었는지 확인합니다.필요하면 기계에서 한 번 실행하십시오.데이터 손실을 초래할 수 있는 변경을 하지 마세요.또한 프로덕션에 투입되는 기능을 프로덕션 데이터 사본(모호한)이 있는 임시 또는 사전 프로덕션 환경에 자동으로 배치하여 잠재적인 문제를 감지하고 복구해야 합니다.

발표하지 않으려는 모든 기능에 기능 전환이 추가되었는지 확인합니다.

따로

심사 중인 코드가 최신 주요 지점 코드와 통합되었는지 확인합니다.

이러한 변경 사항을 통합한 후 다른 팀에 설명을 추가해야 합니다.예를 들어 중대한 변화가 있으면 QA 팀이 어떤 방면에서 회귀를 실행하는지 알려준다.또는 다운스트림 소비자 시스템 API 계약의 변경 사항을 통지합니다.또는 다른 개발자를 돕기 위해 자술한 파일을 업데이트합니다.

전반적으로 심사할 변경 사항을 비교적 작은 범위 내에서 유지하고 가능한 한 빨리 피드백을 얻기 위해 요청을 제출해야 한다.
의견에 의견을 추가하십시오.만약 당신이 이 게시물을 좋아한다면 다른 사람들이 그것을 찾아 토론에 참여할 수 있도록 추천해 주십시오.