내 코드를 어떻게 검토합니까? [닫은]

나는 프로젝트 솔로에서 일하고 있으며 내 자신의 코드를 유지해야합니다. 일반적으로 코드 검토는 코드 작성자가 수행하지 않으므로 검토자는 신선한 눈으로 코드를 볼 수 있습니다. 그러나 나는 그런 사치가 없습니다. 내 코드를보다 효과적으로 검토하기 위해 어떤 관행을 사용할 수 있습니까?

우선, 도구를 사용하여 최대한 많이 확인하십시오. 테스트 (적당한 코드 적용 범위로 백업)는 코드의 정확성에 대한 확신을줍니다. 정적 분석 도구는 많은 모범 사례를 포착 할 수 있습니다. 항상 당신이 결정하기 위해 인간의 눈이 필요한 문제가있을 것입니다 그리고 당신은 다른 사람처럼 자신의 물건을 검토하는 일을 결코 잘하지 않을 것입니다, 그러나 당신이 도울 수있는 몇 가지가 있습니다

• 검사가 존재하고 통과하는지 확인하십시오 (어떤 경우에는이 검사를 중단해야 할 수도 있지만 그 이유를 정당화 할 수는 있지만 목표 검사 범위를 가질 수 있습니다)
• 정적 분석 통과를 확인하십시오 (여기에는 부정 부정이 있지만 그 이유를 정당화 할 수있는 한 괜찮습니다).
• 검토 할 추가 사항에 대한 점검 목록 유지 (가능한 경우이를 새로운 정적 분석 규칙으로 추가) SA가 확인할 수없는 항목 (예 : 주석이 여전히 유효한지, 적절하게 명명 된 항목인지 확인) 물론, 컴퓨터 과학에 알려진 두 가지 어려운 문제 중 하나)
• 결함이 식별되면 원인이 체계적인지 확인하고 이전 테스트 또는 검토에서 발견되지 않은 이유를 확인하십시오.

물론 다른 코드도 검토 할 때 유용합니다.

Code Review Stack Exchange 사이트를 살펴보십시오 . 동료 검토 를 위해 작업중 인 프로젝트의 코드를 공유하기위한 것입니다 .

코드 검토 스택 교환 은 코드 를 동료 검토하기위한 질문 및 답변 사이트입니다. 우리는 작업 코드를 취하고 더 잘함으로써 전 세계 프로그래머의 기술을 향상시키기 위해 함께 노력하고 있습니다.

다음 영역에서 프로젝트의 특정 작업 코드에 대한 피드백을 찾고 있다면…

• 모범 사례 및 디자인 패턴 사용
• 보안 문제들
• 공연
• 예상치 못한 경우의 정확성

코드 정적 분석 도구를 사용하여 특정 종류의 문제를 감지 할 수도 있지만 경우에 따라 잘못된 경고가 발생하고 설계 개선 방법을 제안 할 수 없습니다.

나는 내 머리 속에 완전히 다른 사람을 개발했습니다. 그들 중 하나는 프로그래머조차도 아닙니다! 우리는 채팅하고, 최신 뉴스를 토론하고, 서로의 코드를 검토합니다.

나는 나의 접근 방식을 강력히 추천한다.

ps 그는 농담하지 않습니다.

나는 한 사람의 검토가 두 사람의 검토만큼 효율적이지 않다는 오순절에 동의합니다. 그러나 당신은 그것을 최대한 활용하려고 할 수 있습니다 :

단기 검토 (코드가 생성 된 직후)

로컬 저장소로 git을 사용하고 있습니다. 기능을 완료하거나 버그를 수정할 때마다 변경 사항을 리포지토리에 전송합니다.

체크인하기 전에 코드에서 변경된 내용을 비교하고 다시 생각합니다.

• 변수 / 메소드 / 클래스 이름에 여전히 사용 된 내용이 반영됩니까?

장기 검토 (코드가 생성 된 후 6 개월)

나는 나 자신에게 묻습니다.

• 클래스 / 메서드 / 변수가 무엇을 한 문장으로 설명 할 수 있습니까?
• 클래스를 분리하여 사용하거나 (다른 클래스를 제외하고) 단위 테스트를 작성하는 것이 얼마나 쉬운가요?

