동료 개발자가 소스 코드 커밋에 주석을 추가하도록 어떻게 설득합니까?

Subversion (우리가 직장에서 사용하는 것)은 커밋에 대한 의견을 요구하도록 구성 할 수 있지만 단순히 이것을 켜는 힘이 없습니다. 내가 알고 내 신속하게 커밋 뒤에 이유를 이해하는 것이 유용하기 때문에 내 커밋 주석 이유가있는 경우에만 메모리 조깅 등이다. 그러나 이것은 내가 항상 얻는 두 가지 반응에 맞서기에 충분하지 않은 것 같습니다.

1. 시간이 너무 오래 걸리며 변경 사항을 리포지토리로 가져오고 싶습니다.
2. diff를 보는 것만 큼 쉽습니다.

나는 심지어 단순히 JIRA 이슈 ID를 넣는 것의 가치와 그것이 이슈와 자동으로 어떻게 연결되는지를 보여 주지만 여전히 주사위와는 관련이 없습니다.

최악의 경우, 전화를 걸 수 있는 사람 은 같은 캠프에 있습니다. 귀찮게하고 싶지 않으며 diff를 보는 것이 좋습니다.

나는 그것이 옳은 일이라는 것을 알고 있지만 어떻게 그들이 빛을 보게 할 수 있습니까? 동료 개발자를 설득 할 수없는 경우에도 경영진이 비즈니스를 위해 옳은 일임을 설득 할 수 있습니까?

"왜"에 중점을 둡니다. 그것의 모든 차이점을 잘보고 누군가가 코드 섹션의 논리 흐름이나 그와 비슷한 것을 바꾸는 것을 보았지만 왜 그것을 바 꾸었습니까? 이유는 일반적으로 관련 티켓 (JIRA)에 있습니다.

그들은 왜 "왜"가 중요한지 궁금해 할 수도 있지만, 2 년 동안 그 변경의 영향을 미치는 버그를 발견했을 때 그 버그가 발생한 이유를 아는 것이 새로운 버그를 수정하는 것뿐만 아니라 오래된 버그가 다시 발생하지 않습니다.

감사 이유도 있습니다. 바인딩 커밋 및 티켓 ID는 확인하기가 정말 쉽습니다. 버전 2를 푸시하고 있습니다. 이는 결함 23, 25, 26 및 27을 수정하지만 결함 24에 대한 커밋은 없으므로 여전히 미결합니다.

그들이 합병을하고 지원을 처리하도록하십시오. 다시 말하지만, 당신은이 일을 할 수있는 위치에 있지 않지만, 이전 커밋에서 문제를 해결할 수있는 사람이 있다면 정중하게 울타리 위로 보내라고 말하십시오. 커밋 주석이 없기 때문에 내가 한 일을 말할 수 없습니다.이를 변경해야합니다.

분기 병합에도 사용됩니다. 그것이 당신에게 해당되는지 아닌지는 확실하지 않지만, 그것은 내가 의견을 유용하게 생각하는 한 영역입니다.

다시 한 번, 귀하의 보트가 아니라 소프트웨어 팀을 관리했을 때 그들이 좋은 커밋 의견을 주면 그들에게 주별 상태 보고서 대신 사용할 것이라고 말했습니다. 그 후 훌륭한 커밋을 얻었고 관리자로서 진행중인 일을 추적하는 것이 더 쉬웠습니다.

코드에 줄 바꿈과 간격이 필요한 것과 같은 이유로 체크인 주석이 필요합니다. 더 쉽게 추적 할 수 있도록 읽고 이해하십시오.

때때로 당신은 비교를 비교할 필요가 있지만, 종종 그렇지 않습니다. 개발자가 필요로하는 모든 것을 2-3 문장으로 읽는 것만으로 비교할 수 없게하는 것은 총 시간 낭비입니다. 왜 개발자 시간의 가치가 보이지 않는지 궁금합니다.

