코드 리뷰에서 긍정적 인 피드백은 얼마나 중요합니까?

코드 검토 중에 코드 의 좋은 부분과 그것이 좋은 이유 를 지적하는 것이 중요 합니까? 긍정적 인 피드백은 검토중인 개발자 및 검토에 참여하는 다른 사람들에게 유용 할 수 있습니다.

우리는 온라인 도구를 사용하여 검토를 수행하므로 개발자는 커밋 된 코드에 대한 리뷰를 열 수 있고 다른 사람들은 지정된 기간 (예 : 1 주) 내에 코드를 검토 할 수 있습니다. 다른 사람들은 코드 나 다른 검토 자의 의견에 의견을 제시 할 수 있습니다.

긍정적 인 피드백과 부정적인 피드백 사이에 균형이 있어야합니까?

피어 코드 리뷰를 사용하여 품질 및 사기 개선
http://www.slideshare.net/SmartBear_Software/improve-quality-and-morale-using-peer-code-reviews

모두가해야 할 일 : 코드 검토
http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

이 두 기사 모두 코드 검토의 목적 중 하나는 오류를 찾는 것이 아니라 좋은 개발 기술에 대한 지식을 공유하는 것이라고 설명합니다.

그래서 나는 그것이 매우 중요하다고 말합니다. 누가 회의에 가고 싶고 비난 만 받고 싶어합니까?

코드 검토를 할 때 나는 독백을 실행하는 경향이 있으므로, 내가 읽고있는 것을 이해하기 때문에 많은 "Ok, 나는 그것이 무엇을하는지 알 수 있습니다. "좋아요 .. 그리고 그 작품은 두 가지 모두에 달려 있습니다."

저는 이런 식으로 "우라라 너무 큽니다!"라고 생각하지 않습니다. 아주 지루한 코드 일 수도 있지만, 다른 사람이 실제로 여러분의 의견을 파싱하고 이해하는 것은 긍정적 인 피드백의 형태입니다. 피드백은 "이 코드는 의미가 있습니다."라고 이해하지 못하는 부분이 생겼을 때 설명을 요청하고 이해할 때 "아, 알았어요"라고 외칩니다.

우리는 모두 다른 사람들이 코드를 이해하기를 원하기 때문에 이해의 단순한 전달이 다른 엔지니어에게 찬사를 보냅니다.

즉, 우수하거나 긍정적 인 특성을 가진 코드의 일부를 볼 경우 (심지어 지루한 사소한 코드라도 최소한의 형태이면 좋을 수 있음) 이러한 특성을 분명히 나타내는 경향이 있습니다. 큰!" "이것은 최소한의 구현이라고 생각합니다"또는 "좋아요,이 복잡한 알고리즘에는 많은 주석이 있습니다", 코드의 속성에 중점을 두는 것은 본질적인 장점이나 나쁜 점이 아닙니다.

엔지니어가 아래를 보거나 받침대에 눌린 느낌이 들지 않도록하기 위해 코드 검토에서 코드에 "좋은 점"또는 "나쁜 점"을 표시 할 때마다 어떤 것이 나쁘다고 말하지 말고 오히려 원인과 결과에 대해 이야기하십시오. 그들의 코드.

"이 부분은 의미가 있습니다. 여기에는 마법의 숫자가 있습니다. 그 가치의 의미는 다음 엔지니어가 이것을 이해하지 못할 것입니다."

"여기에 DI 컨테이너가 있어도 해당 저장소와의 연결이 느슨합니다."

"여기에 정적 사전이 있는데, 여러 스레드가 해당 사전에 닿으면 일부 경쟁 조건이 발생할 수 있습니다."

좋은 점이나 나쁜 점은 없지만 엔지니어가 변경 해야하는지 여부는 코드를 검토하는 엔지니어가 이해할 수 있습니다. 분명히 코드 검토를 yay 또는 nay로 끝내야하지만, 그 과정에서이 문장을 누적하면 nay가 "원합니다. 체크인하기 전에 고정 된 매직 넘버 "

코드 검토에서 내가 좋아하고 "충분한"코드 이상을 넘어선 무언가를 본다면 긍정적 인 피드백을 줄 것입니다.

