동료 검토 또는 쌍 프로그래밍, 아니면 둘 다?[닫은]

Question

• 코드 피어 리뷰에 참여하거나 페어 프로그래밍 연습에 참여하시나요? 아니면 둘 다에 참여하시나요?
• 이러한 관행을 사용하여 소프트웨어 품질이 향상되었음을 입증할 수 있었습니까?
• 실습 과정에서 어떤 이점과 단점을 발견했습니까?
• 구현하는 데 어떤 장애물이 있었나요?

내 경우에는 개발 팀이 다양한 소프트웨어 아티팩트(요구 사항 분석, 테스트 계획, 코드 등)에 대한 동료 검토를 진행했습니다.동료 프로그래밍은 옵션으로 간주되지도 않았습니다.

동료 검토 관행은 위에서부터 밀려났고 개발자들은 결코 이를 받아들이지 않았습니다.우리는 활동에서 지표를 수집하는 외부 SQA 그룹을 갖고 있었지만, 그 노력이 미성숙했기 때문에 그 수치는 꽤 가치가 없었습니다.이것이 작업을 수행하는 "공식적인" 방법이 된 지 몇 년이 지난 후, 개발자들은 규정된 절차를 집합적으로 무시하게 되었습니다.

이제 버그가 수명주기에 개입되는 시점에 대한 가시성이 떨어집니다.그리고 동료 검토를 수행하지 않으면 팀의 전문성이 높아집니다. 시스템의 전문 영역 외부에 있는 구성 요소의 요구 사항/논리를 실제로 아는 사람은 아무도 없습니다.

동료 리뷰나 페어 프로그래밍, 특히 성공 사례에 대한 귀하의 경험을 아는 것이 중요할 것입니다.

Answer 1

내가 젊고 어리석었을 때, 내가 처음으로 한 일 중 하나는 형식화되지 않은 텍스트로 버려진 긴 PDF 파일에서 특정 필드를 꺼내는 파서를 만드는 것이었습니다.나는 어떤 형태의 정규식을 사용할 만큼 충분히 알고 있었지만 정규식에 대해서는 그 일을 잘 수행할 만큼 충분하지 않았습니다.며칠 후 나는 작업을 마쳤지만 동료 검토에서 내가 더 잘할 수 있었고 내가 만든 것은 쓰레기라는 사실을 알고 압도당했습니다.나는 내가 바보가 아니라는 것을 증명하기 위해 어휘 분석을 수행하는 방법을 배웠지만, 동료 검토 과정이 형편없었다고만 말씀드리겠습니다.내 실패에 대해 춤을 추려면 선배가 필요하지 않았습니다. 멘토가 필요했고 동료 평가를 할 때마다 그 점을 스스로 상기시켜 왔습니다.

나는 문앞에서 자존심을 확인할 때 동료 평가를 좋아합니다.(저도 포함됩니다!) 이 세상에는 유한한 시간이 있고, 배우고 할 수 있는 시간은 한정되어 있습니다.좋은 동료 검토를 통해 지식을 확장하고 더 짧은 시간 내에 더 많은 작업을 수행할 수 있습니다.문제는 항문 구문 검사를 통해 상황이 저하될 때 발생합니다.

이 때문에 몇 가지 규칙이 있습니다.저는 우리가 자동화할 수 있는 어떤 것도 동료 검토하지 않습니다.맞춤법 검사를 실행하고 코드 미화 프로그램을 실행하세요.FXCop과 같은 기능을 사용할 수 있는 경우 이를 실행하고, 표시된 대로 수행하거나, 그렇지 않은 타당한 이유가 있어야 합니다.그런 다음 코드가 어떻게 구성되어 있는지, 어떻게 작동하는지, 그리고 코드를 개선하기 위해 할 수 있는 일을 살펴볼 수 있습니다.이런 방식으로 문제를 해결하는 방법과 누군가가 그렇게 생각하는 이유에 대한 다른 관점을 얻을 수 있습니다.때로는 다른 방법이 더 좋지 않을 때도 있고, 때로는 새로운 솔루션이 환상적이어서 남은 프로그래밍 수명 동안 사용할 수 있는 것이기도 합니다.검토가 완료되면 그게 전부입니다. 나는 그것을 당신에 대한 예로 사용하지 않습니다.그것으로부터 당신이 무엇을 할 것인지 배우는 것은 당신의 몫입니다.나는 두려움이나 위협으로 관리하지 않을 것입니다. 당신은 똑똑한 사람이고 그것을 보여주도록 하겠습니다.