• 좋은 예를 설정하십시오. 자신의 커밋 메시지를 유용성의 빛나는 예로 만드십시오. 팀이 스토리 및 결함을 관리하는 데 사용하는 다른 시스템에 대한 참조를 포함하십시오. 변경 사항을 요약 한 간단한 설명과 변경 사항이 필요한 이유에 대한 적절한 설명을 제출하십시오.
• 적절한 커밋 메시지가 없으면 추가 작업이 발생할 때마다 제출자에게 질문을 던지십시오. 이것과 함께하십시오 (그러나 바보는 아닙니다).
• 역할을 과도하게 수행하지 않으면 커밋 메시지를 사용하여 매일 변경 로그를 보내는 스크립트를 작성하십시오. 이것은 유용한 메시지가 개정판을 탐색하는 것보다 이점이 있다는 주장에 신뢰성을 부여합니다. 또한 매일 매일 무슨 일이 일어나고 있는지 확인할 수 있으므로 관리가 도움이 될 수 있습니다.
• 동맹국을 확인하십시오. 바라건대 당신에 동의하는 다른 개인이 적어도 한 명 있기를 바랍니다 (아마도 동의하지 않음). 그 사람이나 그 사람들을 찾아서 당신이 혼자 서 있지 않도록 더 설득하십시오.
• 적절한 커밋 메시지가 시간을 절약 한 방법 (또는 불량한 메시지로 인해 시간이 많이 소요됨)을 언급 할 기회가 있으면이를 포착하십시오.

삐걱 거리는 바퀴가되는 것을 두려워하지 마십시오. 다른 사람들의 나쁜 습관과 싸우는 것은 종종 마멸의 전쟁입니다.

이것은 내가 들었던 가장 기괴한 질문 중 하나입니다. 사람들이 무언가를 고치는 데 몇 시간 또는 며칠을 보내고 커밋 메시지를 입력하는 데 2 ​​초가 더 걸리나요?! 근시안적인 사람들과 일하는 것에 대해 걱정할 것이라고 말해야합니다. 그들은 분명히 그들의 잠재력을 최대한 발휘하기 위해 도구를 사용하지 않습니다.

다음은 지난주에 관련된 코드 검토의 예입니다. Google의 버전 관리 소프트웨어는 병합에서 기록을 보존하지 않으므로 이전 변경 사항의 경우 정확한 지점을 찾아야합니다. 그렇지 않으면 커밋 메시지에 "지점 Y에서 병합 됨"과 같은 내용이 표시됩니다. 지점 Y는 "지점 Z에서 병합 됨"을 표시 할 수 있으며, 더 깊은 수준의 중첩은 실제로 실제 커밋 메시지를 갖습니다.

신입 사원은 역사를 정확하게 추적하는 방법을 몰랐습니다. 이는 본질적으로 diff와 함께 일하고 있음을 의미합니다. 그는 자신이 추적하고있는 버그와 관련된 코드를 주석 처리하는 것을 보았다. 코드의 주석을 해제하면 버그가 사라졌습니다. 그는 디버깅 중에 누군가가 코드를 주석 처리했다고 가정하고 실수로 체크인했습니다.

코드 검토 중에 우리 둘에게 옳지 않은 느낌이 들었습니다. 그래서 실제 커밋 메시지를 추적하고 1 년 전에 해당 코드를 제거해야 할 정당한 이유가 있음을 발견했습니다. 새 직원은 코드를 수정하여 이전 버그를 다시 소개하지 않고 새로 발견 된 버그를 수정했습니다.

철저한 단위 테스트와 같이 이러한 종류의 회귀를 피하는 더 좋은 방법이 있지만 단위 테스트에서 2 초의 커밋 메시지 "낭비"시간으로 귀찮게 할 수없는 사람들을 볼 수는 없습니다.

여기에 정확히 같은 문제가 있었으므로 Subversion에 커밋 사전 후크를 추가하여 사용자 스토리 번호로 시작하지 않은 커밋을 수락하지 않습니다 (예상 형식에 대한 일부 기본 패턴 일치).

000-0000을 입력하는 것을 막을 수는 없지만, 한 번만 파괴적인 바보가 완벽하게 수용 가능한 숫자를 만들면 숫자를 구성합니다.

나는 일련의 사용자 이야기가 들어간 빌드를 찾으려고 며칠을 보낸 후에 이것을했습니다. 네, 그것은 어디 다른 프로세스 실패를 다루는했지만, 그것은 여전히 매우 추적 할 수있는 가치있는 정보를 제공합니다.

좋은 커밋 의견은 좋은 문서, 느리고 기능이 부족한 두뇌를위한 캐시 또는 긴 디버깅 / 문제 분석 / 조사 결과의 캐시와 같습니다.

예를 들어 디버깅, 로그 분석 등 무엇이든 알아낼 때마다 결과와 결과는 소중합니다. 물론 대부분의 작업을 반복 할 수 있지만 시간이 걸릴 수 있습니다. 따라서 항상 결과를 문서화해야합니다.

여전히 문서화에는 시간이 걸리고 때로는 "이 작업을 한 번만 수행해야하므로 왜 적어 두어야합니까?"와 같이 필요하지 않은 것으로 느껴지기도합니다. 괜찮습니다. 결과를 처음으로 문서화하지 않았으므로 두 번째로 동일한 작업을 수행하자마자 결과를 문서화하는 것이 영리합니다.

