나는 최근에 소프트웨어 테스터와 이야기를 나누며 테스트 중심 개발 (TDD) 여기 Qumulo에서 엔지니어링 팀을 위한 필수 관행이기 때문입니다.
그는 자신의 감정을 표현하기 위해 다음과 같이 말했습니다.
나는 단위 테스팅이 중요하다고 생각하지만, 개발자들은 종종 테스트를 작성할 때 사용자의 관점에서 생각하지 않습니다. 대신 그들은 구현과 작동 방식에 대해 생각합니다. 실제로 작동하는 방식이 아닌 경우가 많습니다.
테스터로서의 그의 편견은 나에게 영향을 미치지 않지만, 엄격하게 기능 테스트를 작성하는 일을 하는 사람이 릴리스 주기에 매우 필요한 사고 방식을 가져올 수 있다는 데 동의합니다. 소프트웨어 엔지니어는 디자이너가 먼저이고 코더가 두 번째이기 때문에 기능 개발자가 이러한 차단기 사고 방식을 공유하는 것도 중요하다고 생각합니다. 우리는 사용 사례, 일이 어떻게 잘못될 수 있는지, 일이 불가피하게 잘못될 때 피해를 완화하는 방법에 대해 생각할 필요가 있습니다..
Qumulo에서는 이러한 기술을 강화하는 엔지니어를 위한 온보딩 및 성장 프로세스를 지속적으로 만들고 있습니다. 여기에는 성장 프로세스를 촉진하기 위한 TDD 사용이 포함됩니다.
엔지니어는 실제로 고객을 위해 문제를 해결하려고 노력하는 과학자일 뿐입니다. 내 경험상 TDD의 가장 가치 있는 기여는 TDD를 실행하는 엔지니어를 위한 과학적 방법을 용이하게 하는 방법입니다. 단위 테스트를 작성할 때 다음과 같은 가설을 세웁니다. 그리고 만약에, 프로덕션 코드를 변경하면 최신 테스트에서 주장한 속성을 충족하게 됩니다. 이것은 실제로 두 가지 가설이 복합된 것입니다.
- 기존 프로덕션 코드는 새 테스트에서 주장한 속성을 충족하지 않습니다.
- 수정된 프로덕션 코드는 새 테스트에서 주장한 속성을 충족합니다.
TDD가 없으면 대조군에 대한 실험을 수행하는 것을 잊음으로써 나쁜 과학을 연습하고 있습니다. 테스트가 프로덕션 코드를 변경하지 않고 통과했을 수 있으며 이는 테스트에 버그가 있거나 프로덕션 코드의 새로운 속성을 전달하지 않는다는 것을 의미합니다.
Qumulo의 코드 기반은 랩 노트북과 같습니다. 프로덕션 코드에서 수행된 모든 실험을 문서화하는 55,000개 이상의 테스트가 있습니다. 그것은 우리가 코드에 대해 알고 있는 것을 전달하며, 각 테스트는 독자에게 전달하는 만큼만 가치가 있습니다. 고객의 요구 사항에 대한 우리의 이해가 변경된 경우일 수 있으며 그에 따라 코드와 이에 대해 알고 있는 내용도 변경되어야 합니다. 테스트가 가치가 있는지 여부를 결정하는 것은 엔지니어의 몫이며, 가치가 없으면 삭제됩니다.
과학적 방법을 용이하게 함으로써 TDD를 통해 엔지니어는 더 골치 아픈 문제에 집중할 수 있습니다. 어떤 테스트가 누락되었습니까? 이것은 엔지니어가 고객의 머리 속으로 들어가야 하기 때문에 설계 프로세스의 핵심 과제입니다. 그것은 그들이 고려하도록 강요합니다. 우리 고객은 누구입니까? 그들은 어떻게 우리의 코드를 실행할 것인가? ("고객"에는 귀하의 코드를 사용하는 다른 엔지니어가 포함될 수 있습니다.)
그리고 디자인 프로세스는 항상 협력적입니다. 혼자 가는 것은 위험하기 때문입니다!
"한 명의 프로그래머가 한 달에 할 수 있는 일을 두 명의 프로그래머가 두 달에 할 수 있습니다." — 프레드 브룩스
나는 여기에서 Fred의 말을 꺼내고 있지만 "한 프로그래머가 할 수 있는 일"이 버그를 작성하는 것이라면 Fred의 진술은 새로운 의미를 갖습니다. 한 프로그래머가 한 프로그래머가 한 프로그래머에 작성하는 것만큼 두 프로그래머가 두 달 동안 많은 버그를 작성할 것입니다. 월! 그러나 진지하게, TDD를 연습할 때 작성하는 모든 버그는 실제로 작성하지 않은 테스트이며 두 명의 엔지니어 짝 프로그래밍은 한 명의 엔지니어보다 더 많은 테스트 케이스를 생각할 것입니다. 또한 더 나은 변수 및 함수 이름으로 더 깨끗한 코드를 생성하는 경향이 있습니다. 일반적으로 규율은 각 사람이 다른 사람에게 책임을 물을수록 더 강해집니다.
그래서 우리는 그것을 권장합니다 기본적으로 엔지니어 쌍, 그리고 그것은 코딩에서 멈추지 않습니다. Qumulo에서는 사용자 스토리를 작성하고, 작업을 작성하고, 화이트보드에 쌍으로 문제를 해결합니다. 페어링은 버그 비율을 줄이는 것뿐만 아니라 문제 영역에 대한 정보를 퍼뜨리고 (보너스로) 재미있습니다.
제대로 하면 재밌습니다. 그렇다면 엔지니어들이 효과적으로 테스트하고 페어링하도록 어떻게 가르칠 수 있을까요?
우리는 최근에 TDD 및 페어링 워크샵이라는 온보딩 프로세스에 이벤트를 추가했습니다. 우리는 TDD와 짝짓기에 대한 프레젠테이션을 하고, 이점과 함정에 대해 논의하고, kata(자주 반복되는 작은 연습 문제)에서 짝짓기를 통해 배운 모든 것을 연습합니다. 우리는 탁구, 드라이버/내비게이터 및 모빙 스타일을 사용하여 엄격한 TDD를 연습하고 로마 숫자를 십진수로 또는 그 반대로 변환하기 위한 라이브러리를 구현합니다.
참가자는 종종 페어링 및 TDD에 대해 동일한 불만을 제기합니다.
- 나는 누군가 지켜보고 있는 코딩이 불편하다. 명확하게 생각하기 어렵게 만듭니다.
- 나는 종종 파트너와 의견이 맞지 않아 시간을 낭비합니다.
- 나는 내비게이터의 자비에 따라 그저 타자 기계처럼 느껴졌습니다. 나는 우리가 해결하고 있는 문제를 따라가지 못했습니다.
- 내가 모든 일을 하는 동안 파트너가 산만해지는 것 같은 느낌이 든다.
- TDD는 비효율적입니다. 나는 결국 세련된 코드를 작성하고 나중에 수정합니다.
우리는 이러한 측면을 연습해 왔습니다. 극한의 프로그래밍 (XP) Qumulo에서 수년 동안 이러한 문제를 해결하고 신입 사원에게 다음과 같은 교훈을 제공했습니다.
- 페어링 세션에 대해 명확하고 달성 가능한 목표 및 운영 절차 설정 전에 시작합니다.
- 생산성이 떨어지는 것을 느끼면 휴식을 취하십시오.
- 페어링 경험이 많지 않으면 피곤할 수 있습니다. 파트너에게 알리면 담론을 덜 강렬한 것으로 바꿀 수 있습니다.
- 의견 불일치를 극복할 수 없다면 중재할 제XNUMX자를 불러들입니다.
- 길을 잃는다면 파트너에게 역할이나 스타일을 바꿔 속도를 늦추고 싶다고 말하세요. 남기는 것은 좋지 않습니다.
- TDD의 일부는 가능한 가장 간단한 코드를 작성하는 것입니다. 그 순간.추상화와 리팩토링을 식별해야 하는 경우가 많습니다(참조 변환 우선 전제).
워크샵 외에도 페어링 및 TDD는 일반적으로 엔지니어링 팀에서 권장하며 각 팀에는 코딩 표준을 전달하고 팀 구성원이 테스트 가능한 디자인 및 코드 인수를 찾도록 돕는 것을 목표로 하는 기술 코치가 있습니다.
XP의 이점을 경험할 만큼 충분히 오랫동안 연습하지 않았다면 XP에 회의적이기 쉽습니다. 우리는 TDD와 짝짓기가 엔지니어가 보다 효과적으로 의사 소통하고 자존심을 집에 두는 숙련된 과학자 및 디자이너로 성장하는 데 도움이 된다는 것을 발견했습니다. 아름다운 눈송이를 스스로 만든 것에 대한 영광을 주장하고 싶은 마음이 들 수도 있지만, 페어링을 하면 코드가 모든 사람이 디자인하고 읽고 재사용할 수 있다는 것을 깨닫게 되므로 말이 되지 않습니다. 그것을 당신의 개인적인 자부심에 붙이기 위해.
