주니어 개발자에게는 코드 검토가 필요합니까?

코드 리뷰와 관련하여 서로 다른 방법론을 가진 두 회사에서 근무했습니다.

첫 번째 회사에서는 팀 리더가 코드 검토를 수행했으며 모든 모듈을 완료 한 후에 필요했습니다.

그러나 두 번째 회사에서는 팀 리더가 코드 검토를 수행 할 필요가 없었으며 기능 및 디자인 문제를 확인했습니다.

그래서 혼란스러워합니다. 코드 검토 프로세스가 실제로 필요합니까? 그렇다면 왜 그렇습니까? 그렇지 않다면 왜 그렇지 않습니까?

개인적으로 모든 코드는 코드 검토를 거쳐야한다고 생각합니다. 주니어 개발자인지 수석 개발자인지는 중요하지 않습니다.

왜? 초보자에게는 타이틀에 개발 방법에 대한 언급이 없으며 선임 개발자는 후배로부터 무언가를 배울 수 있습니다. 우리 회사에서는 다른 팀원 중 한 명이 귀하의 코드를 검토 할 수 있도록 이동합니다. 대부분은 "주니어"와 선임 팀으로 구성되어 있기 때문에 매일 말하지 않는 모든 내용은 다음과 같습니다. 후속 조치에 사로 잡혔습니다. 선배가 주니어 코드를 좋아하지 않는다면, 주니어 코드가 왜 그랬는지 듣고 그것을 살펴보고 그것이 미래에 사용될 수있는 실현 가능한 솔루션인지 확인해야합니다. 당신이 누군지

코드 검토의 중요한 점 중 하나는 너무 멋지지 않다는 것입니다. 좋은 사람이라면 시스템에서 점점 더 복잡한 코드를 발전시킬 수 있습니다. 어제와 마찬가지로 전직 개발자가 작성한 개발자가 작성한 완전한 응용 프로그램을 다시 작성하기 시작했으며 코드를 검토해야 할 수도 있습니다.

왜 팀 리더가 리뷰 만해야하는지는 알 수 없지만 제대로 개발되지 않은 코드에서 "싸움"을 선택하는 것을 두려워하지 않는 사람이 필요하며 코드가 어떻게 작동해야 하는지를 신경 써야합니다. 있다,이다. 모든 회사가 실제로 자신이하는 일에 관심이있는 사람들을 고용하는 것은 아니며, 나쁜 계란은 어깨를 으 rug하고 불량 코드에 대해 "OK"라고 말하기 때문에 코드 검토를 수행해서는 안됩니다.

기본적으로 코드 검토는 경험에 관계없이 모든 프로그래머에게 필요합니다. 소프트웨어 개발의 품질 관리이며, 오픈 소스가 매우 높은 품질의 이유 중 하나입니다.

편집 : 그 이유는 오늘날 코드 검토자가 나중에 관리자와 정확히 같은 역할을하기 때문입니다. 코드가 오늘날 그에게 의미가 없다면 나중에 이해가되지 않아 버그를 수정하는 데 비용이 더 많이 듭니다. 따라서 개발자가 여전히 코드를 기억하면서 오늘날 이해하기 쉽게 만드십시오. 또한 검토자는 개발자가 놓친 버그 또는 누락을 볼 수 있습니다.

불행히도 거의 그것을 원하지 않지만 비즈니스 관점에서 볼 때 의무적이어야합니다.

코드 검토가 이제는 필요하지만 3 년 전만해도되지 않은 곳에서 일하고 있습니다. 그것은 우리의 코드와 다른 사람들이 나중에 코드를 유지하는 능력을 크게 향상 시켰습니다. 경험이 많은 선임의 개발자조차도 QA가 발견하기 전에 코드 검토에서 쉽고 조용하게 수정할 수있는 실수를 저지 릅니다. 또한 원래 개발자 이외의 한 명 이상이 코드를 잘 알고 있습니다.

코드 검토와 마찬가지로 조직이 새로운 것을 시도 할 때 종종 변화에 대한 저항이 있습니다. 코드 검토를 통해 그 중 어느 것도 거의 보지 못했습니다 (공식 QA 부서를 얻는 것이 정서적이었습니다). 가치를보기 위해서는 한두 번의 리뷰 만 있으면됩니다.

