개발 가속도의 법칙 - 최적의 개발환경

먼저번 가정에서 개발 가속도는 최적의 개발환경에 비례한다고 가설을 세웠습니다. 개발환경은 최고 수준보다는 최적을 지향해야 합니다. 무조건 개발자 PC의 성능이 좋거나 네트워크가 빠르다고 해서 개발 생산성이 좋다고 말할 수 없으며, 가장 비싸고 성능이 좋은 IDE 도구를 갖춘다고 해서 개발 생산성이 높아진다고 단정할 수는 없습니다. 개발환경과 개발하려는 대상의 아키텍처와는 궁합이 맞아야 하며, 이를 가지고 작업하는 개발자에도 친숙하고 쉽게 접근할 수 있는 환경이 최적화된 개발환경입니다.

통상 개발환경은 작업자인 개발자의 환경인 개인 작업장(workspace), 공용으로 (통합용으로) 사용되는 공유 개발 환경, 형상항목을 이력 관리하는 형상 환경, 개인 작업장과 공유 개발 환경을 연결해주는 배포 환경 등으로 나뉠 수 있습니다. 물론, 테스트를 위한 환경 역시 개발환경에 포함될 수도 있습니다.

모든 개발환경에 공통적으로 적용되는 원칙은 깨끗한 상태를 유지해야 한다는 것입니다. [클린 코드와 클린 작업장, 항상 청결을 유지하라] 깨끗한 상태를 유지하려면 무엇보다도 많은 노력이 들 수 밖에 없으며, 이러한 노력은 실제 개발을 수행하는 개발자에게는 또 다른 부담이 되기도 합니다. 깨끗한 상태를 유지하려는 노력은 다분히 반복 수행적인 작업들이 많으며, 이러한 작업들은 자동화를 통해서 상당히 많은 부담을 경감시킬 수 있습니다. [TDD, CI, CD]

개발환경이 만들어지는 시점은 아키텍처의 기본적인 골격이 어느 정도 나타나는 시점과 비슷합니다. 즉, 아키텍처가 만들어지는 시점에 개발환경에 관련된 부분들이 같이 고려가 되어야 하며, 필요한 SW 구성 요소들이 아키텍처를 통해서 식별/조합될 때 개발환경에 필요한 구성 요소들도 같이 식별/조합됩니다. 하지만, 개발환경의 구성 요소들이 모두 식별되었다고 하더라도 이를 어떻게 운영하고, 어떠한 방식으로 조화를 이룰지는 순전히 개발자의 몫입니다. 형상관리 도구를 아무리 비싸고 성능이 좋은 것을 선정했다고 하더라도 형상항목에 대한 디렉토리 구조를 체계적이거나 직관적으로 구성하지 못하면 형상항목을 찾는데에만 시간을 낭비하거나 동일하거나 유사한 내용이 중복되어 관리되어서 형상관리 도구를 사용하지 않느니만 못합니다.

최적의 개발환경은 최적의 개발도구를 선정하는 것 뿐만 아니라, 최적의 개발 상태를 유지하도록 체계적이고 직관적인 개발환경을 관리하는 것까지 포함됩니다. 이와 같은 관리를 하려면 선정된 개발도구가 미처 제공하지 못하는 기능들을 확장하거나 변형하여 현재의 개발 상태를 최적화시킬 수 있는 장치를 추가로 고안해야 한다는 의미입니다. 예를 들어, 수많은 컴포넌트들의 의존관계로 인해서 빌드/통합에 많은 시간을 필요로 한다면, 변경되지 않은 컴포넌트에 대한 빌드를 제외하고 변경된 컴포넌트들만 빌드/통합하도록 변경할 필요가 있습니다. 매회의 빌드는 형상도구에서부터 변경된 내용만을 체크아웃받고, 변경되지 않은 컴포넌트를 빌드하는 순간에 빌드를 건너뛰어 이전에 빌드된 내용으로 그 다음으로 진행하도록 하면 많은 시간을 절약할 수 있습니다. 이와 같은 내용은 빌드 도구가 이를 지원하지 않는다면 간단한 스크립트나 확장을 통해서 가능할 것입니다. 이러한 내용들은 초반에 개발환경을 선정하는 시점에는 나타나지 않은 문제들이지만, 계속해서 빌드 내용을 모니터링하여 빌드 프로세스를 조정해야 하는 것입니다.

최적은 어느 순간을 의미하는 것이 아니라, 꾸준히 지속적으로 관리되는 상태를 의미합니다. SW 개발의 처음부터 끝까지 (이후 유지보수를 지나 해당 SW 폐기까지) 개발환경이 최적화 상태를 유지하려는 노력은 개발 생산성/가속도에 보이지 않게 영향을 미치는 요소입니다.