라고 하지만, 완벽을 지향하지 않은 완료도 그러한지 모르겠다. 사람들이 많이 오독해 쓰고 있는 문장이지 않을까 싶다. 돈이 완벽보다 낫다는 인정하겠다...

22장. 동결된 코드의 신기한 사례

아무리 코드가 변하지 않길 바라도, 코드는 반드시 변경되기 마련이다.

그 어떠한 경우에도 완벽하게 동작하는 프로그램은 없다. 말이 안되는 것 같은 이유에 의해서도 프로그램은 동작하지 않는다. 이러한 이유에서 코드는 변경될 수 밖에 없다. 앞서 변하지 않는 건 없다고 이미 적었었다. 책을 읽다가 알았는데 빙하도 움직인다고 한다... 동결은 은유적인 표현일 뿐이다.

우리는 늘 마감 일시가 다가올 때마다 아주 작은 기능 하나를 슬쩍 끼워넣고 싶은 충동에 휩싸인다.

아파트를 예를 들어보자. 다 지은 아파트 한 동이 있고 다음달에 입주를 하는데 누군가가 필로티를 넣어달라고 한다. 이럴 때 건설사는 어떻게 해야할까? 1층 입주 예정자를 내쫗고 1층을 부시고 필로티를 만들 수 있을까? 아니면 주변에 땅을 모조리 파내서 필로티를 만들 수 있을까? 기능 동결을 하게되면 그 어떠한 간단한 기능이라도 추가는 금물이다. 동결된 순간부턴 치명적이거나 위험한 버그가 아니면 수정하지 않아야한다.

이미 입증된 품질에 기반을 둔 변경점만을 세상에 내보내야 한다.

우리는 겉옷을 반만 입고 밖으로 나가지 않는다. 코드도 작업하다가 말고 내보내는 것이 아니라 작업을 완료하고 테스트를 완료하고 리뷰를 완료한 뒤에 내보내야 한다.

종종 IT 프로젝트에서는 마지막 20%의 노력이 들어가는 부분에서 전체 시간의 약 80%가 소모된다.

그 유명한 8 대 2 법칙, 파레토 법칙이다. 아무리 간단한 작업이라 하더라도 작업을 완료하는데 4배의 시간과 노력이 더 들어간다고 생각하면 좋다. 일정을 산정할 때 이 부분도 고려하자.

동결 기간에 기술적 부채를 얻을 것을 기대하라.

'더 낫게 만들 수도 있는 소프트웨어를 그냥 배포하는 일이 이상한 일은 아니다.'라고 책은 이야기하고 있다. 일정이 더 중요할 수도 있고, 땜빵으로 99%가 해결되는데 99.9%를 해결하기 위해선 구조를 변경해야할 수도 있다. 결국 우리가 개발을 할 수 있는 건 돈을 벌기 때문이기에, 퀄리티를 포기해야하는 일이 생긴다. 물론 매번 이렇게 일하면 개발자의 자존감을 크게 깎아먹는다.
이렇게 된 코드를 동결하고 배포를 하게 되면 자연스럽게 기술 부채를 얻게 된다. 이제 이것을 해결하는 것이 또 남은 과제가 된다.

23장. 제발 저를 배포해주세요.

배포 절차에서 최악의 잘못 중 하나는 배포를 프로젝트 말미 시점에 시행하는 것으로 여기는 것이다.

소프트웨어 업계에서는 작업 결과를 보장할 수 있는 마지막 순간까지 그 어떤 작업이나 결정도 연기해야 한다는 믿음이 점차 인기를 얻고 있다고 '린 소프트웨어 개발' 이라는 책에 나왔다고 한다. 하지만 프로젝트 말미에 배포하는 것은 큰 실수이다. 직전에서야 배포할 경우 테스트의 범위가 너무 넓어지고 개발기간 동안의 변경이력을 추적하기가 어렵다. 따라서 배포 절차를 만들고 배포하는 일은 개발 초기 단계부터 진행해야 하는 일이다. 배포 절차를 자동화하고 계속해서 검증해나갈수 있도록 해야한다.