다른 사람의 작업에 대한 코드 검토를 수행하거나 코드를 검토 할 때 고려하지 않은 새로운 기술을 발견했습니다. 우리는 코드 검토를 통해 신입 사원의 역량 문제를 비교적 빠르게 발견했으며, 더 중요하게는 코드 검토에 응답 한 방식으로 문제를 발견했습니다. 우리는 두꺼운 프로그래밍에서 지금 완벽하게 명확하게 보이는 부분이 유지 보수에서 명확하지 않은 부분을 배웠습니다. 이것은 귀중합니다. 필요한 것은 유일한 일이 무엇인지에 대한 주석 일 수 있습니다. 보고서가 실제로 정확한 정보를 갖도록 수정해야하는 데이터베이스 설계에 대한 몇 가지 근본적인 오해가 발견되었습니다.

코드 검토에서 내가 본 것은 종종 다른 사람에게 무언가를 설명하는 행위로 인해 개발자가 머리에서 전구를 켜고 검토자가 보지 못한 버그가 있음을 깨닫게됩니다.

또한 소년은 코드 검토를 통해 표준을 따르지 않거나 필수 도구를 사용하지 않으며 다른 사람이 유지할 수없는 코드를 사용하는 카우보이 프로그래머를 식별 할 수 있습니다. 그리고 그것은 그들이 프로그램을 받거나 나가도록 강요 할 수 있습니다.

코드 검토에 가장 강한 사람들은 종종 조직에서 코드를 코드 검토에 통과 ​​할 수 없다는 것을 알고 있기 때문에 조직에서 제거해야하는 사람들입니다.

민첩한 사람은 "코드 검토가 필요하지 않습니다. 페어 프로그래밍을 수행하고 좋은 테스트를 작성하십시오."

코드 검토는 팀을 통해 지식과 모범 사례를 전파하는 좋은 방법입니다. 내 경험상 모든 코드를 검토하고 누가 어떤 코드를 검토하는지 변경하는 것이 좋습니다.

현재 팀에서는 모든 사람의 코드가 동일하게 검토되며, 코드를 해제하기 전에 프로그래머와 검토 자 모두 코드에 만족해야합니다. 이는 더 많은 주니어 개발자, 다른 개발자를 검토하는 주니어 개발자 또는 서로를 검토하는 다른 수석 개발자가 검토하는 상급 개발자에게도 적용됩니다. 검토자가 경험이 없거나 특정 코드를 검토하는 것이 불편하다고 느끼면 다른 개발자 (또는 원래 개발자)와 팀을 이루어 검토를 그룹으로 수행합니다.

저는 20 년 이상 비즈니스에 종사해 왔으며 소프트웨어 회사와 다른 비즈니스를 위해 일했으며이 중 어느 곳에서도 코드 검토 프로세스가 없었습니다. 그러나 나는 그것을 갖는 것의 이점을 이해하고 감사 할 수 있습니다. 본질적으로, 내가 이해할 때, 표준을 준수하는 데 사용해야합니다. 표준은 다른 사람들이 나중에 코드를 더 쉽게 유지할 수 있도록 따라야합니다. 검토 과정에서도 코드 가독성을 검사하여 유지 관리가 코드와 효과적으로 작동하도록 보장 할 수 있습니다.

현재 저는 단일 개발자 인 작은 상점에서 일하고 있습니다. 때때로 우리는 백 로그를 돕기 위해 계약자를 데려 왔습니다. 이러한 계약자 중 적어도 하나는 반드시 내 표준이나 회사 표준을 충족하지 않는 코드를 작성했지만 제대로 작동했으며 적어도 어느 정도 이해할 수있었습니다. 내가이 문제를 경영진에게 지적했을 때, 그들은 신경 쓰지 않았고, 우리가 지불 한 일이 그 일을했는지 ​​알고 싶었습니다. 따라서 그것은 회사에 달려 있으며 깨끗하고 유지 보수가 쉬운 코드가 원하는 제품인지 또는 돈을 위해 잘 작동하는 것을 원하는지 여부에 달려 있다고 생각합니다.

분명히 개발자와 코드를 유지 관리 해야하는 사람은 일종의 표준을 따르는 깨끗한 코드로 작업하고 싶지만 항상 그런 사치를 얻지 못하므로 최선을 다하고 내가 가진 것을 처리합니다. , 때로는 내 표준으로 일부 코드를 다시 작성해야 함을 의미하더라도.

코드 검토를 통해 문제를보다 쉽게 ​​해결할 수있을 때 소프트웨어 수명주기 초기에 결함을 식별 할 수 있습니다. 에서 SmartBear 우리는 개발 피어 코드 검토 도구를 또한 코드 리뷰는 효과적인 만드는 방법에 대한 연구를 많이 했어요. 고객의 데이터를 바탕으로 코드 검토에서 발견 된 결함은 QA에서 발견 된 결함보다 8-12 배 더 저렴합니다. 비용 절감만으로 코드를 검토 할 가치가 있지만 그 이상의 가치가 있습니다. 코드 검토는 팀의 모든 사람이 소프트웨어 개발자로서 배우고 개선 할 수있는 훌륭한 방법입니다.