먼저, 가능한 한 오랫동안 코드를 따로 보관하십시오. 다른 코드 조각으로 작업하십시오. 하루가 지나도 찾을 수있는 것에 놀랄 것입니다.

둘째, 코드를 문서화하십시오. 많은 프로그래머들이 코드를 문서화하는 것을 싫어하지만 설명서를 작성하고 코드를 작성하는 방법과 작동 방식을 스스로 작성하십시오. 다른 방식으로 코드를 보면 실수를 발견 할 수 있습니다.

과목의 진정한 숙달은 다른 사람에게 그것을 가르 칠 수있는 능력이라고합니다. 문서를 사용하면 다른 사람에게 코드를 가르치려고합니다.

이 디버깅 기술을 코드 검토 기술로 변환하십시오. http://en.wikipedia.org/wiki/Rubber_duck_debugging

이 개념은 마치 새로운 것처럼 코드를 통해 작업 할 수있는 적절한 사고 방식으로 전환하는 데 도움이됩니다.

다른 답변에 언급 된 유용한 도구 외에도 코드 검토를 수행 할 때 사고 방식을 수정하는 것이 유용하다고 생각합니다. 어리석은 일이지만 "코드 리뷰 모자를 쓰고 있습니다"라고 스스로에게 말합니다. 품질 관리도 마찬가지입니다.

그런 다음 그 사고 방식으로 자신을 제한하는 것이 중요합니다 . 귀하는 검토 자 또는 검토 자입니다. 동시에 둘 다있을 수는 없습니다. 검토 자로서 검토 자와 공유하기 위해 객관적인 메모를합니다. 코드를 검토하는 동안 코드를 변경하지 않습니다. 이는 검토자가해야 할 일이 아닙니다.

형식은 때때로 약간 어리석은 느낌이지만 솔로로 일할 때 종종 많은 방향으로 끌린다는 것을 알았습니다. 따라서 다른 무언가가 나오기 전에 반드시 검토 루프를 닫을 필요는 없습니다. 형식 (실제로 위키 도구에서 거친 메모를하고 있습니다)은 검토가 완료되도록하는 데 유용합니다. 마찬가지로 QA 모자를 켠 상태에서 버그를 수정하기 전에 버그 티켓을 추가합니다.

자기 검토가 효과적이지 않다는 것이 일반적인 감정인 것 같습니다. 나는 동의하지 않으며, 자기 검토가 철저하게 수행되면 많은 문제를 잡을 수 있다고 생각합니다.

몇 년 간의 경험에서 얻은 팁은 다음과 같습니다.

• 대략적인 점검표를 준비하십시오. 이것들은 코드를 읽는 동안 플래그를 지정하려는 것입니다.
• 코드 검토를 오프라인으로 가져 가십시오. 낭비가 될 수 있지만 주석을 달고 앞뒤로 뒤집을 수있는 출력물이나 iPad에 동기화 된 멋지게 강조 표시된 pdf의 디지털 문서를 오프라인으로 가져옵니다. 책상에서 멀리 떨어지면 코드를 방해받지 않고 검토 할 수 있습니다.
• 근무일이 아닌 아침 일찍 시작하십시오. 신선한 눈이 더 좋습니다. 실제로 코드를 새로 검토하기 전에 하루에 코드에서 벗어나는 것이 도움이 될 수 있습니다.

참고로,이 가이드 라인은 몇 년 전에 제가 작업 할 때 Oracle에서 권장하는 일부였습니다. 코드는 테스트를 시작하기 전에 "업스트림"에 버그를 잡는 것이 었습니다. 그것은 많은 개발자들에 의해 지루한 직업으로 여겨졌지만 많은 도움이되었습니다.

검토를위한 개인 소프트웨어 프로세스 기술은 작업 및 제품 품질에 대한 기록 데이터를 사용하지만 유용 할 수 있습니다.

