동료가 예고없이 불필요한 개선을 할 때 코드에 대한 책임은 어떻게합니까?

내 팀원 중 하나는 IT 상점의 모든 거래의 잭이며 그의 통찰력을 존중합니다.

그러나 때때로 그는 내 코드를 검토합니다 (그는 팀 리더에게 두 번째 명령이므로 예상치 않습니다). 때때로 그는 최종 목표를 달성하기 전에 내 변경 사항을 검토하고 즉시 변경을 수행합니다. 심지어 내 작업을 한 번 중단했습니다.

다른 경우에는 3 개월 이상 된 내 코드 중 일부를 불필요하게 개선했습니다.

이것은 몇 가지 이유로 나를 귀찮게합니다.

1. 항상 실수를 고칠 기회는 없습니다
2. 그는 혼란 스러울 때 내가 성취하려고하는 것이 무엇인지 묻지 않았으며, 이는 그의 테스트 나 변경에 영향을 줄 수있다
3. 난 항상 그의 코드를 읽을 수 있다고 생각하지 않습니다
4. 마감일은 문제가되지 않으며 현재 작업량에는 코드 변경 사항을 검토하는 것 외에 다른 프로젝트 작업이 필요하지 않습니다.

어쨌든, 나는 과거에 그가 내 코드의 소유권을 가질 수 있도록 (내가 "단점"이라고 말했을 수도 있음) 내 작업에서 무언가 변경되는 것을 볼 경우 게시를 유지하도록 요청했으며 응답하지 않았습니다. .

그의 변경 사항을 설명해달라고 요청하면 공격적으로 벗어날 수 있을까 걱정됩니다.

그는 자신을 지키는 조용한 사람이지만 그의 행동은 계속됩니다. 우리는 팀이기 때문에 코드를 변경하지 못하도록 막고 싶지는 않습니다.하지만 팀을 돕기 위해 제 역할을하고 싶습니다.

설명이 추가되었습니다.

• 1 개의 개발 지점을 공유합니다. 중요한 작업을 잃을 위험이 있기 때문에 모든 변경 사항이 단일 작업을 완료 할 때까지 기다리지 않습니다. 따라서 변경 사항이 빌드되고 중단되지 않도록해야합니다.
• 저의 걱정은 팀원이 그의 변화의 이유나 목적을 설명하지 않는다는 것입니다. 나는 그가 나의 축복이 필요하다고 생각하지 않지만, 우리가 접근 방식에 동의하지 않는다면 장단점을 논의하고 우리가 무슨 일이 일어나고 있는지 이해하면 결정을 내리는 것이 최선이라고 생각했습니다.
• 필요하지 않은 한 경영진의 참여없이 개인적 의견 불일치를 해결하는 것을 선호하기 때문에 아직 팀장과 논의하지 않았습니다. 저의 우려는 우리 업무에 대한 위협보다 개인적인 문제로 보였으므로 팀 리더를 방해하지 않기로 결정했습니다. 코드 검토 프로세스 아이디어를 개발 중입니다. 내 애완 동물 친구에 대해 모든 것을 만들지 않고도보다 체계적인 코드 검토의 이점을 홍보하는 데 도움이됩니다.

필자는 대부분의 개발자가 어느 시점에서이 위치에 있다고 생각하며, 피해자라고 느끼는 모든 개발자가 상급자가되고 후배가 작성한 코드를 정리할 때 얼마나 실망 스러울 지 알기를 바랍니다.

나를 위해,이 상황에서 충돌을 피하는 것은 두 가지로 귀결됩니다.

1. 예의 . 개발자가 자신의 코드에 대해 이야기하면 개발자는 자신이 관심이 있다는 것을 알 수 있으며, 성장한 전문가로 토론 할 수 있습니다.

2. "코드 소유권"은 잊어 버리십시오 . 팀은 코드를 소유합니다 . 변경을 원하는 다른 사람들은 좋은 것입니다. 선임 개발자가 "읽을 수없는"또는 더 나쁜 변경을 수행 한 경우이를 취소하십시오. 적극적 일 필요는 없으며 편집자에게 변경 사항이 적용되지 않았 음을 알리고 복귀에 대해 기꺼이 논의 할 수 있습니다.