따라서 동료가 커밋 의견을 추가하는 것이 너무 많은 일이라고 생각하는 경우, 예를 들어 적어도 Jira 사례 / 티켓을 통해 해결하고 있다고 지적하는 경우, 각각의 이유에 대한 질문에 지속적으로 응답해야한다는 압력에 동기를 부여 할 수 있습니다. 체인지 셋.

제 생각에는 문서는 요청되는 정보의 함수로 작성되어야합니다. 예를 들어, 메일 서신은 매우 훌륭한 문서 시스템입니다. 질문은 나중에 검색 할 수있는 답변을받습니다. 즉, 메일 링리스트와 포럼이 실제로 지식 기반으로 작동하는 방식입니다.

불행히도 내가 근무하는 곳에서는 3 개월 후에 메일이 자동으로 삭제되므로 실제로는 항상 작동하지는 않습니다.

허락이 아니라 용서를 구하십시오.

가혹한 동안, 나는 이것을했습니다. 나는지지하는 사람들과 반대하는 사람들 사이에서 50/50의 분열을 가졌습니다. 대부분의 사람들은 저와 같은 수준이었습니다. 논쟁은 "나는 귀찮게 할 수 없다"와 "요점은 무엇인가?"였습니다. (둘 다 진지한 관심사가 아니라 무관심과 게으름을 나타냄).

나는 단순히 문자열의 길이를 측정하고 거부하기 전에 약간 유머 메시지를주는 커밋 사전 후크를 추가했습니다. 메시지에 내 이름을 넣었으므로 "이 분노"에 대한 책임은 분명했습니다. 물론, "반대"는이를 쉽게 제거 할 수 있지만, 스크립트를 파헤치는 것은 하나 이상의 의견을 추가하는 것보다 더 많은 노력이 필요합니다!

일주일 동안 * * (expletive deleted) 또는 kjhfkwhkfjhw 와 같은 메시지가 추가되었습니다 . 그 후 기본 메시지가 나타나기 시작했습니다.

1 년 동안 회의론자들은 의미있는 의견을 사용하고 실제로는 근시안적임을 인정합니다. 나는 합의를 얻지 못했지만 용서와 아마도 신뢰를 얻었습니다. 사람들이 사용합니다.

좀 더 정직하고 싶거나 (문제가 생길 것이라고 생각되면) 시험 기간 동안 커밋 후크를 추가 할 수있는 권한을 요청하십시오. 사람들이 2 주 또는 4 주 후에 마음에 들지 않으면 꺼냅니다. 그들은 관심을 잃거나 좋아하게 될 것입니다.

나는 보통 사람들에게 다음을 통해 확신시킨다 :

• 좋은 근거가있는 변증법
• 모범으로 이끄는
• 마찰

만약 우리 팀이 나쁜 일을하게하려면 길을 갈 때까지 계속 노력해야합니다. 우리가 이미 X를하고 있었다면 시간 / 돈을 절약 할 수 있다고 지적 할 수있는 시간 동안 괴롭 히려고 노력합니다.

커밋 의견에 대한 추가 이유 :

• 주석에서 자동으로 변경 로그 생성
• 버그 수정, 기능 추가에 대한 감사 내역. 이것은 팀 안팎에서 유용합니다.
• 커밋 메일을보다 유용하게 만드십시오.
• 커밋 X가 수행하는 작업 (거의 모든 커밋 후)을 개발자에게 묻지 마십시오.

• 6 개월 전에 불분명 한 것이 있는지 SVN 로그를 확인하십시오.
• 완료 시점을 알리지 않고이 문제에 대해 몇 가지 질문
• ???
• 이익

좋은 의견을 어떻게 추가 하고 싶 습니까?

내가 방금 가진 동료와의 경험에서. 프로젝트가 끝날 무렵 프로젝트 전반에 걸친 모든 변경 사항에 대한 요약 문서를 작성해야했습니다. 좋은 커밋 메모를 작성하지 않은 동료는이 작업이 다소 시간이 걸리는 것을 발견했으며 이제는 각 커밋마다 상당히 긴 주석을 달았습니다.

따라서 테이크 아웃-하나의 솔루션은 개발자가 프로젝트 마지막에 어떤 파일이 어떻게 변경되었는지, 어떤 파일이 추가 / 제거되었는지, 왜 그런지 상세하게 설명하는 요약 문서를 작성하도록하는 것입니다.

닫힌 문 뒤의 경영진에게 이것을 제안하십시오.

최악의 시나리오가 발생합니다. 모든 상급 레벨 개발자가 문을 닫습니다.