작업 제품에 대한 히스토리 데이터, 특히 결함 수 및 유형으로 시작합니다. PSP 과정에서 와 같은 결함을 분류하는 다양한 방법이 있습니다 . 당신은 자신의 것을 개발할 수 있지만, 아이디어는 당신이 어떤 실수를하는지 말할 수 있어야한다는 것입니다.

어떤 실수를 저지르면 검토 중에 사용할 수있는 점검 목록을 개발할 수 있습니다. 이 체크리스트는 다른 도구를 사용하는 것과는 대조적으로 검토에서 가장 잘 잡을 수 있다고 생각하는 가장 큰 실수를 다룹니다. 작업 제품을 검토 할 때마다 점검 목록을 사용하여 이러한 실수 나 오류를 찾아서 문서화하고 수정하십시오. 이 체크리스트를 정기적으로 정기적으로 수정하여 코드의 실제 관련 문제에 초점을 맞추십시오.

또한 적절한 경우 도구 지원을 사용하는 것이 좋습니다. 정적 분석 도구는 일부 결함을 찾는 데 도움이되고 일부는 스타일 검사를 지원하여 일관성과 좋은 코드 스타일을 적용합니다. 코드 완성 및 구문 강조와 함께 IDE를 사용하면 "빌드"를 클릭하기 전에 일부 문제를 예방하거나 감지 할 수 있습니다. 단위 테스트는 논리 문제를 다룰 수 있습니다. 또한 프로젝트가 충분히 크거나 복잡한 경우 지속적인 통합을 통해 이러한 모든 작업을 정기적으로 실행되는 프로세스에 결합하여 유용한 보고서를 작성할 수 있습니다.

혼자 일한다는 것은 완전한 낯선 사람이 당신을 대신하여 코드를 검토하는 것을 신뢰하지 않는 한 코드 품질을 유지하기 위해 소프트웨어를 작성하는 방법을 살펴 봐야한다는 것을 의미합니다.

우선, 코드가 요구 사항과 일치하는지 확인하는 수단이 있어야하며, 둘째, 나중에 문제가 있다고 판단하면 코드를 변경하기가 비교적 쉽습니다. 다음과 같은 이유로 행동 기반 개발 접근 방식 을 적용하는 것이 좋습니다 .

1. BDD는 먼저 코드 테스트를 작성하는 것을 의미합니다. 이를 통해 모든 코드를 테스트 할 수 있습니다.
2. BDD는 본질적으로 TDD이지만 초점과 "언어"가 약간 다릅니다. 이것이 의미하는 바는 코드 작업 중에 코드를 계속 리팩토링하고 리팩토링 노력으로 코드가 제품 사양을 충족하는지 확인하기 위해 테스트를 사용한다는 것입니다.
3. BDD 언어는 요구 사항을 단위 테스트로 본질적으로 인코딩하는 문장의 형태로 테스트를 작성하도록 권장합니다.

따라서 여기서의 아이디어는 테스트를 통과 한 후에도 코드를 계속 리팩토링한다는 것은 자신의 코드를 효과적으로 검토하고 단위 테스트를 "여분의 시선"으로 사용하여 코드가 테스트에서 인코딩 된 요구 사항에서 벗어나십시오. 또한 요구 사항을 기반으로 한 높은 테스트 적용 범위를 통해 요구 사항을 충족하지 않고도 향후 코드를 변경할 수 있습니다.

실제 문제는 코드에서 리팩터링해야 할 잠재적 문제를 발견 할 수 있는지 여부입니다. 시중에는이를 도와 줄 수있는 몇 가지 프로파일 링 도구와 코드 품질 메트릭과 관련된 여러 가지 도구가 있습니다. 이것들은 종종 코드 리뷰가 놓칠 수있는 많은 것을 말해 줄 수 있으며, 스스로 프로젝트를 개발할 때 필수적입니다. 그러나 실제로는 경험이 핵심이며 리팩토링에서 무자비한 습관을 가지면 자신의 코드에서 훨씬 더 비판적 일 것입니다. 아직 읽지 않았다면 Martin Fowler의 리팩토링 책을 시작점으로 읽고 작업하려는 언어에 관계없이 좋은 BDD API를 찾으십시오.