코드의 팀 소유권은 훌륭하며 두 가지 방법을 모두 사용합니다. 다른 사람의 코드에서 의미가없는 것을 발견하면 수정하십시오. 지나치게 소유하고 부적절한 의사 소통을하는 것은 유독 한 개발 환경을 만드는 확실한 방법입니다.

귀하와 대부분의 답변자들은 두 동료 간의 의사 소통 문제로이 문제에 접근하지만 실제로는 그렇지 않습니다. 당신이 묘사하는 것은 다른 어떤 것보다 끔찍한 코드 검토 프로세스 와 비슷합니다 .

먼저, 동료가 두 번째 명령이며 코드를 검토 할 것으로 예상됩니다. 그건 잘못이야 정의에 따르면 피어 코드 검토는 계층 적이 지 않으며 결함을 찾는 것이 아닙니다. 또한 학습 경험 (관련된 모든 사람에게), 사회적 상호 작용의 기회를 제공하고 집단 코드 소유권을 구축하는 데 유용한 도구를 입증 할 수 있습니다. 또한, 때때로 자신의 코드를 검토 그에게서 배우고 자신이 잘못 할 때 (아무도 바로 그것을 얻을 수없는 그 수정해야 모든 시간).

또한 동료가 즉시 변경한다고 언급합니다. 그것은 또한 잘못이지만, 물론 이미 알고 있습니다. 그의 gung ho 접근법이 문제가되지 않았다면이 질문을하지 않았을 것입니다. 그러나 나는 당신이 잘못된 곳에서 해결책을 찾고 있다고 생각합니다. 완벽하게 정직하게 말하면, 당신의 동료는 저를 조금 생각 나게합니다. 저와 비슷한 상황에서 저에게 효과가 있었던 것은 잘 정의되고 탄탄한 검토 프로세스와 멋진 도구 세트였습니다. 동료가 코드를 검토하지 못하게하고 모든 작은 변화가 실제로 작동하지 않기 전에 중지하고 대화하도록 요청하는 것은 아닙니다. 잠시 동안이 될 수도 있지만, 그는 곧 너무 성가신 지점에 도달하여 시작한 곳으로 돌아갈 수 있습니다. 심지어 코드 검토를 중단합니다.

여기서 해결책의 핵심은 피어 코드 검토 도구 일 수 있습니다. 나는 일반적으로 제품 권장 사항을 피하지만 코드 검토를 위해 Atlassian 's Crucible정말 생명의 은인입니다. 그것이하는 것이 매우 단순 해 보일 수도 있지만 그것이 놀라운 일이 아니라는 것을 의미하지는 않습니다. 리포지토리에 연결하여 개별 변경 세트, 파일 또는 파일 그룹을 검토 할 수있는 기회를 제공합니다. 코드를 변경할 필요가 없으며, 옳지 않다고 느끼는 모든 것에 대해 언급하십시오. 다른 사람의 코드를 절대 변경해야하는 경우 변경 사항을 설명하는 변경 세트와 함께 간단히 의견을 남길 수 있습니다. Crucible의 제품 페이지에있는 소개 비디오는 자세한 내용을 원한다면 볼 가치가 있습니다. Crucible의 가격은 모든 사람을위한 것이 아니라 무료로 제공되는 동료 검토 도구가 많이 있습니다. 내가 함께 작업하고 즐겼던 것은 Review Board 이며 간단한 Google 검색으로 많은 사람들을 찾을 것이라고 확신합니다.

