카우보이 코더를 어떻게 해제합니까? [닫은]

질문 (팀의 코드 카우보이)을 찾았지만 "Ninja Coder"와 관련이있는 문제였습니다.

나는 " 카우보이 코더 " 의 순수한 살아있는 예인 팀원이 있습니다. 사람을 바꿀 수는 없지만 "Cowboy Coder"처럼 행동하는 것을 멈추게하는 방법이라는 것을 알고 있습니다.

그는 팀의 의견을 거부하고 최근 코드 검토, 단위 테스트, 구현 세부 정보 공유 등을 중지했습니다.

예, 그는 "빠르게 코딩"하지만 코드는 버그 생성기입니다. 다른 팀원과 저는 "버그 수정 단계"에 있으며 버그의 80 %가 코드에서 나옵니다. 나는 그의 버그를 고치고 싶지 않다. 그리고 관리는 장님이거나 이것을보고 싶지 않거나 아마도 그의 "속도"를 좋아할 것입니다.

내가 (나이의 젊은 동료로서, 그의 상사가 아닌) 그것에 대해 무언가를 할 수있는 방법이 있습니까?

이 카우보이 코더를 어떻게 해제 할 수 있습니까?

나는 프로젝트를 정말로 걱정하는 마지막 사람인 것 같습니다.

몇 가지 옵션이 있습니다.

• 걱정스럽게 코더에 접근하십시오. 구체적인 요점을 가진 건설적인 비판으로 이루어져야합니다. 더 큰 발걸음을 내딛기 전에 직접, 개인적으로 우려를 제기하여 그 사람에게 변화의 기회를주는 것이 적절합니다.
• 정보와 통계를 수집하여 관리 부서에 제공하십시오. 관리는 신경 쓰지 않는 것처럼 보일 수도 있지만, 제대로 작동하기 위해 노력하는 것이 중요합니다. 부정적인 결과는 경영진에 불만을 제기하지 않는 다른 사람들을 소외시키는 것을 포함합니다.
• 카우보이 코더의 동료를 찾아 비공개로 토론하십시오. 상대방이들을 수있는 기회가 더 많을 수 있습니다.
• 다른 팀에서 일하도록 요청하십시오. 문제를 해결하지는 않지만 당신의 정신은 그대로 유지됩니다. 최소한 항상 최선을 다해 노력하고 아래로 끌지 않도록하십시오.
• 아무도 듣지 않으면 조직을 떠나십시오. 환경이 좋지 않은 것 같습니다.

그는 팀의 의견을 거부하고 최근 코드 검토, 단위 테스트, 구현 세부 정보 공유를 중단했습니다 ...

코드 검토가 반드시 코더가 검토를 위해 작업을 제출하도록 요구하지는 않습니다.

그가하는 일을 추적하는 쉬운 방법은 VCS 기록을 주시하고 체크인을 확인하는 것입니다. 그의 코드가 걱정된다면 쉽게 찾을 수 있습니다. diff history를보고, 그가 넣은 것을보고, 적기가 튀어 나오는지 확인하십시오. 그의 체크인을 충분히 빨리 잡아 내고 문제를 발견하면 커밋을 롤백하고 그 결과를 전자 메일로 보낼 수 있습니다. 명백히 잘못된 것을 보았을 때 주니어 코더로서 동료 팀원을 부를 수 있습니다.

예, 그는 "빠르게 코딩"하지만 코드는 버그 생성기입니다. 다른 팀원과 저는 "버그 수정 단계"에 있으며 버그의 80 %가 코드에서 나옵니다. 나는 그의 버그를 고치고 싶지 않다. 그리고 관리는 장님이거나 이것을보고 싶지 않거나 아마도 그의 "속도"를 좋아할 것입니다.

코드는 요구 사항에서 비롯됩니다. 요구 사항은 요구 사항이 충족되었는지 확인하는 실행 가능한 테스트를 생성합니다. 이러한 테스트는 추가로 세분화 할 수 있으며 변경 사항이 요구 사항 (적 록색 리 팩터, TDD의 본질)을 충족하는지 확인하기 위해 변경하기 전에 작성할 수 있습니다.