일반적으로 누군가가 실제로 "와우, 정말 좋습니다!"라고 말하는 조각 코드를 작성한다고 생각합니다. 그렇습니다. 긍정적 인 피드백이 중요합니다. 그것은 다른 사람들이 자신이 한 일을 즐겼다는 것을 저자에게 알리고 다시 시도해야합니다. 하지만 지침과 표준 관행을 따르는 것 이상이어야합니다. 누군가가 멋지게 들여 쓰기 또는 상용구 주석을 추가하여 칭찬을 제공하면 막대가 다소 낮아질 수 있습니다.

이것은 일반적인 관리 및 인간 상호 작용 질문이므로 프로그래밍 질문이 아닙니다. 코드 검토에서 긍정적 인 피드백은 모든 종류의 검토에서 긍정적 인 피드백만큼이나 중요합니다.

이것이 필요한지 여부와 필요한 정도는 말하려는 사람의 성향과 정서적 구성의 기능입니다. 어떤 사람들은 칭찬과 결합 될 때 훨씬 더 효과적으로 교정에 응답합니다. 다른 사람들은 시정을 받으면 칭찬이 성실하지 않다고 생각합니다.

일반적인 공식은 때때로 "피드백 샌드위치"라고합니다. 아이디어는 전체적인 톤을 긍정적으로 유지하면서 동시에 부정적인 피드백을 받도록하는 것입니다. 이를 통해 검토를 기대할 때 스트레스를 예방하고 나중에 스스로 흡수되는 브 로딩을 방지 할 수 있습니다. 생산성과 품질면에서 매우 중요합니다. 이것은 단지 감동적인 감정적 인 호그 워시가 아닙니다. 인간의 행동 101입니다.

다시 말하지만, 당신은 당신이 일하는 사람을 알고 그들이 무엇에 반응하는지 이해해야합니다. 사람들을 상대하는 것은 경영진의 문제이며 훌륭한 관리자는 사람들이 어떻게 대응해야하는지 알고 있습니다.

긍정적 인 피드백은 매우 중요하며 개인적, 현실적 역학에서 비롯된 것입니다. 우리는 모두 몇 시간, 며칠, 몇 주, 몇 달 동안 앉아서 코드를 작성하며 대부분의 사람들은 우리가하는 일에 자부심을 가지고 있습니다. 코드 리뷰는이를 보여줄 수있는 기회입니다.

코드 검토에 참여하고 기대할 수있는 최상의 결과가 "코멘트 없음"(즉, 긍정적 인 피드백의 균형이 없음) 인 경우 회의의 제목은 "사람들이 당신이 얼마나 나쁜 것으로 생각하는지 찾아보기"라는 제목으로 쉽게 표시 될 수 있습니다. 결과적으로 개발자는 코드 검토에 짜증을 내기 시작하거나 심지어는 무서운 코드 검토를 시작하게되며 이는 분명히 팀에게 해가됩니다. 개발자는 자신의 코드를 검토하는 것을 "잊어 버릴 것"또는 학습 된 무력감을 개발하고 이러한 회의에서 폭파되는 일이 없도록 모든 작은 일에 대해 어떻게해야하는지 끊임없이 비평가들에게 물어볼 것입니다.

이론적으로 나쁜 점을 고치고 모든 사람에게 감정을 남기라고 요구하는 것이 가장 논리적이라고 말하는 것은 모든 것이 좋으며 좋은 일이지만, 담당자 개발자를 담당하는 사람은 대인 관계의 청각 장애가되는 것과 같은 태도입니다. 이론은 제쳐두고, 우리는 인간이며 인간은 때때로 명목상의 것까지 가볍게 두드리고 싶어합니다. 그 물건이 중요합니다.

나란히 또는 팀 검토를 수행하는 것이 더 중요합니다. 서면 검토에서 좋은 소식은 없습니다. 목표는 코드를 프로덕션으로 만드는 것입니다. 그것이 당신의 코드라면, 당신은 자신에 대해 기분이 좋을 것입니다.

