테스트를 작성을 망설이는 분들께 올립니다.
Needs of Developers
우리 개발자들의 Needs 가 무엇인지 살펴봅시다.
- 가독성이 좋은 코드를 추구한다.
- 훌륭한 설계를 추구한다.
- OOP 의 원칙을 잘 지킨 유지보수성과 확장성이 좋은 코드를 추구한다.
한 문장으로 정리해볼까요?
가독성이 좋으며 유지보수성과 확장성이 좋은 코드를 작성하는 것.
How
개발자의 니즈를 충족시키기 위해 어떤 노력을 해야 할까요?
- OOP 를 공부한다.
- 클린 코드를 공부한다.
- DDD 를 공부한다.
- 코드 리뷰를 한다.
- 등등 ...
Needs of Company
회사의 Needs 는 무엇일까요?
- 수익
왜 갑자기 회사의 니즈가 나왔는지 아래에서 살펴보시죠.
Startup and Agile
대부분의 스타트업들은 Agile(민첩한) 문화를 지향합니다.
왜 Agile 일까요?
Agile 을 원칙을 살펴보겠습니다.
애자일 선언문을 보면 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대응하기를 더 높은 가치로 두고 있습니다.
4개를 다 이해하지 않으셔도 됩니다. 여기서는 변화에 대응하기만 집중적으로 살펴볼 것입니다.
변화에 대응하기
스타트업은 매 순간 순간의 선택이 상당히 중요합니다. 때로는 고객들이 진정으로 필요로하는 서비스를 출시하기 위해 1-2개월 내에 새로운 서비스를 만들어 출시를 해야할 수도 있습니다.
왜 그렇게 빨리 출시해야할까요?
회사가 하는 모든 행동은 수익과 관련되었다고 보시면 됩니다.
제품을 빨리 출시 함으로써, 빠른 고객 유치와 시장 점유를 통한 수익을 내는 것 이라고 생각합니다.
천천히 만들면 더 견고하고 좋은 서비스를 만들 수 있지 않을까요?
어떤 서비스를 고객에게 제공할 목적이면, 가능한 빨리 출시해서 고객의 반응을 보고 고객으로부터 나오는 피드백을 수용하여 민첩하게 변화에 대응 하면서 서비스를 개선하는 것이,
고객들이 원하는 좋은 서비스를 만드는 지름길이라고 생각합니다.
따라서, 많은 스타트업들이 Agile 문화를 선택하는 이유가 제품을 빠르게 출시하고 민첩하게 대응해서 고객이 원하는 서비스를 제공해줌으로써 수익을 얻기 위함 이기 때문입니다.
기술 부채
모든 것을 다 얻을 순 없습니다.
위와 같은 상황이 자주 발생하다보면 기술 부채는 쌓이게 됩니다.
기술 부채가 나쁜건가요?
기술 부채를 내기 때문에 회사가 빠르게 성장할 수 있습니다. 따라서, 기술 부채 자체가 나쁜 것이 아니라 기술 부채를 쌓아두는 것이 나쁘다고 할 수 있습니다.
따라서, 저희는 기술 부채를 주기적으로 해결해야하는 책임도 갖고 있습니다.
기술 부채를 계속 쌓아 두다보면 결국 나중에 회사의 손해로 이어지지 않을까요?
애자일 선언 이면의 원칙
제가 좋아하는 문장 3가지를 소개하고 본론으로 넘어가겠습니다.
- 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서
고객을 만족시키는 것이다. - 기술적 탁월성과 좋은 설계에 대한
지속적 관심이 기민함을 높인다. - 최고의 아키텍처, 요구사항, 설계는
자기 조직적인 팀에서 창발한다.
- 회사의 니즈는 고객을 만족시키는 서비스를 제공해서 수익을 내는 것이고, 개발자의 니즈는 고객을 만족시키는 좋은 서비스를 제공해주는 것입니다.
- 좋은 개발자란 무엇이냐라고 정의하면
관심과태도라고 생각합니다. 부족한 지식은 채우면 되는 부분이지만 관심과 태도를 채워 넣기는 정말 어렵다고 생각합니다. - 정답은 없다고 생각합니다. 주어진 환경과 상황마다 최선의 것을 찾기 위한 노력을 해야 한다고 생각합니다.
Why test code is required?
서론이 길었네요. 이제 테스트 코드의 필요성을 설명해도 될 것 같습니다.
회사의 니즈와, 개발자의 니즈를 충족시키기 위해 개발자가 해야할 일은 바로 테스트 코드를 작성하는 것이라고 생각합니다.
새로운 서비스를 2개월 안에 출시해야 하는 상황이 와서, 야근도 열심히 하고 제품을 출시한 상태라고 가정해봅시다.
과연, 해당 코드는 아무런 문제가 없을까요?
당연히 기술 부채가 쌓여있을 것입니다. 제품을 빨리 출시하느라 코드 리뷰를 Deep 하게 할 시간도 부족했을 것이고요.
- 그 뿐만일까요? 만약에 QA 가 없다고 하면, 모든 기능이 잘 동작한다고 보장할 수 있나요?
- 새로운 기능이 추가된다고 했을 때, 유연하게 대처할 수 있을까요?
- 유지보수성과 확장성이 좋은 코드라고 장담할 수 있나요?
이러한 질문에 당당히 "네" 라고 대답할 수 있는 기업은 테스트 코드를 작성하고 있을 것입니다.
테스트 코드는 개발자의 니즈와 회사의 니즈를 충족시키는데 도움이 되는 도구라고 생각합니다.
소프트웨어 개발 방법론과 단위 테스트
시작이 반이다.
테스트 코드 작성과 관련된 다양한 소프트웨어 개발 방법론이 있습니다.
- TDD
- ATDD
- BDD
- ...
아직 테스트 코드 작성 습관화가 안된 상태에서 TDD 와 ATDD 같은 개발 방법론을 바로 적용하는 것은 많은 부담이 있습니다.
단위 테스트 작성 부터 시작하면 됩니다.
- 모든 기능에 대해 단위 테스트를 작성할 필요는 없습니다.
- 이런것 까지 테스트 작성을 해야해? 라고 생각이 드는 부분도 있습니다.
핵심 기능에 대해서 단위 테스트를 작성하는 것부터 시작해보는 것은 어떨까요?
핵심 기능에 대해서 단위 테스트를 작성하다보면, 내 코드가 점점 테스트 하기 쉬운 코드가 되는 것을 느끼실 수 있고, 테스트 코드가 작성되어있기 때문에 심리적 안정감도 얻으실 수 있습니다.
나비 효과
테스트 코드를 작성함으로써 개발자와 회사의 니즈를 충족시키고, 자신과 회사가 미래에 어떻게 변화될 지 상상해봅시다 :)
Quotation
대부분의 경우 테스트 가능한 애플리케이션을 목표로 할 경우
훌륭한 애플리케이션 코드를 작성하게 된다.
Rod Johnson
References
'TDD' 카테고리의 다른 글
| TDD with Agile (0) | 2022.02.05 |
|---|