팀의 빌드 서버에 "코드 적용 범위"메트릭을 추가하십시오 (필요한 경우 첫 번째 문제임). 단위 테스트 통과를 확인하는 것만으로 단위 테스트가없는 영역에서 만들어진 새로운 TDD 코드가 아닌 문제는 발견되지 않습니다. 모든 단위 테스트를 실행 한 후에는 빌드 서버가 모든 코드 줄을 실행하는 것이 이상적이지만 단위 테스트 할 수없는 것이 실제로 있습니다. 실제로 95 % 이상의 커버리지를 기대할 수 있어야합니다 (또는 특정 라이브러리 또는 파일 형식을 커버리지에서 제외). 조만간 카우보이가 커버리지 수준을 임계 값 아래로 떨어 뜨려 빌드를 중단시키는 무언가를 체크인하고 콜 아웃합니다.

그리고 "속도"에 관한 한, 속도는 물건을 "완료"하는 속도이며, 정확하게 완료 될 때까지 "완료"되지 않습니다. 당신은 이런 식으로 당신의 관리자에게 그것을 넣을 수 있습니다; 관리자가 오일 교환을 위해 BMW를 데려 올 때 오일 팬 플러그를 다시 빼는 것을 잊어 버린 자동차 정비사를 생각해보십시오. 그 결과 모든 새로운 오일이 차고 밖으로 나가기 전에 쏟아집니다. 물론 오일 교환은 5 분 밖에 걸리지 않았지만, 자동차 엔진이 집으로 돌아가는 동안 관리자는 그 점에 신경 쓰지 않을 것입니다. 그는 정비공이 한 걸음 잃어 버렸음을 신경 쓸 것입니다. 지금, 그는 정말 빨리 일을하기 위해 한 카우보이에게 돈을 지불하고 있습니다. 팀의 나머지 부분에 훨씬 더 많은 금액을 지불하여 올바로 작업을 다시 수행합니다. 카우보이가 자신의 일을 계속하게하는 이점은 무엇입니까?

내가 (나이의 젊은 동료로서, 그의 상사가 아닌) 그것에 대해 무언가를 할 수있는 방법이 있습니까?

전화 해 그가 조이는 것을 발견하면 코드가 실패하는 방법, 처음부터 문제를 예방할 수 있었던 방법 (적절한 디자인, TDD, 코드 검토 포함) 및 결과로해야 할 일 또는해야 할 일을 보여주십시오. 깨진 코드를 수정합니다.

나는 프로젝트를 정말로 걱정하는 마지막 사람인 것 같습니다.

klaxons가 울리고, 깜박임, 사이렌 울림 -팀에서 생성 한 코드의 품질에 관심이있는 유일한 사람이라고 느끼면 심각한 문제가 있습니다. 전체 팀이 발로 차고 소리를 지르는 것이 좋은 코딩 시대로 끌어 들이고 있다고 생각되면 운반하기에는 너무 많은 무게가 든다. 회사에 다른 팀이있는 경우 이전을 요청하고 그렇지 않은 경우 대체하십시오.

이 개발자로부터 몇 가지 버그 / 문제가 발생했는지 통계로 관리 부서로 이동하십시오. 그들에게 버그를 수정하면 팀의 생산성에 영향을 준다고 설명하십시오. 실제로 80 %의 문제가 한 사람에게서 발생하는 경우 반드시 해결해야합니다. 그들이 동의 할 수있는 용어로 경영진에게 설명하는 한 (즉, "시간 낭비는 돈 낭비"), 그들은 개입 할 것입니다.

또한이 개발자는 자체 버그 / 문제를 수정해야하므로 이러한 문제를 해결하는 것이 도움이 될 수 있습니다. 귀하의 팀은이 한 사람을 다루지 않아야합니다.

내가 (나이의 젊은 동료로서, 그의 상사가 아닌) 그것에 대해 무언가를 할 수있는 방법이 있습니까?

동료 압력과 모범으로 이끄는 것이 유일한 좋은 방법입니다. 가장 좋은 방법은 보스 / 리드가 수행합니다. 당신이 그들의 상사 / 리드가 아닌 경우 그 사람들과 이야기하십시오. 그러나 결국 당신이 아닌 그것을 돌보는 것이 그들의 일입니다. 일을 잘하고 일이 잘 진행되는 경향이 있는지 확인하십시오.

그는 팀의 의견을 거부하고 최근 코드 검토, 단위 테스트, 구현 세부 정보 공유를 중단했습니다 ...

검토, 테스트 및 구현을 통해 문서화 된 코드 경로가 없습니까? 그렇지 않은 경우 더 넓은 문제가있는 것입니다. 그럴 경우 이관을 확대해야합니다.