회사가 빈 개발자 자리를 채우기 위해 출동하면 관리 팀은 시스템 상태를 클라이언트에게 전달해야합니다.

앱 기록을 재구성 할 때 업무를보다 쉽게 ​​수행 할 수있는 방법을 물어보십시오.

시스템의 변화하는 상태를 명확하게 설명하는 일반 영어 커밋을 읽으십니까?

아니면 코드 차이를보고 스스로 알아내는 것을 선호합니까?

나는 그들이 당신이 느끼는 고통을 실제로 경험하는 것이라고 확신시키는 한 가지 방법을 추측합니다.

예를 들어, 그들이 다음과 같은 문제를 겪고 있다고 가정 해 봅시다 : 그들은 같은 코드 (아주 아이러니)에 대한 다른 버그 수정이 구현되었을 때 어떻게 든 나타나는 버그가 있습니다. 커밋 메시지를 검색하는 것만으로 이것을 찾을 수 있다면 좋을 것입니다 (따라서 누가 그것을 썼는지 찾아보십시오).

또 다른 방법은 커밋 메시지가 특정 방식으로 구현 된 이유에 대한 힌트를 제공하는 데 유용 할 수 있음을 설명하는 것입니다. 커밋 메시지에 "feature X"라고 표시 되더라도이를 구현 한 실마리를 얻을 수 있으므로 누가 대화해야하는지 알 수 있습니다.

그러나 이것은 내가 항상 얻는 두 가지 반응에 맞서기에 충분하지 않은 것 같습니다.

1. 시간이 너무 오래 걸리며 변경 사항을 리포지토리로 가져오고 싶습니다.
2. diff를 보는 것만 큼 쉽습니다.

동료 개발자에게 의견을 제시하여 다른 이점을 얻을 수 있도록 도전을 던져 보셨습니까? 몇 가지 다른 각도에서 이것을 볼 수 있습니다.

1. 그들의 게임을 Upping-이것은 더 까다로운 관점이 될 수 있지만 여기서 아이디어는 그들이 일정 기간 동안 이것을하고 아이디어에 익숙해 져 습관이 다른 길을 가기 위해 더 오래 걸릴 것이라는 것입니다. 또 다른 요점은 의견이 얼마나 정밀하게 조사 될 것인가입니다. 의견에서 짧은 이야기를 원한다면 나는 그들의 요점을 이해할 수 있습니다.
2. 변경 보조금 지급-초기 구매를 시도하거나 한동안 변경을 유도 할 수있는 다른 인센티브를 제공하는 방법으로 일종의 컨테스트를 진행할 수있는 곳입니다.

고려해야 할 또 다른 사항은 동료 개발자가 작업 위치를 관리하는 것을 얼마나 잘 알고 있습니까? 그들이 어제 10 가지 일을하려고한다면, 그들은 이미 작동하는 것으로보고있는 것을 바꾸고 싶지 않을 수도 있다는 것을 이해할 수있었습니다. "아니요, 안되요?"라고 말하려고합니까? 그렇다면 어떻게 그들이 조금 방어 적이거나 전투 적인지 알 수 있습니다. 당신이 그들에게 "이것이 효과가있을 수 있지만, 더 나은 대안이있을 것입니다 ..."라고 말하려고하면 기회가 생길 수 있습니다. "당신보다 성스러운"태도를 갖는 것은 당신에게 도움이되지 않을 것입니다, IMO.

이것을 보는 또 다른 방법은 경력을 키우는 데 관여하는 개발자가 자신 의 작업에 대한 문서 를 소유 해야한다는 것입니다.

위에서 언급 한 기사에서 제기 된 다른 요점 외에도 코드 변경 사항을 검토하여 변경이 발생한 위치 / 시간 / 이유를 확인할 수 있습니다. 찾기 어려운 버그를 추적 할 때 매우 중요합니다.

커밋에 주석을 달아야한다는 것이 중요하다고 확신 한 후에는 커밋에 대한 주석을 강제로 작성하는 스크립트를 만들 수 있습니다. 그렇지 않으면 실패합니다. 의미있는 주석을 보장하기 위해 최소 문자를 지정할 수도 있습니다. 이것은 그들이 "기억"하는데 도움이 될 것입니다.

그러나 @Kevin이 말한 이유를 이해하는 것이 중요합니다. 그렇지 않으면 임의의 의견을 추가합니다.