코드 검토는 팀의 멘토링 및 관리에 도움이되는 정보 소스로 사용되어야합니다. 코드 검토 데이터베이스를 어지럽히 지 않고 긍정적 인 피드백을 줄 수있는 많은 기회가 있습니다. 다른 사람들과 공유하기 위해 예제를 꺼낼 수 있습니다.

코드 이외의 개발자를 검토하는 것이 훨씬 더 많습니다. 하이재킹 코드 검토 시간은 앱이 문 밖으로 나가는 데 비생산적 일 수 있습니다. 코드 검토 외부에서 개발자를 도울 수있는 시간을 설정한다고해서 코드 검토 피드백을 제외해야하는 것은 아닙니다.

코드에 대한 긍정적 인 피드백을 제공 할 수있는 유일한 방법은 "백핸드 칭찬"을 피하지 않으면주의해야합니다. 대부분의 사람들은 이것에 익숙합니다 ... "훌륭한 직업이지만 ..."과 같은 문구로 표시됩니다.

모든 사람이 이것이 프로그래머에 대한 개인적인 검토가 아니라 전체 시스템의 품질에 대한 코딩 연습을 개선하려는 노력이라는 태도로 회의에 오면 모든 피드백은 "좋은"피드백입니다. 코딩 연습을 개선하는 방법을 강조하는 피드백은 문제를 처리하는 유용한 새로운 방법을 강조하는 피드백만큼 중요합니다.

최소한 그 길이에 도달하지 않으면 검토 프로세스 내에서 "좋은 피드백, 나쁜 피드백, 좋은 피드백, 나쁜 피드백"주기를 수행하기 위해 노력하는 것은 단지 같은 백핸드 칭찬 느낌. 좋은 피드백을 강요하지 말고, 좋은 노력을 강화하고, 지식에 구멍을 뚫으십시오.

몇 년 동안 가장 많이 배운 문구 :

• "이것은 흥미로운 접근법입니다. [다른 사용 사례]를 수용해야한다면 어떻게됩니까?"
• "좋은 시도! 우리가 이미 그렇게하는 방법이 있다는 것을 알고 있습니까? 어쩌면 어떤 접근법이 더 효율적인지 확인하기 위해 벤치마킹을해야 할 것입니다."

코드 리뷰에서 가장 마음에 든 워크 플로는 다음과 같습니다.

1. 개발자는 메일 링리스트 / 온라인 도구에 패치를 제출합니다.
2. 관심이 필요한 사람은 패치를보고 개선을 제안합니다.
3. 개발자는 # 1로 돌아갑니다
4. 개선이 필요하지 않은 경우 사람들은 "좋은 일을 해주십시오." <-긍정적 인 피드백. 허용되는 모든 코드가 좋습니다. 사람들이 변경 사항을 말하지 않아도 될수록 더 잘할 수 있습니다.
5. 개발자는 커밋하고 다음 항목으로 넘어갑니다.

일반적으로 새로운 개발자는 코드베이스에 익숙해 짐에 따라 더 많은 '정확한'피드백을 받게됩니다.

이 방법의 장점은 다음과 같습니다.

1. 모두가 모든 일을 알고 있습니다. 독점 또는 미스터리 커밋에 대한 지식이 없습니다.
2. 모두는 다른 사람의 피드백을 통해 배웁니다. 이것은 중요합니다. 페어링하는 동안 얼굴을 보며 대화하는 두 사람 사이에서만 피드백이 발생하면 회의실 반대편에있는 누군가가 메일 링리스트에서 발생했을 때와 같은 방식으로 혜택을받지 않습니다.
3. 다른 개발자는 일반적으로 버전 관리에 들어가기 전에 일부 버그를 발견 할 수 있습니다.

나는 이것에 전혀 동의 할 수 없다. 우수하지만 설명하기 어려운 단순한 코드를 작성할 수있는 Good Development Techniques와 소위 Ninja Coders의 차이점은 무엇입니까? 소프트웨어 개발은 ​​(IMO) 현재 유지 보수성과 이해의 편의를 위해 감각과 교활함을 피하는 최저 공통 분모 원칙입니다. 너무 위험하다.

