클린 코드와 클린 작업장

코드가 깨끗한 상태를 유지하는 것은 프로그래밍에 있어서 가장 중요하시만 시급하지 않은 영역으로 분류되는 것 같습니다. 깨끗한 코드를 유지하는 상태는 여러명이 작업하는 경우에 그 어려움이 더하게 됩니다. 코드가 깨끗하게 유지되려면 여러가지 조건과 환경이 갖추어져야 하며, 그 대표적인 예가 깨끗한 작업장이 먼저 선행되어야 합니다.

즉, 개발 환경은 어느 누가 보더라도 깨끗하게 유지되어야 하며, 개발자의 노력에 대한 부담을 최대한 줄여주어야 합니다. 개발 환경 안에는 형상관리, 테스트 환경, 요구사항 추적 등과 같이 소스 코드를 중심으로 이를 깨끗하게 유지해주는 다양한 환경이 포함될 수 있습니다.

Amazing Graffiti by Banksy close to the Roundhouse - Camden Town, London by canonsnapper

일반적으로 프로그래밍과 소스 코드는 밀접한 관련이 있다라고 말하며, 주로 소스 코드에 대한 품질 관리 측면만을 부각하고, 여기에 집중을 하게 됩니다. 즉, 클린 코드만을 강조하게 되는 형태죠. 이러한 부분은 깨끗한 코드를 유지시켜줄 수 있는 작업장의 역할이 더 큰 영역을 차지합니다.

예를 들어, 새로운 개발자가 투입되었을 때, 작업 환경을 갖추는데 온종일 걸리는 시간, 소스를 체크아웃 받았을 때 코드가 깨지는 현상, 형상관리 안에 소스 코드와 바이너리 코드의 공존, 배포 환경의 부재, 테스트 케이스/코드의 부재, 공유되지 못하는 개발자들의 노하우 등등 이러한 내용들은 모두 깨끗하지 못한 작업장을 가지게 하는 것들입니다. 이러한 환경에서 만들어진 코드들은 대부분이 깨끗하지 못한 상태로 유지가 됩니다. 물론, 이러한 영역들은 눈에 보이는 가시적인 부분이기 때문에 눈에 보이지 않는 정성적인 측면들은 내부 비즈니스 로직 구성과 모델 구성을 파악해봐야 하는 것들입니다.

만일 위와 같은 상황이 현재 프로젝트에서 전개되고 있다면, 그 상황에 대해 아무런 조치를 하지 않으면 더욱 악화가 될겁니다. 즉, 깨진 유리창이 궁극적으로 폐허를 만들어내는 결과를 초래하는 것과 같은 이치입니다. 우선은 형상관리를 좀더 체계적이고 형상관리 도구가 가지는 다양한 기능을 최대한 활용하도록 작업환경을 마련하는 것이 깨끗한 작업환경을 만드는 시작일 것입니다. 형상관리 도구의 태그, 브랜치 등을 사용하여 소스 코드와 배포된 소스 코드의 바이너리 형태를 별도로 관리하게끔 만들고, 버전 번호를 붙여야 합니다. 이러한 체계가 갖추어지면, 빌드/배포를 한꺼번에 처리할 수 있는 장치들을 만들어야 합니다.

SW를 잘 모르는 사람들은 소스 코드만 있으면 프로그래밍이 완료되는 것처럼 이야기하는 경우가 있지만, 빌드 작업이 소스 코드를 만드는 것보다 더 오래 걸릴 수도 있다는 사실을 외면해서 많은 낭패를 보기도 합니다. 빌드는 소스 코드의 산출물이며, 이는 결국 설계 모델의 검증 결과이기도 합니다. 빌드 형태는 다양한 의존관계를 형성하고, 이 의존관계는 결국 비즈니스로부터 출발하여 나타난 모습이 됩니다. 즉, 의존관계를 관리하지 못하면 빌드 작업은 그 만큼 더 어려워지며, 유지보수는 더욱더 힘들어집니다.

작업장은 개발자가 소스 코드를 만들어내는 터전이며, 작업장의 최적화/표준화가 바로 소스 코드의 품질, 즉 SW의 품질과 직접적으로 영향을 주게 됩니다. 또한, 개발생산성까지도 영향을 미칩니다. 가장 실력이 뛰어난(생산성이 높은) 개발자와 가장 실력이 없는 개발자와의 간격은 100배 이상이 된다고 합니다. 이러한 간격을 줄이는 것이 SW 품질을 높이는 것이며, 결국 작업환경을 말끔하게 만드는 비용을 높이면 그 생산성은 높아지게 됩니다. 실력이 뛰어난 개발자만을 찾는 프로젝트는 내부적으로 이러한 진통을 겪는 환경일 것입니다. 이제 SW 개발은 몇몇 사람에게 의존하거나 지식이 많은 사람에게만 많은 업무를 주어서 생산성을 내는 시기는 이제 예전의 개발 방식이며, 이러한 개발 방식의 문제점과 그 결과는 지금까지 많이 보아 왔습니다.

깨끗한 코드 이전에 깨끗한 작업장이 우선 되어야 하며, 이러한 작업장이 개발자들 간의 실력의 향상과 더불어 지식의 공유를 더욱 높여줍니다.