본인과 같은 상황에 처할 때마다 코드 검토 / 메트릭 도구를 사용하여 "코드에 너무 근접하여 코드를 객관적으로 검사"하는 문제를 해결하려고했습니다. 도구가 숙련 된 검토 자와 동일한 가치를 제공 할 수는 없지만 여전히 나쁜 설계 영역을 찾아 낼 수는 있습니다.

이와 관련하여 상당히 유용한 도구 중 하나는 SourceMonitor 입니다. 약간 단순하지만 클래스의 메서드 수 및 각 메서드의 복잡성과 같은 코드에 대한 중간 수준의 의견을 제시합니다. 저는 항상 이런 유형의 정보가 StyleCop 등과 같은 도구를 통해 코딩 스타일을 적용하는 것만 큼 중요하다고 생각했습니다 (중요하지만 가장 큰 문제의 원인은 아님). 일반적으로 고지 사항과 함께이 도구를 사용하십시오. 경험 법칙을 어기는시기를 알고 코드 메트릭 도구에서 모두 녹색 인 것은 자동으로 좋은 품질이 아닙니다.

코드 검토 자에게 무언가를 설명한 횟수를 알 수 없으며 머리 속 전구가 켜지고 "잠깐만 기다려요."라고 말합니다. 그래서 종종 다른 사람이 보지 못한 코드 검토에서 내 자신의 실수를 발견합니다. 그래서 당신은 그것을 시도 할 수 있습니다. 당신의 행동과 이유를 이해하려고하는 사람이 옆에 앉아있는 것처럼 코드를 설명하십시오.

코드 검토에서 자주 발견하는 또 다른 사항은 개발자가 실제로 요구 사항을 따르지 않았다는 것입니다. 따라서 코드와 실제 요구 사항을 비교하는 것이 좋습니다.

우리는 구조적 요구가 비슷한 SSIS 패키지와 같은 작업을 자주 수행합니다. 코드 검토를 위해 확인할 사항에 대한 체크리스트를 개발했습니다 (구성이 올 바르고 로깅 설정되어 있으며 메타 데이터 데이터베이스를 사용하고 표준 위치에있는 파일 임). 기타.). 코드 검토에서 매번 확인하는 것이 편리 할 수도 있습니다. 앉아서 코드 검토에서 확인하려는 항목의 체크리스트에 무엇을 넣을지 생각해보십시오 (첫 번째 항목, 요구 사항이 충족되는지 확인하고 다음 항목은 트랩 및 로깅 오류와 관련이있을 수 있음). 실수를하고 수정하면 목록에 다른 항목을 추가 할 수 있습니다 (예 : 루프에서 다음 레코드로 이동하거나 동일한 첫 번째 항목을 끝없이 반복 할 것입니다. 그것을 찾도록 가르치십시오!).

3 개월을 준 다음 돌아가서 코드를 살펴보십시오. 나는 당신이 그것에 뭔가 잘못 찾을 수 없다면 (또는이 쓰레기를 쓴 사람 질문!) 당신은 나보다 더 나은 사람입니다 약속드립니다!

나는 일반적으로 모든 코드를 인쇄하고 조용한 환경에 앉아서 읽습니다. 오타, 문제, 리팩터링, 정리를 통해 많은 것을 발견했습니다. 모든 사람이해야한다고 스스로 점검하는 것이 좋습니다.

대학으로 돌아가서 저는 가정교사였습니다. 필자는 많은 개발자들이 결코 생각하지 못했을 것으로 생각되는 코딩에 대한 몇 가지 관점을 분명히 제시했습니다. 가장 중요한 것 중 하나는 코드를 큰 소리로 읽는 것입니다. 그다지 들리지는 않지만 모든 사람들이 관련 될 수 있다고 생각하는 완벽한 예를 들어 보겠습니다.

이메일이나 종이를 작성하고 여러 번 다시 읽은 후 정확한지 확인한 다음 보내십시오. 눈에 띄는 철자 오류, 오타 또는 문법 오류가 있는지 확인하십시오. 나는 어제 클라이언트가 Shift 키 대신 shit 키를 누르라고 요청했을 때 이것을 수행했다. 당신은 당신의 머리를 읽을 때-당신이보고 싶은 것을 볼 수 있습니다.