리뷰에서 코드를 본 적이 있는데 '아 멋지다'고 생각했던 시간을 생각할 수 없습니다. 이와 같은 코드가 발생하면 Cool-Yet-Acceptable 캠프에 빠질 것이라고 가정 할 수 있습니다.

또한 긍정적 인 피드백을받지 못한 사람들이 너무 열심히 노력하고 결국 "믿어주세요!"

코드 검토는 팀간에 코드 품질 책임을 전파하기 위해 존재합니다. 즉, 심각한 문제가 나중에 발생하면 개별 개발자를 비난 할 수 없습니다. 그것을 사용하여 문제를 찾고, 그것을 유지 해야하는 경우를 대비하여 이상한 물건의 원래 개발자로부터 설명을 얻는 데 사용하십시오. 개인적으로 부정적인 피드백을받는 데 더 관심이 있습니다. 고객은 코드의 차가움에 신경 쓰지 않고 원하는 코드 만 수행합니다.

백 슬랩을 술집에 남겨 두십시오.

그것은 나에게 중요하다. 나는 양성을 위해 솜털 같은 말이나 양성을 원하지 않습니다. 내가 작성한 모든 코드가 깨지기 쉬운 경우 이유를 말하고 수정하고 배우자. 그러나 내가 옳은 일을하면 한 번만 듣는 것이 좋습니다. 나는 "올바른"모든 일에 대해 긍정적 인 강화를 필요로하지 않지만, "X, Y, Z를 향상 시키되 나머지는 좋아 보인다"고해도 문제가됩니다.

정직한 피드백만큼 중요하지는 않습니다. 저는 대기업을 위해 일하고 있으며, 프로그래머가 열심히 노력하거나 좋은 사람인지, 아니면 보통 좋은 코드를 작성하는지에 대해서는 고객이 신경 쓰지 않습니다! 작동하는 소프트웨어가 필요합니다.

나는 완전히 객관적인 것이 중요하다고 생각합니다. 긍정적 인 의견을 제시하여 사기를 높이는 것은 시간 낭비입니다.

이것은 코드 검토가 지나치게 중요하다는 것을 의미 할 수 있지만, 그 시점이 아닙니다. 우리는 또한 자신을 비판해야합니다. 필자가 작성한 코드가 완전히 쓰레기이고 아마도 개선 될 수 있다는 가정은 내 코드와 기술 수준을 향상시키는 데 도움이된다는 것을 알게되었습니다.

당신이 의견을 얻지 못하면 당신은 좋은 일을 한 것으로 간주 할 수 있습니다.

Mantra는 간단하다 : 품질 코드 (실제로는 적음)를 원한다면 적절한 검토 방법을 실행해야한다. 긍정적 인 피드백은 개발자 / 프로그래머가 아이디어 / 솔루션 / 수정을 생각하고 생각해내는 데 도움이됩니다. 너무 가혹하지 말고 요점을 확고히하십시오. Q & A 관리자는 팀 또는 구성원을 올바른 방향으로 안내 할 수있는 좋은 방법론과 관행을 알고 있어야합니다. 결과적으로 품질이 향상됩니다. 기간.

코드가 경쟁 용이거나 면접을 위해 제출 된 경우 (즉, 작성되고 다시 작성할 수없는 코드) 긍정적 인 의견은 필수입니다. 실제로, 부정적인 피드백뿐만 아니라 긍정적 인 피드백이 있는지 확인해야합니다. 그렇게하면 코더는 자신의 강점과 약점이 어디에 있는지 알고 보상 할 수 있습니다.

그러나 코드를 다시 작성할 수있는 직장 환경에서 말하는 것 같습니다. 어떤 경우에는 시스템에서 버그를 제거하려고합니다. 따라서 그러한 상황에서는 부정적인 버그 만 가치가 있습니다.

불편한 점이 있으시면 모든 사람이 좋은 코드와 나쁜 코드를 모두 토론 할 수있는 주간 코드 검토 회의를 가지십시오.

편집 : 비록 뭔가가 당신에게 깊은 인상을 주더라도, 당신이 개인적으로 당신의 칭찬을 표현하는 것을 막는 것은 아무것도 없습니다. 그러나 추적기는 프로덕션 코드 검토를위한 것 같습니다.