Answer 2

우리는 최소한 다른 사람의 눈을 거치지 않고 코드가 프로덕션에 들어가지 않도록 노력합니다.
일반적으로 이는 코드 검토를 의미합니다.우리는 리뷰가 코드 작성의 본질적인 부분이라는 것을 팀 내에서 습관화하려고 노력합니다.글을 쓰고 다른 사람에게 의견을 물어보세요.
또한 충분한 인력이 있는 프로젝트(작업의 규모가 적절한 경우)에서는 페어링 프로그래밍을 시도합니다.
나는 우리가 이것의 이점을 확실히 보았다고 말해야 합니다.우선, 이는 팀의 후배 개발자를 멘토링하는 좋은 방법입니다. 코드를 검토하면 더 나은 작업이 무엇인지 보여줄 수 있고, 그들과 짝을 이루면 더 나은 작업 방법, 숙련된 사람들의 방법을 알게 됩니다. IDE를 더 잘 사용하는 방법에 대해서도 생각해보세요.
또한 코드가 어떻게 보이는지 아는 한 전체 팀의 동기화를 유지합니다.
게다가 이는 모든 사람의 기쁨과 개인적인 발전을 증가시킵니다. 코드에 대해 이야기하고 추론할 수 있는 팀이 더 나은 팀, 계속 학습하고 공유하는 팀입니다.

주의해야 할 사항:

• 페어링할 때 선배들이 후배들에게도 프로그래밍을 허용하도록 하세요.
• 사람들이 작은 작업에 짝을 이루도록 하지 마십시오. 대개 시간을 낭비합니다.
• 쌍이 어떻게 지내는지 관찰하십시오(쌍을 강제로 함께 결합시키지 마십시오).
• 가끔씩 쌍을 다시 섞는 것을 기억하세요
• 리뷰를 자존심과 일치시키지 마십시오. 사람들이 다른 사람을 압도하도록 두지 마십시오.

Answer 3

동료평가는 다음과 같아야 한다 필수적인.

다양한 규모의 팀 내에서 이에 접근하는 다양한 방법을 논의하는 수많은 기사와 책을 읽고 찾을 수 있지만 경험에 대해 문의하는 것 같습니다.

개인적으로 피어 리뷰는 재미있어야 한다고 생각합니다.음식을 제공하고 분위기를 유쾌하게 유지합니다.이는 실제로 개발자/프로그래머가 판단할 기회가 아닌 서로에게서 배울 수 있는 시간으로 간주되어야 합니다(그리고 우리 모두는 모든 프로그래밍이 타고난 판단 유전자를 가지고 태어난 것처럼 보인다는 것을 알고 있습니다).나는 리뷰를 공개된 시간의 1/3 또는 1/4로 구성하는 데 감사하거나 도움을 주는 경향이 있습니다.즉, 그룹이 함께 모여 한 사람이 현재 프로젝트와 관련이 없는 작업 중이거나 검토 중인 프로젝트를 발표할 때를 의미합니다(마감일이 어렵다는 것을 알고 있지만 시도해 보세요).

창작자들은 일반적으로 영감을 얻기 위해 함께 모여 현재 관심을 갖고 있는 그림, 디자인, 아티스트를 전시합니다.현실적으로 영감은 리뷰에서 육성하고자 하는 주요 개념이어야 합니다.게다가 사람들은 동료 개발자들이 이전에 알아차리지 못했던 일들을 자연스럽게 알아차립니다.“와, 그럼 한 줄의 코드로 그걸 할 수 있었나요?시원한." 개발자가 자신이하는 일, 작업중인 작업 및 어떻게 진행되는지에 대해 영감을 얻고 동기를 부여하는 것은 Pecking Order와 Rank를 설정하기 위해 동료 검토를 사용하는 것보다 배당금을 더 많이 지불 할 것입니다.

마지막으로 실제로 "검토" 부분이 나오지만 이는 피할 수 없는 사실입니다.더 나은 개발자는 잘못된 코드를 보게 될 것이며, 충분한 검토를 거친 후에는 가난한 코더가 한 단계 더 발전하거나 잊어버릴 때입니다.

상황을 긍정적이고 체계적으로 유지한다면 대개 좋은 경험이 될 것입니다.