코드 검토의 효율성을 떨어 뜨릴 수있는 몇 가지 함정이 있으며 조직이 그 중 하나에 걸리는 것처럼 보입니다. 사람들이 아니라 코드에 대해 코드를 검토하십시오. 제목은 코드 검토에서 아무 의미가 없습니다. 권위에 대한 호소 (나는 팀장이기 때문에 내 방식대로해야한다)는 선보다 더 많은 해를 끼친다. 대신 가르치십시오. 선임 엔지니어는 그것이 요구되는 것만이 아니라 왜 자신의 방식으로해야하는지 설명해야합니다. 개념을 설명하는 데 어려움을 겪고 있다면 학습 경험이기도합니다. 두 사람 모두 노력에 대한 더 나은 개발자가 될 것입니다.

모든 코드를 검토하는 코드가 과도하다고 생각합니다. 모든 코드를 검토하는 데 걸리는 시간은 다른 곳에서 더 잘 사용될 수 있습니다. Alterntivley 중요한 코드 및 특히 복잡한 부분은 코드 검토가 필요하지만 모든 코드 줄이 필요한 것은 아닙니다.

내 의견으로는, 주니어 또는 시니어 개발자가 작성한 것이 든 회사가 사용할 코드는 항상 검토해야합니다. 왜? 코드에 몇 가지 버그가 있다면 어떨까요? 이 코드를 사용하는 동안 프로그램이 중단 된 경우 어떻게해야합니까? 이러한 일이 발생하지 않도록 사용하기 전에 모든 코드를 검토해야합니다.

그러나 코드를 검토하지 않는 회사는 어떻습니까? 그들은 아마도 소비자에게 "충돌";-)이라고 말하면서 많은 기술 문제와 많은 기술을 가진 회사 일 것입니다.

모든 질문에 대답하겠습니다.

• 예, 검토 프로세스가 필요합니다.
• 왜? 내가 위에서 언급 한 이유 때문에.

Code Review : Code Review 프로세스는 모두에게 중요한 과정이어야합니다. 코드 검토 수행 으로 인해 혜택을받는 사람과 혜택을받는 사람에 대해 설명하겠습니다.

1. 코드 검토 수행으로 회사가 얻는 이점 : 코드를 자주 검토하는 경우 회사는 최종 제품을 훨씬 더 최적화 된 방식으로 얻을 수있어 시장에서 브랜드 이름을 얻는 데 도움이되고 회사는 현재 CMMI 레벨을 얻거나 향상시킵니다 .

2. 코드 검토의 수행으로 인한 팀 리더의 이점 : 우리 모두가 알듯이 교사는 학생들의 답변을 더 자주 검토하기 때문에 실수를 쉽게 식별 할 수 있으므로 아이디어를 얻을 수 있습니다. 잘못 될 가능성이 있습니다. 마찬가지로 팀 리더도이 영역에서 무엇이 잘못되었는지 알고 있습니다. 이를 해결하는 방법과 팀 리더가 주니어 개발자의 뉴스 아이디어를 얻도록 도와줍니다.

3. 코드 검토의 수행으로 주니어 개발자의 이점 : 주니어 개발자는 코드 검토 프로세스에 대한 아이디어를 쉽게 얻을 수 있으며 코딩 표준을 얻을 수 있습니다. 그들은 더 높은 수준의 포스트에 올 때 특히 도움이 될 수있는 코딩의 표준화를 배울 것입니다.

그래서 결론은 코드 검토는 모든 사람에게 매우 중요한 프로세스입니다. 팀 구성원도 마찬가지입니다. 코드에서 부주의 한 실수를 저 지르십시오.

버그로 인해 코드 (검토)를 확인하기 전이나 나중에 아이디어를 방해하거나 이해하기가 너무 영리하고 어려워 지거나 허용되는 표준 관행을 따르지 않는 것의 차이점은 무엇입니까? 당신의 자아입니까?

자격이없는 자격을 갖춘 팀원이 제대로 구현하지 않았기 때문에 코드 검토의 장점이나 그 밖의 다른 것을 무시할 수 없습니다. Code Review는 소수의 슈퍼 프로그래머 만 파악할 수있는 매우 복잡한 프로세스가 아닙니다. 나는 스스로 편집 할 수 있거나 시간을 가지고있는 많은 프로그래머 나 전문 작가가 있는지 잘 모르겠습니다.