어떤 도구를 선택하든 프로세스가 완전히 변경됩니다. 멈출 필요가없고, 의자에서 내리고, 다른 사람을 방해하고 변경 사항을 논의 할 필요가 없습니다. 당신이해야 할 모든 것은 매주 시간을 정하고 의견을 검토하는 것입니다 (일주일에 한 번만 제안입니다. 당신은 나보다 일정과 일상을 잘 알고 있습니다). 더 중요한 것은 핵심 리뷰가 데이터베이스에 저장되어 언제든지 검색 할 수 있다는 것입니다. 그들은 워터 쿨러에 대한 임시 토론이 아닙니다. 이전 리뷰에서 내가 가장 좋아하는 사용 사례는 코드 팀에 새 팀원을 소개 할 때입니다. 우리가 정확히 어디에 붙어 있는지, 다른 의견을 가지고 있는지 등을 지적하는 코드베이스를 통해 새로운 누군가를 걸을 수 있다면 항상 좋습니다.

계속해서이 동료의 코드를 항상 읽을 수있는 것은 아닙니다. 그것은 일반적인 코딩 표준이 없다는 것을 알려주며 나쁜 일입니다. 다시 한 번 사람 문제로 접근하거나 프로세스 문제로 접근 할 수 있으며, 후자를 강력히 제안합니다. 팀을 구성하고 가능한 빨리 공통 코딩 스타일과 표준 세트를 채택하십시오. 개발 에코 시스템에서 공통적 인 표준 세트를 선택했거나 자체 표준을 수립하더라도 문제가되지 않습니다. 실제로 중요한 것은 표준이 일관되고 표준을 준수하는 것입니다. 거기에 많은 도구가 도움이 될 수 있지만 완전히 다른 토론입니다. 시작하기 위해 매우 간단한 작업은 사전 커밋 후크가 코드에서 일종의 스타일 포맷터를 실행하는 것입니다. 원하는대로 코드를 계속 작성할 수 있으며 다른 사람이보기 전에 도구가 자동으로 "수정"하도록 할 수 있습니다.

마지막으로 당신에 언급 코멘트 관리는 개별 dev에 지점이 필요하다 생각하지 않습니다. 우리가 "관리 지점"이 아니라 "개발 지점"이라고 부르는 이유가 있습니다. 머릿속에 형성되는 돌풍이 나올 이유가 없기 때문에 여기서 멈출 것입니다.

모든 말은, 나는 당신의 동료가 여기에 잘못 있다고 의심하지 않습니다. 그것은 나의 요점이 아니며, 나의 요점은 전체 개발 프로세스가 잘못되었다는 것입니다. 그것은 수정하기가 더 쉽습니다. 적절한 도구를 사용하여 수많은 공식 및 비공식 프로세스를 탐색하고 팀에 적합한 프로세스를 선택하십시오. 머지 않아 대부분의 "사람 문제"가 더 이상 존재하지 않는다는 것을 알게 될 것입니다. 그리고 "우리는 작은 팀이므로 모든 것을 필요로하지 않는다"고 변명하는 사람 (자신 포함)의 말을 듣지 마십시오. 유능한 개발자 팀은 일주일 이내에 필요한 도구를 설정하고 자동화 할 수있는 모든 것을 자동화하며 다시 돌아 보지 않을 수 있습니다.

추신. "코드 소유권"은 끊임없는 논쟁을 불러 일으키는 용어로, 사람들마다 다른 것을 의미합니다. C2 에 대한 상이하고 때로는 반대되는 의견의 대부분을 훌륭하게 찾을 수 있습니다 .

"코드"에 대한 책임 을 지게 만드는 프로세스는 무엇입니까 ? 특정 기능을 계속 작동시킬 책임은 전적으로 귀하에게 있습니까? 리드는 "마이클, 당신이 책임을지고 싶습니다"라고 말했습니까? 아니면 특정 기능이 손상 될 때마다 팀장과 팀원이 당신을 바라본다는 점에서 당신의 책임은 암시 적인가?

어느 쪽이든 책임이 있다면 코드에 대한 권한이 필요합니다. 다음에 다른 사람이 일방적 인 변화를 일으켜서 문제를 해결하기 위해 리드가 나올 때, 리드와 함께 앉아 권한과 책임을 조정하도록 요청해야합니다.

이것이 전체 상황을 해결할 수는 없지만 소스 코드에 주석을 더 추가 할 수 있습니다.