페어 프로그래밍을 다루는 것을 거의 잊었습니다.설정이 더 어렵습니다.분명히 약한 프로그래머 두 명이 함께 일하도록 할 수는 없습니다. 아니면 백만 ​​개의 타자기와 함께 백만 마리의 원숭이를 배치하는 것이 나을 수도 있습니다.더 강한 사람과 약한 사람을 배치하고 두 사람 모두에게 개인적으로 인센티브를 제공하십시오.약한 사람은 개선이 보상받을 수 있다는 것을 알아야 하며(그러한 인센티브가 필요한 경우), 더 강한 프로그래머는 진정한 리더가 좋은 멘토로부터 시작한다는 것을 알아야 합니다.약한 개발자가 입력하고 있는지 확인하십시오.그 반대도 아니고 프리젠테이션이 되어 "하품"누군가는 경험을 통해 아무것도 얻지 못할 수도 있습니다.

Answer 4

나는 애자일 코칭을 많이 해왔고 사람들이 페어 프로그래밍의 "오명"을 극복하도록 돕기 위해 이를 "실시간 코드 및 디자인 검토"라고 부릅니다.사람들은 그런 용어로 개념을 더 잘 이해하는 것 같습니다.

Answer 5

내가 가진 유일하게 직접적으로 관련된 경험은 동료 디자인 리뷰(오래 전)입니다.그리고 그들은 빨랐다.문헌을 읽어보면 좋은 리뷰의 몇 가지 규칙(사람에 집중하기, 철자법에 집중하기, 명확한 결과 없음 등)을 위반한 것이 분명했습니다.등) 그러나 그것이 우리가 아는 전부였습니다.

하지만 그 이후로 나는 많은 오프라인 코드 검토에 참여해 왔습니다.

프로젝트에 따라 "라이브" 지점에 체크인하기 전에 또는 체크인 후 임의의 시점에 명령이 지정되었습니다.4개 프로젝트 중 3개 프로젝트에서 처음에는 필요악으로 받아들여졌지만 나중에는 귀중한 입력으로 받아들여졌습니다.

작업 검토의 이점은 모든 사람이 더 나은 코드를 작성하도록 하고 최고의 코더에게도 멘토링을 제공하는 것입니다. (솔직히 말하면, 당신의 유능한 프로그래머가 실제로 읽기 쉬운 코드를 작성합니까?) 일단 경험이 부족한 직원을 설득하여 자신은 그렇지 않다고 말하도록 설득할 수 있습니다. 뭔가 이해하세요. 당신은 멀리 있습니다.일부 인기 있는 사진은 허풍을 떨겠지만 실제 최고의 사진은 자신이 작성한 내용에 대해 생각하고 실제로 변수 이름이나 레이아웃을 변경하고 심지어 설명을 추가할 수도 있습니다.

네 번째 프로젝트는 '임의의 시간'을 검토하는 부과된 계획을 사용하며 기술 책임자가 아직 참여하지 않았습니다(깨진 팀?)

---

설명하는 두 가지 관행은 공식적인 접근 방식입니다.그들은 모든 성격과 그룹에 잘 작동하지 않습니다.

팀이 실제로 할 수 있다고 생각되는 일을 시도해보고 개선할 수 있는지 확인하세요.

코드를 더 자세히 살펴보고 나면 뒤돌아보고 싶지 않을 것입니다.

Answer 6

• 예, 우리 회사는 동료 코드 검토를 사용합니다.우리는 이를 Over-The-Shoulder 검토로 수행하고 팀의 테스터를 회의에 초대하여 변경 사항을 더 잘 이해할 수 있도록 합니다.

• 여러 연구에서 입증된 것처럼 코드 검토에는 확실한 이점이 있습니다.우리 회사의 경우 지원 통화 횟수가 감소하고 보고된 버그 수도 감소함에 따라 코드 품질이 향상되는 것이 분명했습니다.메모:여기에서 얻을 수 있는 이점 중 일부는 Scrum을 구현하고 Waterfall을 포기한 결과였습니다.아래에서 스크럼에 대해 자세히 알아보세요.

• 코드 검토의 이점은 구조 및 코딩 표준에 적용되므로 제품이 더욱 안정적이고 유지 관리하기 쉬운 코드가 될 수 있으며, 이를 통해 개발자는 "해결" 버그 및 기타 생산 문제보다는 새로운 기능에 더 집중할 수 있습니다.코드 검토가 "올바르게" 수행된다면 실제로 어떤 단점도 없습니다.아래의 "올바른 방법"에 대해 자세히 알아보세요.