몇 달 후 코드 라인으로 돌아와서 내가 무슨 생각을했는지 궁금한 적이 있습니까? 코드 검토를 통해 더 잘 잡을 수 있습니다. 당신은 그것을 잡았고 당신은 당신이 한참 전에 프로그래머보다 약간 더 낫습니다-나는 희망합니다.

IMO는 모든 개발자에게 코드 검토가 필수적 이지만 검토를 수행하는 사람들이 자신을 유능하게 할 때만 필수입니다 . 과거에는 리뷰에서 거부 된 코드를 보았습니다. 왜냐하면 나는 따라 SOLID가지 않았고 일부 종속성 주입을 수행하고 논리적 디자인에 따라 네임 스페이스와 폴더로 코드를 구성했으며 작은 단위 테스트 세트를 포함 시켰기 때문에 코드를 확인하십시오. 이 코드는 "너무 복잡하다"고 거부되었고, 회사가 코드를 작성하는 방식이 아니기 때문에 모든 것을 하나로 묶고 테스트를 제거하는 클래스를 사용하라는 지시를 받았습니다.

이와 같은 코드 검토는 가치가 없지만, 유능한 팀과의 코드 검토는 종종 ​​디자인에 대해 무언가를 밝히거나 (예 : X와 Y를 수행해야하지만 Z는하지 않아야하는 이유) 실제 결함을 표시 할 수 있습니다 (예 : X를 수행하면 Y가 실패하게됩니다) 잘못된 이유로).

물론 코드 검토는 필요 하지 않습니다 . 그런 다음 테스트, 지속적인 통합, 소스 제어, 고객 참여, 프로파일 링, 정적 분석, 적절한 하드웨어, 원 클릭 빌드, 버그 추적 등이 없습니다.

코드 리뷰와 함께 위에서 언급 한 것은 소프트웨어 품질을 보장하는 도구입니다. 기술, 운, 시간 및 결심의 조합으로; 이 소프트웨어를 사용하지 않고도 양질의 소프트웨어를 제공 할 수 있지만 그렇지 않을 가능성이 높습니다 .

귀하의 시나리오에서는 혼란 스러울 것이 없습니다. 모든 조직이 모든 모범 사례에 빠지는 것은 아닙니다. 그들은 동의하지 않을 수도 있고, 구현하는 다른 모범 사례와 충돌 할 수도 있고, 현재 시점에서 구현의 오버 헤드가 너무 크다고 생각할 수도 있습니다. 그들의 상황에 따라, 그렇게하는 것이 옳을 수도 있고, 거짓 경제를 만들고있을 수도 있습니다. 일부 도구 (예 : 소스 제어)의 경우 투자 회수 / 노력 비율이 너무 좋아 사용하기가 쉽지 않습니다. 다른 사람들에게는 덜 명확합니다.

코드 검토가 상당한 오버 헤드를 유발하는 관행이라는 데는 의심의 여지가 없습니다. 이 때문에 조직은 오버 헤드를 전혀하지 않거나 특정 상황 (예 : 주니어 팀원 또는 특히 털이 많은 변경)에서만 오버 헤드를 최소화하려고합니다. 그것이 비용보다 더 많은 돈을 갚는 것 (버그 잡기, 기술 부채 감소 또는 지식 공유)을 항상 상실하는 것은 분명하지 않습니다. 이 투자금의 대부분은 정량화하기 어렵지만, 조직에서 검토하는 데 소요되는 시간을 계산하는 것은 매우 쉽습니다. 정량화하기에 가장 쉬운 비트 (버그 수 감소)는 다른 요인 (예 : "버그가 적을수록 성숙함")에 속하기 쉽습니다.

우리는 터키에서 온라인 축구 게임을합니다. 많은 사용자와 게임 마스터가 기능에 도움을줍니다. 또한 필요한 기능에 대한 의견을 제공합니다. 따라서 많은 사용자가 있다면 배지를 돕거나 얻기 위해 기능 테스트를 수행 할 수 있다고 생각합니다. 포럼, 지원 팀 및 개인 테스트 환경을 갖춘 개발자, 게임 마스터 및 사용자의 공동 작업은 소셜 프로젝트를 만듭니다.

개발 팀 간의 코드 검토 및 공유 경험이 반드시 필요하지만 중요하지 않은 경우 스스로 강요 할 필요는 없습니다.

자세한 제 2 자 검사 방법은 프로세스의 민첩성 또는 폭포수에 관계없이 수명주기에 달려 있다고 생각합니다. 높은 수준의 디자인 / 검사와보다 세부적인 수준의 디자인 검사를하는 것이 합리적이라고 생각합니다. 팀원 몇 명을 조사하는 것도 좋은 일이라고 생각합니다.

그들은 경험이 거의 없기 때문에 절대적으로 필요합니다.