소프트웨어 개발자로서의 당신은, 자기 자신의 가장 큰 적이다. 이 사실을 일찍 깨달을수록 더 훌륭한 프로그래머가 될 수 있다.

물론 당신이 좋은 의도를 가지고 있다는 사실은 이해한다. 누구나 다 그렇다. 우리는 모두 소프트웨어 개발자다. 우리는 코드를 작성하는 사람들이다. 그것이 우리가 하는 일이다. 실력이 뛰어난 프로그래머인 우리는 약간의 이사용 테이프, 옷걸이, 그리고 바로 코드를 이용해서 해결할 수 없는 문제를 만난 적이 없다. 하지만 윌 쉬플리(Will Shipley)는 너무 많은 코드를 작성하고자 하는 우리의 자연스러운 내적 경향을 억제해야 한다고 주장한다.

*****

코딩의 근본적인 속성에 따르면 프로그래머인 우리가 내리는 모든 결정에는 그 자체로 장점과 단점이 동시에 포함돼 있다. 프로그래밍의 진정한 장인이 되는 길은 바로 그러한 장단점의 본질을 잘 이해하고, 우리가 작성하는 모든 코드의 구석구석에서 언제나 그러한 사실을 잊지 않는 데 있다.
코드를 평가할 때 우리가 취할 수 있는 측정 방법으로는 여러 가지가 있다.

? 코드의 간결함
? 기능의 풍부함
? 실행 속도
? 코드 작성에 걸린 시간
? 안정성
? 유연성

기억할 것은 이러한 측면들이 모두 각자 반대되는 방향으로 뻗어나간다는 사실이다. 예를 들어 당신은 정말로 아름답고 빠르게 동작하는 코드를 장장 삼일에 걸쳐 작성할 수 있다. 이 경우 두 개의 차원은 상승하는 방향으로 움직이지만, 코드를 너무 오랫동안 작성했으므로 하나의 차원은 완전히 하락하는 방향으로 움직인다.

그렇다면 어떤 상황에서 어떤 것에 가치를 둬야 할지 어떻게 알 수 있는가? 그러한 결정을 어떻게 내리는가? 이러한 질문에 대한 대답은 너무나 당연하고 간단하기 때문에 아무도 들으려고 하지 않는다. 대답은 바로 간결함에서 시작하라는 것이다. 테스트를 수행하는 과정에서 다른 차원으로 나아갈 필요가 있다고 생각되면 필요한 내용을 그때 추가해도 늦지 않다.

*****

나는 이러한 주장에 전적으로 동의한다. 개발자들에게 더 적은 코드(Code Smaller)를 작성하길 권장할 때 이와 비슷한 주장을 펼친 바 있다. 이것은 단지 코드의 물리적인 분량을 최소로 만들기 위해 우리가 아는 온갖 기법들을 총동원해야 한다는 식의, 귀류법에 대한 이야기를 하고 있는 것이 아니다. 어떤 프로그래머 개인이 읽고 이해해야 하는 프로그램 코드의 분량을 최소한으로 줄이기 위한 실질적이고 타당한 감소 전략에 대해 말하고 있는 것이다. 내가 말하고자 하는 바를 설명하기 위한 예를 살펴보자.

if (s == String.Empty) if(s == "")

이 두 if 구문 중에서 나는 두 번째 if가 더 낫다고 본다. 더 짧기 때문이다. 그렇지만 나는 String.Empty라는 장황한 표현이 컴파일러에게는 더 효율적이라는 주장에 목숨을 걸 정도로 확신하는 개발자를 만나게 되리라는 사실을 잘 알고 있다. 마치 그런 주장에 내가 관심이 있기라도 한 것처럼. 혹은 그런 주장에 관심을 갖는 사람이 마치 있기라도 한 것처럼 말이다!

그와 같은 극단적인 주장을 인정하는 것은 대부분의 프로그래머에게 괴로운 일일 것이다. 그들은 코딩이라는 행위를 너무나 사랑하기 때문이다. 하지만 최선의 코드는 아예 코드가 없는 것이다. 당신이 세상 안으로 끌어들이려고 애쓰는 코드는 모든 줄마다 반드시 디버깅해야 하고, 누군가 읽고 이해해야 하며, 유지보수해야 한다. 당신이 새로운 코드를 한 줄 작성할 때마다 이러한 일들을 반드시 수행해야 한다. 다른 선택의 여지가 없기 때문이다. 코드가 우리의 적인 이유는 결국 우리 프로그래머들이 터무니없을 정도로 많은 코드를 작성하기 때문이다. 그렇지만 아예 코드를 작성하지 않는 것은 말이 되지 않는다. 그렇다면 차선책은 바로 간결함에서 시작하는 것이다.

코드를 작성하는 것을 사랑한다면, 그러니까 진짜로 코딩을 사랑한다면 가급적 적은 분량의 코드를 작성하는 것조차 충분히 사랑할 수 있을 것이다.