지금까지 모든 대답을 합리적으로 조합해야합니다. 결국, 똑똑한 사람들 (개발자) 그룹에 대해 이야기 할 때, 행동이 중요한 이유를 제시하고, 행동이 올바르게 수행되도록 투자되는 행동이 어떻게 수행되는지 충분히 제어해야합니다 . 위의 명령은 일반적으로 똑똑한 사람들에게는 느슨합니다. 문제가 문제라는 데 동의하지 않으면 규칙을 따르는 것보다 명령을 해결하는 데 더 많은 시간을 할애 할 수 있기 때문입니다.

내 전술 중 일부는 다음과 같습니다.

변경 사항 커밋 :

먼저, 팀은 언제 커밋 할 것인지, 무엇을 커밋 할 것인지에 동의해야합니다. 사람들이 무언가를 어디에 두어야할지 모릅니다. 언제, 얼마나 자주 체크인해야하는지에 대한 합의는 “빌드를 깨뜨리지 말라”는 것은 명백한 좋은 규칙이지만 어떻게 확인되고 누가 그것에 대해 알게됩니까? 또 다른 기준은 “체크인되지 않은 경우 수행되지 않습니다”입니다.

내가 아는 대부분의 개발자는 코드 IF를 확인하는 것이 행복합니다.

• 체크인 과정은 쉽습니다
• 동기화 프로세스가 쉽습니다 (다른 개발자의 변경을 고려하여)
• 변경 사항 확인 및 버전 간 이동이 쉽습니다.

내가 최근에 알아 차린 한 가지는 새로운 CM 도구를 사용할 때 체크인이 더 빈번하고 고통스럽지 않다는 것입니다. 우리 팀은 이전에 Clearcase를 사용한 Rational Team Concert를 개척하고 있습니다. 툴을 광고한다는 의미는 아니지만 작고 빠른 병합이 많은 새로운 스트리밍 체크인의 물결이 조기 체크인과 자주 체크인에 더 매력적입니다.

개발자가 CM 통증 제거를 담당하게하면 일반적으로 체크인 횟수가 증가합니다.

아키텍처 준수-뷰 및 컨트롤러에서 모델 문제를 작성하지 않음

나는 그것을 “아키텍처를 올바르게 수행하라”는 일반적인 덩어리에 넣었다. 나는 동료 평가에 대해 말한 사람에 동의합니다. 동료의 압력은 이것에 좋습니다. 내가 일반적으로 사람들이이 분야에서 모범 사례를 접어 접하게되는 방법 중 하나는 동료들이 다른 방법으로 왜 그렇게했는지 물어 보는 것입니다 (그렇지 않은 방법). 일반적으로 “왜”질문은 사람들이 왜 다르게해야하는지 깨닫는 길을 안내합니다. 사람들이 모범 사례를 잘 이해 한 이유를 잘 알고 있으면이를 따르는 것이 훨씬 쉽습니다.

또한 사람을 결정에 연결하는 형식이 있다면 해당 영역에 버그를 할당하는 것이 더 쉬울 수 있습니다. 따라서 디자인이 잘못된 영역에서 버그를 수정하는 책임이있는 사람은 바로 전에 무언가를 얻을 필요가 있습니다. 그들은 새롭고 흥미 진진한 무언가로 넘어갈 수 있습니다.

하드 코딩 방지

명확한 코딩 표준으로 시작하고 코딩 검토를 동료 검토에 통합합니다. 하드 코딩은 동료 검토 안건의 확인란이 될 수있는 것 중 하나입니다.

나는 이런 종류의 것이 그것이 규칙을 집행하는 팀 리더의 역할이 된 것을 본 것 중 하나입니다. 내가 운영 한 팀에서는 일반적으로 코드의 동료 검토에서 주석을 수정하기 전까지는 누군가가 계속 움직이지 못하게합니다. “하드 코딩 없음”은 빈번한 동료 검토 의견입니다.

일반적으로

거의 모든 모범 사례를 통해 전투를 선택해야한다고 생각합니다. 완벽한 팀은 없습니다. 그러나 주요 통증 포인트를 주시하고 클러스터에서 문제를 해결할 수 있습니다. 팀의 어려움과 특정 개인의 성가신 점을 실제로 아는 것이 리더의 역할이된다고 생각합니다.

팀이 특정 모범 사례를 수행하지 못한 경우 첫 번째 질문은 “이로 인해 얼마나 많은 피해가 발생합니까?” 대답이 “최소한”일 경우 아마도 시간 가치가 없을 것입니다. 일부 모범 사례는 특정 유형의 시스템과 가장 관련이 있습니다. 전반적으로 우수하지만, 사례가 자주 발생하지 않거나 시스템의 주요 부분이 아닌 시스템의 경우에는 가치가 없습니다.

“얼마나 많은지?” “ALOT !!!”입니다. 모범 사례에서이 한 가지 문제를 해결하여이 모든 고통과 고통을 제거 할 수 있음을 팀에게 보여줄 수있는 사례를 구축 할 수 있습니다. 대부분의 사람들은 고통과 고통을 피하는 것이 기쁘고 대화가 “내가 말한 것이기 때문에”에서 “우리가 더 낫기 때문에 이것을하기로 결정했습니다”로 대화를 바꿉니다.

답변