코드를 더 잘 검토하는 방법?

먼저 코드 검토 프로세스를 굳게 믿고 항상 다른 사람이 내 코드를 검토하기를 원합니다. 내 질문은 실제로 다른 사람을 위해 코드 검토를 더 잘 수행 할 수있는 방법에 중점을 둡니다.

코드 검토를 수행하려면 기존 코드의 작동 방식에 대한 지식과 현지 표준이 무엇인지 잘 알고 있어야합니다. 여전히 다른 사람들을 위해 코드를 충분히 검토하지 않는 것 같습니다. 또한 특정 사람들이 다른 사람들보다 더 나은 직업 검토 코드를 사용하는 것처럼 보이므로 훌륭한 코드 검토 자에게 사용하는 기술이 무엇인지 궁금합니다.

더 나은 코드 검토를 수행 할 방법이 없습니다. 당신이 할 수있는 것만이 학습과 경험으로 향상을 유지합니다.

일반적으로 내가 따르는 것들

- Use variables judiciously
- Keep things in scope loose boundaries will generate more errors
- Orient your language of coding in domain specific terms, they make more sense
- Keep loops to minimum 2 for each method if needed
- use ternary operators
- Arrange methods alphabetically
- Keep errors at handling ease
- write less but efficient code

나는 당신이 그것에 추가 할 수있는 많은 생각합니다.

다른 사람들이 당신을 위해 좋은 리뷰어가되는 이유를 스스로에게 물어보십시오.

또한 코드를 진행하면서;

• 당신이 이해하지 못하는 것에 멈춰 지금 의견이 필요하다고 쓰십시오.
• 코딩 표준 (공백, 괄호, 낙타 케이스 등)을 준수하는지 식별
• 모든 기능이 포함되어 있는지 확인하십시오
• 로직이 경계 조건 등을 통과하는지 확인하기 위해 간단한 로직 테스트를 수행하십시오.

나는 단지 목표

• 제안 된 변경이 필요한 이유를 설명 합니다. 수정 사항뿐만 아니라 다른 이유도 얻습니다.
• 코드 형식에 동의-모든 사람의 코드가 동일 / 친숙하게 보이도록
• 유지하려는 코드 특성 목록을 공유합니다. 모든 사람이 모든 실수를 한 번만 할 필요가 없도록 위키에 올리십시오. 자주 업데이트하십시오.

그 외에도 "찾을 내용을 아는 것"은 경험, 연습 및 독서와 함께 제공됩니다.

내 경험상 가장 좋은 방법은 홀 팀이 코드를 검토하도록하는 것입니다. 각 프로젝트마다 커밋 메일 링리스트를 사용하여 버전 관리 시스템에 대한 모든 코드 변경을 따를 수 있습니다. 대부분의 개발자는 코드 변경에 관심이 있기 때문에 프로젝트 별 메일 링리스트에 가입했습니다.

누군가가 새로운 소스 코드에서 나쁜 길을 발견했을 때, 커미터가 훈련 된 사람이라면 커미터에게 어떻게 더 나은 방법을 설명 할 수 있는지, 또는 경험이 풍부한 커미터라면 그것에 대해 토론을 시작합니다.

물론이 방법은 모든 새 코드가 검토되도록 보장하지는 않습니다. 특히 팀원 중 한 명이 각 코드 변경을 수행 할 여가가없는 스트레스가 많은시기에 더욱 그렇습니다. 또한 모든 개발자가 모든 개발자가 자신의 업무를 훌륭하게 수행 할 책임이있는 것은 아니며, 이것만으로도 검토를 보증 할 수는 없습니다. 그러나 최소한 우리 팀에는 항상 기술 품질을 담당하는 기술 관리자가 있습니다.

다음 점수를 준수하는 경우 코드 리뷰의 진정한 팬입니다.

• 모든 개발자는 자신의 의견에 대한 모든 코드와 주장을 검토 할 수 있습니다
• 아무도 다른 사람의 코드를 남용 할 권리가 없습니다
• 잘못된 코드는 토론을 활성화 할뿐만 아니라 좋은 코드도 활성화합니다
• 토론은 모든 관련 사람들의 행복으로 끝납니다
• 최소한 기능이 완료되기 전에 검토가 거의 실시간으로 이루어집니다.

내가 배운 것은 각 코드 줄을 검토하고 코드 형식 또는 코드 효율성 측면에서 코드 품질과 같은 것들을 제어해야한다고 생각하면 기계가 할 수있는 일을하기 때문에 자신이 매우 비효율적이라는 것입니다 당신. 목표는 각 코드 기여의 빌드 및 코드 품질을 제어하는 ​​지속적인 통합 시스템을 사용해야합니다. 이 시스템이 보고서를 작성하여 기고자에게 보내면 모든 것이 완벽합니다.

프로그래머의 품질을 제어하거나 순위를 매겨 야하기 때문에 코드를 검토해야한다면 제 제안은 이해가되지 않습니다. 이 경우 소스 코드를 한 줄씩 검토하지도 않습니다. 나는 다음과 같은 것들을 검토 할 것이다 :

• 보안 관련 문제가 있습니까
• 사용 된 API
• 코드가 지정된 아키텍처를 적용 했습니까?
• 그는 유용한 테스트를 작성 했습니까 (그러나 그가 암시 적으로 지시받은 경우에만 배워야했습니다)
• 선적 서류 비치
• 빌드 프로세스
• ... 그리고 아마도 더

숙련 된 개발자라면 항상 더 나은 성능으로 할 수있는 루프와 같은 것을 찾을 수 있습니다. 물론 다른 사람들에게 그러한 지식을 설명하는 것이 유용하지만 이것은 검토 세션의 일부가되어서는 안됩니다. 중대한 성능 문제가있는 경우에는 목록 유형의 덜 효율적인 변형을 사용했기 때문이 아닙니다.

초기 질문은 일부 사람들이 다른 사람들보다 더 나은 검토를하는 것처럼 보였기 때문에이 사람들은 실제 검토가 시작되기 전에 미리보기를 할 것이라고 대답했을 것입니다. .

[H] 이제 다른 사람을 위해 코드 검토를 더 잘 수행 할 수 있습니까?

그들에게 많은 질문을

코드 검토를 수행하려면 기존 코드의 작동 방식에 대해 알고 있어야합니다.

사실, 아닙니다. 좋은 검토자가되기 위해 코드를 미리 알 필요는 없습니다.

몇 일 전에 고용주가 모든 코드 체크인을 검토자가 서명하도록 요구하기 시작했습니다. 나는 C에서 GUI 작업을 주로하고 있었고, 저를위한 최고의 리뷰어 중 하나는 내 친구 빌이었습니다. 그는 C에 능숙했지만 GUI 작업을 많이하지 않았으며 리뷰에 들어가서 내 코드가 어떻게 작동하는지 전혀 몰랐습니다.

그러나 그는 그것에 대해 많은 질문을했고 설명해야 내 코드가 무엇을했는지, 왜 내 생각에 많은 생각을 자극했는지 이해할 수있었습니다. 그것은 엣지 케이스와 함께 많은 이상한 작은 버그를 발견하게 만들었고, 내가 취할 수있는 다른 접근법도 고려했습니다. 또한 그 시점에서 22 년 동안 C를 작성했지만 꽤 능숙하다고 생각했지만 코드 품질이 빠르게 향상되었습니다.

더 이상 그곳에서 일하지 않아도 체크인 전에 diff를 검토하고 "빌이 어떤 질문을합니까?" 그리고 종종 결과적으로 무언가를 바꾸는 일이 생깁니다.