1. 코드가 완료되지 않은 경우 표시 될 수 있습니다.
2. 코드 블록의 목적이 자체 문서화가 아닌 경우 문서화해야합니다.

레몬을 빨아 먹는 대신 시간을 낭비하면서 레모네이드를 만들어보십시오. 마이클이 말했듯이, 일반적으로 팀원들은 당신을 나쁘게 보이게하지 않습니다. 실수를 통해 배우고 향후 개정판에 적용하십시오.

그의 변화가 부정적인 영향을 미쳤다고 생각되면, 이것을 외교적으로 말하십시오. 그것이 저라면, 나는 왜 특정한 변화가 이루어진 것인지 묻고 원래의 변화를 방어 할 수 있는지 알아볼 것입니다. 선임 동료들도 인간입니다. 그가 무언가를 놓쳤거나 그가 제공하는 부정적인 영향을 알지 못할 가능성이 있습니다.

정치, 법률 또는 경제에 관계없이 모든 사람은 암시 적으로 '자신의 코드를 소유합니다'- '사물의 본질'-자연스럽게 자신의 작업과 개인적으로 연결되는 느낌입니다.

동료가 당신이 묘사 한 행동에 관여 하고 있으며, 머리를 구할 때 반응이없는 경우 , 그 동료는 무례하고, 말을 가장 적게하고, 당신을 훼손하려고 시도 할 수 있습니다. .)- 팀 플레이어처럼 들리지 않습니다 .

좋은 동료가 당신과 함께 바닥에 접촉하고 코드의 문제를 지적하는 것입니다 당신에게 - 당신은 / 수정을 변경하거나 적절하게 응답 할 수 있습니다. 나는 내가 newbee 때에도, 내 멘토는 항상 내가 잘못하고 있었는지 나에게 지적하자 (또는 왜 설명하는 매우 감사 하게 내가 그것을 수정). 그것은 나에게 더 나은 프로그래머가되었고 모두에게 이익이되었다. 그리고 그것이 다른 사람들의 작업을 검토 할 때 항상 한 일입니다. 그러면 여러분 (또는 누구든지)은 실제로 여러분의 '모든 거래의 잭'에서 무언가를 배우고, 교사를 포함하여 코드와 팀이 모두 나아집니다 : 교육은 이해를 돕는다.

가능하다면 팀 리더와 개인적으로 문제 를 논의하겠습니다 . 상황에 대한 당신의 설명에 근거하여, 좋은 팀장이 당신의 편을들 것입니다-나쁜 것은하지 않을 것입니다 ... 분명히 이것은주의가 필요합니다-당신은 스스로 판단해야합니다.

코드를 작성하면 검토해야합니다.

검토 중에 코드를 변경하면 코드가 더 이상 내가 검토 한 코드가 아니라 내가 변경 한 코드입니다. 따라서 검토해야합니다. 아마 당신에 의해.

누군가 내 변경 사항을 검토하지 않고 변경 사항으로 새 코드를 커밋하면 (1) 검토되지 않은 변경 사항 및 (2) 코드 검토가 심각하게 수행되는 경우 가능한 최악의 죄를 저지른 것입니다.

나는 당신이 지금 올바른 방법으로 처리하고 있다고 생각하지만,이 방법으로 전혀 코딩하지 않을 정도로 당신을 혼란스럽게하는 팁 포인트가 곧있을 것입니다.

내가 당신이라면, 나는이 사람과 빠른 일대일을 요구하고 나의 PoV를 침착하면서도 단단하게 설명 할 것입니다. 코드 등의 팀 소유권은 모두 훌륭하지만 모든 개발자가 자신의 작업을 수행 할 수있는 충분한 공간을 제공하지 않으면 실수를 저지르고 개선하지 않으면 좋은 코드를 작성하지 않습니다. 이것은 나중에보다 빨리 마찰 영역이 될 수 있습니다.

(이것이 workspace.stackexchange에 있다면 완전히 다른 대답이 있습니다. 코드 검토를 수행하는 올바른 방법을 찾는 것이 쉬운 일입니다. 동료가 이것을 준수하도록 설득하는 것이 훨씬 어렵습니다).