코드 리뷰가 있습니까? 도움이 될 수있는 것은 커밋이나 병합을 다른 개발자가보고 승인해야한다는 규칙을 제정하는 것입니다. 그런 다음 검토자인 경우 개발자에게 커밋을 수행하여 개발자에게 수행 한 작업을 설명하도록 요청해야합니다. 그가 말하면, 그가 방금 말한 것을 주석에 입력하도록 요청해야합니다. 종종 한 변경 사항을 일관되게 설명 할 수없는 경우, 이러한 변경은 처음에는 수행되지 않았 음을 의미합니다.

그래도 사람들은 의견을 밝히는 것만 큼 분명히 유용한 것에 반대 할 수 있습니까? 시간이 오래 걸리지 않으며 잘 보냈다. 주석을 작성하면 방금 수행 한 작업에 대해 생각해야합니다. 심지어 자신이 생각한 바를 실제로했는지, 그리고 어리석은 짓을하지 않았는지 확인하기 위해 diff를 살펴볼 수도 있습니다.

당신이 의견을 쓰지 않으면, 당신은 조잡하고 징계되지 않습니다. 그리고 의견을 쓰지 않아도된다고 주장하면 고의적으로 과실하는 것입니다.

그들에게 50,000 라인 메소드의 절차 혼란을 유지할 수있는 유일한 방법을 말한 다음 미래에 더 명확하고 명확한 코드를 작성하는 것을 고려하여 코드베이스를 팽팽하게하는 무의미한 주석을 처리하지 않아도됩니다.

이것은 프로세스 변경 항목입니다. 관리자는 주석의 QA를 포함하여 코드 단독에 대한 품질 보증 검사를 위해 "x"에 의해 개발 된 코드를 "Y"에 할당해야합니다.

내 조직에서 개발자는 자신의 코드에 대한 최종 QA를 수행하고 체크인 할 수 없으며 다른 개발자가이를 수행해야합니다. QA 수표의 일부는 의견이므로 의견도없고 체크인도하지 않습니다. 우리의 "예술"이 실제로 다른 사람의 계약 지적 재산 인 경우 많은 계약 작업을 수행하므로 다른 사람들이 우리의 코드를 이해하고 활용할 수 있어야합니다. 또한 오랜 시간이 지난 후 프로젝트가 우리에게 돌아올 때가 있으며 18-24 개월 후에 코드를 가져 와서 왜 우리 앞에 코드 아티팩트에 도달했는지 이유, 장소 및 방법을 이해할 수 있어야합니다. 이것은 커밋 주석을 작성하는 자체 서빙 동기를 제공합니다.

동료 개발자에게 병합을 수행하고 기록을 찾아보고 기록에서 몇 개의 파일을 비교하도록 요청하십시오.

다음 날부터 의견을 보내달라고 요청할 것입니다.

다음은 몇 가지 조언입니다.

1. 세상을 바꾸려고하지 마십시오. 당신은 실패합니다.
2. 대신 모든 사람이 약간 다르게 작동한다는 것을 인식해야합니다. 모든 사람에게 맞는 크기는 없습니다.
3. 사람들의 작업 과정에 특정 단계를 요구하는 것은 매우 사악합니다. 이러한 프로세스를 변경하는 데 10 년이 걸립니다. 다음 마감일 전에이 작업을 수행하도록 요청하고 있습니다.
4. 간단한 공정 변경이라도 시간이 오래 걸릴 수 있습니다.
5. 커밋에 대한 작은 의견은 이러한 프로세스를 변경하기에는 너무 중요하지 않습니다.
6. 양질의 작업을 수행한다고 가정 할 수 있지만 단계 자체를 선택할 수있는 충분한 자유를 주어야합니다. 숙련 된 개발자에게는 약간의 부담스러운 단계가 필요하지 않을 수 있습니다.
7. 초보자를 돌보는 경우 더 강력한 프로세스가 필요할 수 있지만 숙련 된 개발자는 헛소리를 처리해서는 안됩니다.
8. 작업 수행 방식에 대한 엄격한 제한을 적용하는 것은 결코 효과가 없으며 사람들을 느리게 할 수 있습니다.
9. 자신의 길이 일을하는 유일한 방법이라고 생각하는 사람들이 많이 있습니다. 당신이 그들 중 하나가 아니길 바랍니다.

소스 제어가이를 입증하는 경우 주석 처리되지 않은 커미트를 방지하기 위해 필수 주석을 설정하십시오. 충분히 간단하고 모든 사람은 곧 5 초의 주석 입력이 고통스럽지 않다는 것을 알게 될 것입니다.

그러나 주석 처리되지 않은 커밋은 가장 작은 단점 중 하나입니다. 나는 단일 커밋이 언급되지 않은 많은 성공적인 프로젝트에 참여했습니다. 팬티 위에 무리를 갖지 마십시오.