• 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학론

2013/6 컴퓨터/IT 100위 | 현재 컴퓨터/IT 100위 |

출판사 리뷰

코딩 호러 블로그의 운영자이자 스택 오버플로우 공동 창업자가 알려주는 소프트웨어 개발의 비밀!

소프트웨어 개발 분야에서 가장 영향력 있는 블로그를 손에 꼽으라면 분명 코딩 호러(http://www.codinghorror.com)가 포함될 것이다. 코딩 호러는 하루 약 100,000명이 방문하는 블로그로서, 소프트웨어 개발과 관한 참신하고 독특한 식견과 재치 있는 입담으로 정평이 나 있다. 더불어 코딩 호러 운영자가 만든 스택 오버플로우(http://stackoverflow.com/)는 소프트웨어 개발 과정에서 문제가 생기거나 궁금한 점이 있으면 언제든지 달려가서 조언을 구할 수 있는 곳으로서, 자신의 소프트웨어 개발 능력을 한 단계 향상시킬 기회가 무궁무진한 곳이다.

이 책에서는 이 두 사이트를 탄생시킨 저자의 소프트웨어 개발과 관련된 지혜와 조언이 가감 없이 담겨 있다. 저자가 전해주는 소프트웨어 개발에 관한 깊이 있는 연구 내용과 조언들은 비단 프로그래머뿐 아니라 소프트웨어 개발을 둘러싼 이해관계자에게 모두 도움될 것이다. 그동안 코딩 호러에 실린 글 중에서 엄선한 글만 실린 이 책은 소프트웨어 개발에 관한 저자의 통찰력과 실질적인 조언을 통해 여러분의 소프트웨어 개발 프로젝트가 성공하기 위한 밑거름이 되어 줄 것이다.

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

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

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

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

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

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

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

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

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

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

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