이것은 다른 사람들이 제안한 '하루 또는 일주일 또는 한 달만 기다리십시오'제안에 대한 지름길입니다. 당신이 그것을 큰소리로 읽는다면 당신도 같은 것을 잡습니다. 왜 그렇게 효과적인지 모르겠지만 수백 명의 학생과 함께 앉아서 큰 소리로 읽은 후에는 효과가 있다고 말할 수 있습니다.

대부분의 사람들은 자신의 코드를 자신의 아기로 생각하고 현실보다는 자아를 먹이는 경향이 있습니다. 다른 코드 검토와 마찬가지로 다른 사람의 코드를 볼 때 검토하십시오. 당신이 무언가를 썼다는 것을 완전히 잊어라. 코드의 각 줄을 검토하십시오. 점검 목록은 자체 코드 검토에 대한 미학에 도움이됩니다. 코드 검토를위한 자동화 된 도구가 확장에 도움이 될 수 있습니다. klocwork (상업용 소프트웨어) 와 같은 도구를 사용 했습니다. 대규모 프로젝트에서 작업하고 여러 개발자가 작업하는 동안 매우 유용합니다. 수정보다는 결함 감지에 항상 집중하십시오.

그러나 모범 사례는 자신을 검토 한 후 나중에 다른 역할을 맡은 검토를 위해 다른 두 명 이상을 참여시키는 것입니다.

직접 Fagan 검사를 고려하십시오-혼자 있기 때문에 프로세스를 조정해야하지만 그로부터 상당한 가치를 얻을 수 있어야합니다. 비결은 솔로 개발자로서 코드를 평가할 수있는 올바른 "규칙"을 찾은 다음 매번 비판적이고 분석적이며 무자비한 마음의 프레임으로 질문을하는 훈련을받는 것입니다. 나는 당신이 시작해야 할 4-5 개의 중요한 질문들을 브레인 스토밍하고 나서 시간이 지남에 따라 진화하고 싶을지도 모른다. 어떤 사람들은 시간이 많이 걸리는 것처럼 보이기 때문에 정식 검사에 반대합니다. 너무 비싸다고 결정하기 전에 검사를 제대로 수행하면 실제로 프로젝트 시간이 단축된다는 모든 통계적 증거를 명심하십시오. 추가 연구를 시작할 수있는 Wikipedia 링크는 다음과 같습니다.

http://en.wikipedia.org/wiki/Software_inspection

Strauss와 Ebenau의 "소프트웨어 검사 프로세스"를위한 Google과 같은 서적도 있습니다.

다른 옵션은 중요한 프로젝트를 검사하도록 누군가에게 비용을 지불하거나 모든 코드를 검사하기 위해 때때로 비용을 지불하는 것입니다. 이 사람은 꽤 좋았습니다. 우리는 그를 새로운 개발자를 훈련시키기 위해 여러 번 나왔습니다.

http://www.javaspecialists.eu/

코드 검토에 대한 모든 권장 사항 외에도 PMD 및 findBug와 같은 도구를 사용하여 코드의 첫 번째 수준을 유지할 수 있습니다.

실제로 답변에 아직 배치되지 않았습니다 (그러나 기존 답변에 주석으로 추가됨)

숙면을 취한 후 코드를 검토하십시오. 예를 들어 전날 작성한 코드를 검토하여 하루를 시작하십시오.

물론 이것은 팀의 집단적 경험을 제공하지는 않지만 새로운 관점에서 코드를 검토 할 수있게 해줍니다.

예를 들어, 불쾌한 해킹으로 코드 조각을 남긴 경우 코드를 즉시 검토하면 코드를 수정하지 않을 수 있습니다. 결국, 코드 검토를 시작할 때 이미이 핵이 존재한다는 것을 알고 이해했습니다. 그러나 숙면을 취했다면 더 나은 해결책을 찾게 될 것입니다.

우리가 잠을 자면 뇌는 실제로 우리가 가지고있는 문제들에 대한 연구를 중단하지 않기 때문에 실제로 해결책이 생길 수도 있습니다 .