• 코드 검토를 구현하는 동안 극복해야 할 장애물 중 일부는 "형"이 나를 지켜보고 있다는 생각과 완벽한 코드가 없다는 것은 고문과 고통을 의미한다는 생각입니다.개발자들이 서로를 신뢰하게 만드는 것은 때로 어려운 일입니다. 특히 "순서를 따지는 것"이나 "너보다 더 신성한" 태도를 취하고 여러분의 노력을 현미경으로 관찰하는 경우에는 더욱 그렇습니다.신뢰는 이러한 문제를 해결하는 열쇠입니다.개발자는 코드 실수로 인해 동료나 경영진으로부터 처벌을 받지 않을 것이라고 믿어야 합니다.그것은 모든 사람에게 일어납니다.문제를 기록하고 해결한 후 계속 진행하세요.

스크럼스크럼 방법론 사용의 이점 중 하나는 개발 주기("스프린트")가 짧다는 것입니다."스프린트"의 기간은 조직에 가장 적합한 것이 무엇인지에 따라 결정되며 약간의 시행착오가 필요하지만 실제로는 4주 이상의 반복이 있어서는 안 됩니다.이점은 개발자가 매일 의사소통하고 프로젝트 초기에 문제를 의사소통해야 한다는 것입니다.이는 처음에 개발 부서에서 채택되었으며 스크럼의 이점이 광범위해짐에 따라 회사의 모든 영역으로 확산되었습니다.자세한 내용은 다음을 참조하세요. http://en.wikipedia.org/wiki/SCRUM 또는 http://www.scrumalliance.org/ .개발 반복 횟수가 작을수록 코드 검토 프로세스에서는 더 작은 코드 조각을 검토하므로 몇 시간 또는 며칠 간의 공식 검토보다 검토에서 문제를 발견할 가능성이 더 높습니다.

“올바른 길”"올바른 방식"으로 수행된 코드 리뷰는 완전히 주관적입니다.그러나 나는 개인적으로 그러한 리뷰가 비공식적이고 어깨 너머로 검토되어야 한다고 믿습니다.검토의 모든 참가자는“왜 그렇게 했습니까?”와 같은 진술로 검토 된 사람을 개인적으로 공격하지 않아야합니다. 또는“무슨 생각을 했습니까?” 등.이러한 유형의 댓글은 동료 간의 신뢰를 약화시켜 적개심으로 이어지며, 솔루션을 코딩하는 최선의/올바른 방법에 대해 몇 시간 동안 논쟁을 벌이게 됩니다.개발자는 완전히 동일하게 생각하거나 코딩하지 않으며 문제에 대한 해결책은 다양하다는 점을 명심하세요.
어깨 너머로 리뷰에 대한 약간의 설명입니다.이는 원격 데스크톱 공유(여기서 선택)을 통해 수행하거나 직접 수행할 수 있습니다.그러나 개발자에게만 국한되어서는 안 됩니다.우리는 일반적으로 팀당 두 명의 개발자, 테스터, 문서 담당자 및 제품 소유자로 구성된 전체 스크럼 팀을 초대합니다.개발자가 아닌 모든 사람은 변경 사항이나 새로운 기능을 더 잘 이해하기 위해 존재합니다.그들은 자유롭게 질문하거나 의견을 제공할 수 있지만 코딩 결정이나 의견을 내릴 수는 없습니다.초기 요구 사항이 시나리오를 놓쳤을 수 있으므로 프로젝트 방향을 변경할 수 있는 특정 질문이 요청될 수 있으므로 이는 효과적이었습니다. 그러나 이것이 바로 애자일의 전부인 변화입니다.

제안스크럼과 코드 리뷰를 의무화하기 전에 조사해 볼 것을 적극 권장합니다.더 나은 품질의 제품을 얻기 위해 각각에 대한 기본 규칙을 만들고 이를 문화의 일부로 구현하십시오.그것은 자연스러운 프로세스의 일부가 되고 모든 수준에서 통합되도록 문화의 일부가 되어야 합니다. 이는 낮은 품질, 마감 기한 준수 및 좌절에서 더 나은 품질의 제품으로의 패러다임 전환, 좌절 감소 및 정시 납품 증가이기 때문입니다. .

Answer 7

페어 프로그래밍에서 github의 PR 리뷰로 이동한 후의 비교 분석입니다.

현재 PR 검토 프로세스에서 우리 팀이 따르는 사항을 단계별로 나열하는 데 중점을 두고 있습니다.

“코드 리뷰 vs 페어 프로그래밍” https://blog.mavenhive.in/pair-programming-vs-code-reviews-79f0f1bf926