저는 회사의 개발을 개선하는 역할을 맡았습니다. 내가 시작하고 싶었던 첫 번째 일은 코드 검토였습니다.

우리 회사에는 3 명의 프로그래머가 있습니다. 저는 웹 프로그래머이며 알려진 언어는 주로 PHP, ActionScript 및 JavaScript입니다. 다른 2 명의 개발자는 VB.net에서 내부 애플리케이션을 작성합니다.

우리는 지금 몇 주 동안 코드 검토를 해왔습니다. VB 코드를 이해하기가 어렵습니다. 그래서 그들이 무엇을하고 있는지를 말할 때, 나는 대부분 그 단어를 받아 들여야합니다.

잘못된 것으로 보이는 것이 있으면 내 의견을 설명하고 내가 아는 언어 중 하나로 어떻게 해결해야하는지 설명합니다.

때로는 제 제안을 환영하지만 " 이 언어로 적용 할 수 있는 가장 좋은 방법입니다 "또는 " 이 언어에 적용되지 않는 방법 "또는 그와 유사한 것들을 들었습니다 .

이것은 사실 일 수 있지만 언어를 모른 채 이러한 주장을 확인하거나 반박하는 방법을 모르겠습니다.

더 나은 코드 검토를 할 수 있도록 vb를 배우는 것이 가능한 해결책이라는 것을 알고 있습니다. 나는 vb를 배우는 데 관심이 없으며 (특히 내 자신의 프로젝트를 위해 배우려고하는 다른 기술 목록이 있기 때문에) 이것을 최후의 수단으로 유지하고 싶지만 옵션입니다.

나에게 온 또 다른 아이디어는 둘 다 C #에 관심이 있으며 나도 관심이 있습니다. 그러나 그것은 우리 모두에게 새로운 것입니다. 애완 동물 C # .net 프로젝트를 공동 작업하고 서로 코드를 검토하는 우리 모두의 이점에 대해 생각했습니다.

컨설턴트를 고용하여 코드 검토를 해줄 가능성도 있습니다.

이 상황에서 내가 뭘 추천하겠습니까?

다른 것들을 배우려는 당신의 개인적인 욕구는 당신이 지금 직업에 실제로 필요한 것을 배우기 위해 뒷좌석을 가져야합니다. VB.net을 배우십시오. 많은 질문을하여 이해하는 언어를 알 때 이해하지 못하는 코드를 효과적으로 코딩 할 수 있습니다. 왜). 그러나 코드를 이해하지 못하면 최선을 다해 코드를 설명하고 코드를 설명하는 과정에서 버그를 발견하기를 바랍니다. 리뷰를 통해 내 코드에서 버그를 발견하지는 않았지만 코드를 검토하는 가장 효과적인 방법은 아닙니다. 코드 검토는 이제 업무의 일부이며 처리하고 효과적으로 수행하기 위해 필요한 것을 배우십시오.

당신이 배우는 동안, 그들이 우리가이 언어로하는 방식이 아니라고 말할 때, 그들이 사용하기에 좋은 기술이라고 말하는 출처를 보여주십시오. 다른 방법으로 코드 검토에서 당신에게 정당화하는 것은 그들에게 달려 있습니다. 해당 링크를보기 시작하면 언어에 익숙해집니다.

사실, 나는 위의 모든 것에 동의하지 않습니다. JS / PHP / ActiopnScript를 사용하면 프로그래밍 언어의 기능과 작동 방식에 대한 기본적인 이해가 가능합니다. 실제로 VB와 JS 사이에는 많은 유사점이 있다고 주장합니다. 그러나 그것은 내 요점이 아닙니다. 언어에 능숙하더라도 다른 사람의 사고 과정을 따르려고 할 때 무언가를 간과하기가 쉽습니다. 따라서 검토해야 할 것은 프로그래머가 수행 한 작업과 이유를 설명 할 수있는 기회를 제공하는 것입니다.

한 친구는 이것을 "관리인 이론"이라고 설명했습니다. 프로그래머는 누군가, 누군가, 심지어 관리인에게 세부 사항을 설명함으로써 코드의 약점을 자신에게 노출시킵니다. 방법. 그러나 코드를 철저하고 공개적으로 설명해야합니다 (개발자가 방어적일 때는 검토가되지 않습니다).

짧은 버전

