코드를 단 한 줄 변경할 때도 리뷰/테스트 코드/문서화가 필요할까?

지난 주 팀 회고에서 구성원 중 한 분께서 이런 주제를 던져주셨다.

“최근 작업 하나를 하면서 드는 생각이 있었습니다. 실제 버그 픽스는 딱 한줄 수정한 것 뿐인데, 굳이 이를 위한 테스트 케이스 작성과 문서 작성을 꼭 해야 하나하는 자문였습니다.”

항상 고민스러운 주제다.

버그를 수정할 때 변경할 소스 코드가 단 한 줄 뿐이라면, (한 줄은 아니더라도 너무 뻔한 버그라면) 얼른 수정해서 눈 앞에서 치워버리고 싶다는 생각이 들게 마련이다. 한 줄을 고치면서도 물론 코드 리뷰도 하고, 테스트 케이스도 작성해서 돌려보고, 문서도 충실하게 수정할 수도 있겠지. 하지만 그렇게 하는 사람이 몇이나 될까? 그게 과연 효율적인 행동일까?

(솔직히 고백하자면, 간단한 수정하면서 난 그렇게 해 본 적도 없고, 이런 주제를 갖고 고민해본 적도 없다.)

.

.

.

그 다음 날 책을 보다 그 책에서 정말 우연히도 이런 그래프를 발견했다.

ffr

 

FFR은 “Fault Feedback Ratio”의 약자다. 우선 “Fault Feedback”이란, 버그를 수정하면서 시스템에 또 다른 버그가 생겨나는 것을 말한다. 따라서, FFR은 한 번 수정할 때 몇 개의 버그가 새로 생기는지를 의미하는데, 만약 FFR 값이 0.4라면 버그를 1번 수정하면 0.4개의 버그가 새로 생긴다는 뜻이다. FFR을 살펴보면 해당 조직의 소프트웨어 개발 문화를 매우 정확하게 유추해볼 수 있다.

“Lines of Code Changed”는 변경한 코드가 몇 줄인지를 나타내고 있다. 따라서, 이 그래프는 각 버그 수정마다 몇 줄의 코드를 수정했는지, 그리고 그 수정으로 인해 몇 개의 버그가 새로 생겼는지를 보여주는 그래프다.

대개 변경한 코드가 늘어날수록 (즉, 복잡한 버그일수록) FFR이 높을 것이라고 생각한다.  상대적으로 복잡한 버그를 수정할 때 실수할 가능성이 더 높아지고 올바르게 변경하기 어려울 것이라고 예상하는 것이다. 나도 그렇고 사람들은 대부분 당연히 그렇게 생각한다. 그 가설이 바로 그래프에 있는 점선이다.

그러나, 실제 측정치는 생각과는 달랐다. 그래프에서 볼 수 있는 작은 원이 실제 측정한 값이다. 사람들의 예상을 뒤엎고, 몇 줄 안되는 간단한 수정에서 더 많은 버그가 새로 생겨났던 것이다. 어떤 버그 수정이 사소하다는 생각이 들면, 그 생각으로 인해 신중한 판단의 가능성이 낮아져, 결국 FFR이 높아지는 모습을 보여주고 있다.

“문제를 쉽게 해결할 수 있다는 생각이, 오히려 문제 해결의 가능성을 낮춘다.”

저자는 단 한 줄을 바꾸더라도, 그 코드를 리뷰하고, 테스트 케이스를 작성하고, 문서로 정리하는 일은 결코 시간 낭비가 아니라고 말한다. 나는 리뷰/테스트 케이스 작성/문서화라는 행위자체가 중요한 것은 아니라는 생각이 든다. 한 줄을 바꾸더라도 그런 실천이 왜 의미가 있는지에 대한 구성원들의 이해와 공감대, 그리고 그것을 이루려는 노력이 중요하다. 아마 저자도 그런 이야기를 하고 싶었을 것이다.

이런 고민을 해볼 기회를 던져주신 우리 개발실의 도형님께 감사!

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중