코드 검토 및 단위 테스트에 대한 경험이없고 (필요하지 않은) 개발자 그룹을 관리하는 팀 리더로서 코드 검토 및 단위 테스트 실습을 어떻게 진행할 수 있습니까?
코드 검토 및 단위 테스트가 자연스럽게 개발자 흐름에 맞도록하는 방법을 어떻게 만들 것입니까?
이 두 영역의 저항 중 하나는 "우리는 항상 일정이 엄격하므로 코드 검토 및 단위 테스트를위한 시간이 없다"는 것입니다.
코드 검토에 대한 또 다른 저항은 현재 우리가 그것을 수행하는 방법을 모른다는 것입니다. 체크인 할 때마다 코드를 검토해야합니까, 아니면 지정된 날짜에 코드를 검토해야합니까?
답변:
팀원들은 실제로 코드 검토 및 단위 테스트가 좋은 일이라는 데 동의합니까?
아니면 그들은 단지이 변명으로 그 아이디어를 거부하려합니까?
첫 번째 경우, 해결책은 지금 시작하는 것 입니다. (확인, 주요 이정표가 있기 전 마지막 날인 경우에는 나중에 기다릴 수 있지만 더 이상은 없을 것입니다.) 우리는 이전의 근무 환경에서 품질 엔지니어 인 코딩 관행 개선 및 전반적인 품질. 다음 주까지 코드 검토 시작을 계속 연기했습니다. 어느 날 나는 우리가 한 달 정도이 일을하고 있다는 것을 깨달았으며, 다른 것을 시도하지 않으면 아마도 끝까지 계속 될 것입니다. 그래서 그 주에 대한 첫 번째 코드 검토를 발표했습니다. 나는 사람들에게 그것이 불완전하거나 아직 무엇을해야할지 정확히 모른다면 아무런 문제가 없다고 말했다. 우리는 그 일을 시작하고, 그것이 어떻게 진행되는지 배우고 우리가 배울 때 일을 개선 할 것이라고 말했다. 적어도 회사를 떠날 때까지 일했습니다.
두 번째 경우에는 팀과 더 많은 교육과 공개 토론이 필요할 수 있습니다. 코드 품질 문제를 토론 무엇을 그들에게 그들이 개발 과정의 문제로 볼 수 등 테스트 / 코드에서 / (또는 그 부족) 그리고 이것들을 해결하는 방법에 대한 함께 브레인 스토밍 . 궁극적 인 목표는 반드시 코드 검토를 수행하는 것이 아니라 단지 수단 일 뿐이며 개발 프로세스와 출력 품질을 향상시키는 것입니다. 더 쉽게 개선 될 수있는 더 고통스러운 다른 문제가 있다는 것이 판명 될 수 있습니다. 그런 다음 먼저 가져 가십시오. 심지어 환경이나 프로세스의 사소한 변화 일 수도 있습니다. 이 모든 것이 팀 사기를 개선하고 상호 신뢰를 구축하며 팀 유대를 도울 것입니다.
결론은, 누군가에게 품질을 강요 할 수 없다는 것입니다 . 품질을 만드는 장애물 만 제거 할 수 있습니다 . 사전 팀의 합의없이 엄격한 규칙과 의무 관행을 시행함으로써 팀을 소외시키고 궁극적으로 목표로하는 품질 개선을 방지 할 수 있습니다. 공개 토론과 팀의 가장 시급한 문제와 상황 개선 방법에 대한 합의를 목표로 OTOH를 통해 팀 지원을받을 가능성이 높아집니다. 이것은 장기적으로 품질 향상 추진을 유지하는 데 결정적인 차이를 만들 것입니다.
고전적인 문제. 제대로 할 시간이 충분하지 않고 항상 작업을 다시 수행하기에 충분한 시간이 필요합니다. 사람들이 모범 사례를 시작하기 전까지는 모범 사례를 수행 할 충분한 시간이없는 것 같습니다. 특히 승리는 개발 외부의 사람들에게는 보이지 않습니다.
코드 검토의 핵심은 가능한 한 적은 코드를 가능한 한 빨리 검토하려는 것입니다. 이렇게하면 검토 시간을 확보하는 것이 더 쉬워지고 사람들이 생각하기에 코드가 신선하며 제안 된 개선 사항을 구현하는 것이 더 쉬울 것입니다. 극단적으로 당신은 모든 단일 체크인을 검토하고 싶습니다. 이를 자동화하는 좋은 도구는 http://code.google.com/appengine/articles/rietveld.html 입니다. Google은 모든 체크인시 코드 검토를 강제하기 위해 내부적으로 사용하는 도구의 변형입니다.
코드 검토의 과제는 수십 년 전에 고전적인 컴퓨터 프로그래밍 심리학 에서 설명되었습니다 . 문제는 프로그래머가 자기 이미지를 프로그래밍 기술에 묶는 경향이 있다는 것입니다. 이는 프로그래머가 자신의 기술이 스너프하지 않다는 증거에 직면 할 때마다 개인적으로 받아들이는 경향이 있음을 의미합니다. 심각한 충돌이 발생할 수 있습니다. Steve McConnell의 클래식 Rapid Development 를 선택하면 그러한 충돌 가능성을 줄이는 코드 검토 프로세스를 설정하는 방법에 대한 여러 가지 제안을 제공합니다. (핵심 요소는 경영진이 프로세스에 관여하지 않도록하는 것입니다.) 이렇게하면 충돌 가능성이 줄어들지 만 충돌이 발생하지는 않습니다.
즉, 혜택은 비용보다 훨씬 큽니다. 한 가지 지표를 인용하기 위해 IBM은 코드 검토가 버그를 찾아 제거하는 가장 효과적인 방법 인 달러당 1 달러라는 사실을 발견했습니다. 이는 품질 보증 부서를 대체하지 않습니다. 그러나 결과적으로 훨씬 적은 문제가 발생합니다. 그리고 그것은 당신이 학습 속도를 높이고 지식을 퍼뜨리는 등의 이점을 누리기 전입니다.
그들에게 선택권을주지 마십시오. 테스트 및 검토는 필수입니다. 그들이 협조하지 않으면 테스트되지 않았거나 검토되지 않은 프로모션 거부와 같은 강경 전술에 의지 할 수 있습니다. 상황이 정말 나쁘면 최악의 범죄자를 해고하십시오.
팀이 항상 일정보다 뒤처진 경우를 보았습니다. 팀은 항상 테스트와 검토로 잡히지 않은 버그를 수정하고 있기 때문입니다. 약간의 선행 작업을하면 장기적으로 훨씬 더 많은 비용을 절약 할 수 있으며 팀을 더 빨리 배치할수록 팀이 더 잘 얻을 수 있습니다.
불행히도 결과를 실제로 보려면 시간이 걸릴 수 있습니다. 실습을 장려하기 위해 버그 보고서 비율, 평균 버그 수정 시간 및 기능 구현 비율을 차트로 표시 할 수 있습니다. 일반적으로 약 6 개월의 테스트 및 검토 후 이러한 측정 항목이 개선되고 팀이 최종적으로이를 얻습니다.
개발자의 의지에 반하는 tdd를 도입하는 것은 어렵다. tdd를 사랑하는 법을 배우는 것은 어려운 방법입니다.
tdd가 그린 필드에서 가장 효율적이기 때문에 (또는 테스트가 뒤틀린 경우 어렵고 비용이 많이 들고 비효율적이므로) 새로운 것을 구현하는 소규모 팀에서 시작합니다. 팀에서 tdd에 덜 반대하는 두 명의 개발자가 좋은 출발점이되는 것을 발견하면. tdd 개발자는 tdd에 경험이없는 동안 생산성이 저하된다는 점을 명심하십시오.
이 tdd 개발은 코드 검토를위한 좋은 출발점입니다. tdd가 프로그램 아키텍처에 어떤 영향을 미쳤으며 어떻게 소프트웨어 유지 관리를 용이하게하는지 논의하십시오.