1. 코드 검토는 검토 자 와 검토자가 학습 할 수 있는 기회입니다 .
2. 질문으로서의 구절 피드백.
3. 지식이 부족하여 피드백을 제공하지 못하게하지 마십시오 (# 2를 수행하는 한).
4. "선호도 검토"를 피하거나 적어도 그들이 당신의 개인적인 취향이며 반드시 동의 할 필요는 없음을 분명히하려고 노력하십시오.
5. "armchair 코드 검토 자"대신 패치를 제출하십시오.

더 긴 버전

우선, 코드 검토는 검토자가 배울 수있는 기회가 아니라는 점을 기억하십시오. 또한 검토자가 배울 수있는 기회이기도합니다. 사실, 새로운 프로그래머가 코드 검토를 시작하여 코드에 대한 느낌을 갖도록하는 여러 조직에 대해 들었습니다.

이를 염두에두고, 내가 일반적으로 항상 유용하다고 생각하는 코드 검토 조언이 있습니다. 그러나 특히 귀하의 입장에 적합합니다. 의견이 아닌 질문 형태로 피드백을 표현하십시오. 다시 말해, "이 코드는 짜증나!"라고 말하는 대신 "왜 코드를 작성하는 대신 이런 방식으로 코드를 작성 했습니까?"라고 말할 수 있습니다. 이렇게하면 코드 검토 프로세스가 더욱 즐거워지고 배우게됩니다.

내가 당신에게 해줄 또 다른 조언은 당신의 지식 부족이 당신을 뒤로 물러서는 안한다는 것입니다. 자신이 잘못 생각하는 것을보고 검토 자로부터 손으로 대답하는 경우, 최소한 지식이 부족하여 물러서지 마십시오. 한 언어로 좋은 코드를 만드는 것은 다른 언어로 좋은 코드를 만드는 것과 거의 다르지 않습니다. 예, 특정 언어에는 좋은 코드를 작성하는 데 도움이되는 다른 관용구가 있습니다. 그러나 이러한 관용구는 그 자체가 아니라 도구 라는 것을 인식하는 것이 중요 합니다.

우선, "기본 설정 검토"를하지 마십시오. 이것은 (그리고 다른 많은 사람들이) 매우 의식적인 노력을 기울여야하는 것입니다. 다시 말해서, "You did x 했지만 y를 선호합니다 . "와 같은 리뷰를하지 않도록하십시오 . 이제 선호 사항을 명시하는 데 아무런 문제가 없지만 명확하게 레이블을 지정하고 상대방이 자유롭게 동의하지 않는다는 메모를해야합니다. 언어마다 언어가 다른 대부분의 항목이이 범주에 속하므로 이는 중요합니다.

마지막으로 분산 버전 제어 시스템을 사용하십니까? 도움이 될 수있는 한 가지 방법은 코드의 문제점에 주목하지 않고 코드를 작성한 방법을 다시 작성하여 테스트 한 다음 패치를 제출할 수 있다는 것입니다. 이렇게하면 코드를 개선하는 데 진심으로 관심을 갖고 있으며 "어머니 어 코드 검토 자"가 아니라 언어를 더 잘 배울 수 있습니다. 또한 일반적으로 "이 작업을 수행 한 방법은 다음과 같습니다. 동의하는 경우 패치를 작성하십시오"보다 "이 작업을 수행해야한다고 생각합니다"에 동의하지 않는 것이 더 쉽습니다. DVCS가 반드시 필요 하지는 않지만 분명히 도움이됩니다.

문제에 집중하지 못하고 해결책이 잘못되었습니다. 개발을 개선해야하는 과제를 겪었으며 솔루션은 언어를 이해하지 못하는 코드 검토 담당자 (자체)를 배치하는 것입니다. 누가 코드를 검토하고 있습니까? 언어를 배우기 전까지 서로 검토 할 수없는 이유는 무엇입니까?

보다 즉각적인 개선을 위해 선택할 수있는 다른 문제 영역이 있어야합니다. 이런 식으로 그들은 당신에게 연기를 날려 버리고 아무것도 개선되지 않습니다.

여러분이 이해하지 못하는 언어로 새로운 개발을 지시하는 것은 (C #) 특히 모든 사람이 나쁜 습관을 가져다 줄 때 돈을 지불하는 데 오랜 시간이 걸리지 않을 것입니다.

디자인에 중점을 둡니다 (이것은 언급되었습니다). 현재 코드를 유지 관리하는 데 어려움이 있으면 VB 용 리팩토링 도구를 살펴보십시오. 많은 기본 관행이 동일합니다.

실제로 알지 못하는 내용을 '읽기 교정'할 수는 있지만 적절하게 검토 할 수는 없습니다 . 나는 C에 능숙하고 C ++을 잘 알고 있지만 C #에서 무언가를 검토하는 것을 꿈꾸지 않을 것입니다.

일부 회사는 수많은 테스트를 통해 코드를 실행하고 코드에 어떤 문제가 있는지 전문화하기 때문에 컨설턴트를 데려 가야한다고 생각하지 않습니다.

그럼에도 불구하고 결과를 해석 할 언어를 아는 것은 개별 개발자에게 달려 있습니다. 예를 들어, 코드 검토자가의 반환 값을 사용하지 않은 것에 대해 저를 지치게했다면 printf()이상하게보고 그들의 주심에 의문을 품고 "좋습니다. 콘솔에 아무 것도 인쇄 할 수없는 경우 어떻게해야합니까? 도움이 되길?"

고려해야 할 사항은 부서와 팀장을 설정하는 것에 대해 상사와 대화하는 것입니다. 따라서 다른 사람은 자신의 도메인에서는 효과적 일 수 있습니다.

그래도 감사를 위해 타사를 사용할 수 있다고 생각합니다. 소금의 가치가있는 대부분의 프로그래머는 반 정도의 허위 (내 예 에서처럼)를 기각하더라도 합법적 인 문제에 주의를 기울일 것입니다 printf().

당신이 이해하지 못하는 것에 대한 지침을 제공하는 것은 당신이 잘 알고 있기 때문에 장님을 이끄는 장님과 유사합니다.

FxCop 및 StyleCop 과 같은 린트 도구를 사용 하여 코드베이스의 정적 분석을 처리하는 방법 중 하나가 있습니다 . 이를 통해 도구에서 생성 된 보고서를 토론 할 수 있습니다.

다른 접근 방식은 코드 검토를 설계 검토로 전환하는 것입니다. 코드를 작성하기 훨씬 전에 설계 검토가 더 자주 문제를 발견하지 않습니다. 프로그래머가 디자인을 가지고 있다면 일반적으로 훨씬 효율적으로 접근 할 수 있으며 버그로 인해 버그가 줄어 듭니다. 디자인이 존재하지 않으면 접근 방식에서 임시가되고 버그 수 증가로 인해 코드가 손상됩니다. 코드 검토에 등장하기 전에 디자인 검토의 문제점을 파악하여 각 사용자가 구현할 구체적인 디자인을 갖도록하십시오. UML은 당신의 친구이며 umlet 과 같은 도구 는 빠르고 사용하기 쉽습니다 .

나쁜 소식은 코드 검토에 효과적으로 참여하려면 VB를 배워야한다는 것입니다. 어떤 종류의 프로젝트에서 VB를 사용하는 것도 도움이 될 것입니다 (생산에 반드시 필요한 것은 아님).

좋은 소식은 일단이 작업을 수행 한 후에도 C #으로 넘어갈 때 배운 내용이 여전히 유용하다는 것입니다.

동료 검토를 수행 할 때 항상 유지해야한다는 생각은 다음과 같습니다.

"이 코드를 유지 관리하는 다음 사람입니다!"

검토 준비의 일부로 그렇게 할 수있을만큼 충분히 이해해야하며, 원래 프로그래머는 코드를 유지하기에 충분히 코드를 이해하는 데 필요한 것보다 더 성가신 결함을 인식해야합니다. .

VB에서 프로그래밍 할 수없는 경우 코드를 유지할 수 없으며 피어 검토자가 될 수 없습니다.

이해하지 못하는 코드를 검토해서는 안됩니다. 개발자가 수행 한 모든 이상한 모양을 설명해야하는 개발자 만 귀찮게합니다.

코딩 지침을 선택 / 정의하고 이러한 지침에 따라 코드를 확인하십시오. 무언가가 지침을 준수하지 않으면 개발자에게 설명을 요청할 수 있습니다.

기존 지침을 선택하는 것으로 시작합니다 (VB.net 코딩 표준을 모르지만 Google은 다음과 같이 말했습니다.

• VB .Net 코딩 지침
• 서브 메인
• 하나의 코드 프레임 워크

VB .net 용 도구와 같은 stylecop 사용

NDepend를 사용 하여 소스 분석 (사이 클릭 복잡성, 길이, 깊이 등에 대한 규칙이 있음)

코드가 선택한 표준을 준수한다고 말할 수 있으면 기능이 올바른지 또는 적절한 OOP 원칙을 사용하는 코드에 대해서는 언급하지 않습니다. 그러나 적어도 그것은 뭔가입니다.

좋은 코드 검토는 언어, API 및 라이브러리, 스타일, 변수 이름 등의 적절한 사용-언어를 이해해야하는 사항과 코드가 문제를 얼마나 잘 해결하는지에 대한 것입니다.-좋은 주석, 적절한 아키텍처, 관련 디자인 패턴 검토, 모든 오류 사례 등을 고려합니다. 코드 검토를 처음 시작할 때 전자에 집중하는 경향이 있습니다. 보기 쉽고 선택하기 쉽습니다. (예 : 변수 이름이 마음에 들지 않습니다. XXXX 스타일 이름을 사용해야합니다.)

코드가 문제를 얼마나 잘 해결하는지에 더 중점을두면 코드 검토가 더욱 중요해집니다. 지금은 첫 번째 영역에서 많은 가치를 제공 할 수 없으므로 문제를 해결하는 방법이 아니라 문제를 해결하고 문제에 대한 조언을 제공하는 데 집중하십시오.

물론 둘 사이에 겹치는 부분이 있습니다. VB.NET을 알면 특정 상황에서 특정 디자인 패턴이 왜 적합하지 않은지에 대한 조언을 제공 할 수 있습니다.

무엇보다도이 단계에서 겸손해야합니다. 프로세스 변경이 어렵습니다. VB.NET 전문가 인 경우에도 변경이 쉽지 않을 수 있습니다. 코드 검토를 사용하지 않은 사람들은 처음에 그것을 좋아하지 않습니다. 다른 사람들이 귀하의 코드를 보도록하는 것은 힘든 경험입니다. 그 가치를보고, 인내심을 인내하려면 시간이 걸립니다. 바이 인을하는 것은 좋은 과정이지만 시간이 걸릴 것입니다.

코드를 직접 보지 않고 테스트에 더 집중하도록 초점을 맞출 수 있습니까? 코드 검토를 포기하는 것은 아니지만 처음에는 내부 앱에서 발생하는 일부를 디코딩하는 데 도움이되는 충분한 테스트를 수행하는 것이 더 합리적입니다. 여기서 테스트는 일부 기능에 대해 좀 더 친숙해 지도록 테스트 할 수 있다는 아이디어입니다. 나는 이것을 다른 길로 본다. 여기서 검토는 나중에 다시 돌아와서 개요 / 선결 세션을 갖는 것이 좋으며 약간의 휴식이 필요할 수 있기 때문에 두 부분으로 나눌 수 있습니다. 다음 날 이틀까지 휴식을 취하면 질문으로 돌아와 토론을하기 전에 코드 나 비슷한 것을 생각하고 잠을 자고 싶은 사람이 충분한 시간을 가질 수 있습니다.

물론 이미 테스트를 받았다면 불행히도 의미가 없습니다. 다른 생각은 VB.Net에서 이것이 특정 방식으로 수행되었다는 주장의 예를 제시하는 것입니다.이 방법은 작은 코드 표준에서 VB.Net이 어떤 의미로 구축되었는지의 핵심입니다.

VB의 기본 사항을 배우더라도 언어의 모든 기능을 모르는 상태에서 코드 검토를 수행하면 언어의 안전하지 않은 기능 사용을 감지 할 수 없습니다.

문자열이 아닌 입력 유형을 더 쉽게 구문 분석하기 위해 Python 2의 input () 함수가 입력을 반환하기 전에 실제로 입력을 평가했다는 것을 모르고 있다고 가정하십시오. 그런 다음 코드는 임의 코드 실행에 취약하여 사용자가 __import__('os').execl('/bin/sh', '/bin/sh')Linux 시스템 과 같은 방식 으로 입력 하여 Python 프로세스를 셸로 전환 할 수 있습니다. 대신 raw_input ()을 사용하여 처리되지 않은 입력 데이터를 가져와야합니다.

언어의 모든 기능을 모른 채 코드 검토를 수행하려고 시도하면 언어에서 특정 절차를 수행하는 더 좋은 방법을 깨닫지 못할 수 있습니다. 또한 해로운 보안 결함으로 이어질 수 있습니다.