아래는 《Code Simplicity : 소프트웨어 생명 연장을 위한 원칙》을 읽으면서 iReadItNow에 옮겨 적은 내용을 그대로 붙여넣기한 것이다. 이 책은 eBook PDF로만 판매되고 있으며, 9천 원이다. 결제를 하면 바로 다운받을 수 있고, DRM 없는 PDF기 때문에 인쇄해서 봐도 되고, 스마트폰에 넣어서 봐도 되고, 컴퓨터로 봐도 된다.

일단, 이 책에서 이야기하는 내용 중에 모르는 내용은 거의 없다. 저자도 서문에서 그렇게 말한다. 이 책의 장점은 다들 어렴풋이 아는 내용을 종합해서 명료하게 정리한다는 데 있다.

예컨대, 왜 유지보수하기 쉽게 코딩하는 것이 당장 출시를 빨리하는 것보다 더 중요한지 수학적으로 증명하는 게 그렇다.

저자가 책에서 제시한 원칙들을 정리해서 부록으로 넣어 놨는데, 책을 다 읽은 다음엔 부록을 보면서 되새기면 된다.

아래 밑줄 그은 내용들을 훑어 보면, 읽을 만한 책인지 판단할 수 있을 것이다.

  • 저자 : 맥스 카넷-알렉산더
  • 역자 : 신정안
  • 출판사 : 한빛미디어
  • 포맷 : 81 페이지, eBook

단순화에 대한 오해

가끔, 단순함을 “프로그램은 코드가 많으면 안 되며, 고급 기술을 사용하면 안 된다”라고 오해한다. 그러 나 사실은 그렇지 않다. 코드가 많으면 실제로 시스템이 더욱 단순해질 수 있다. 좀 더 많이 작성했다면 좀 더 많이 읽으면 된다. 또한, 고급 기술은 학습시간이 필요하지만 코드를 좀 더 단순하게 만들 수 있다.
원하는 기능을 빨리 코딩하는 것보다 단순하게 코딩하는 데 시간이 더 오래 걸린다고 이야기하는 사람도 있다. 하지만 이 말을 증명할 만한 데이터는 어디에도 없다. 만만찮은 소프트웨어를 개발하려면 적게는 몇 주, 몇 달이 걸린다. 오늘 프로그램이 좀 더 복잡해졌다면 내일은 작업이 더욱 더뎌질 것이다. 복잡함이 지름길 이라고 생각할 수도 있지만, 단순하게 코딩하면 오히려 작업이 빠르게 처리된다고 많은 연구가 말한다.
P.2

[민주적으로 설계한답시고 - 안형우] 위원회가 설계하면 더욱 나쁜 설계가 될 수 있으며,설계가 더욱 복잡해질 수 도있다. 모든프로그래머가 자신의 영역에서 제대로 설계할 수 있게 의사결정 권한이 있어야 한다. 취약하거나 애매하게 의사결정이 이뤄진다면 하위 설계자에 대한 거부권을 가진 중급 프로그래머나 리더 프로그래머가 수정해야 한다. 그렇지 않으면 코드 설계의 책임은 실제로 코드를 작업한 사람에게로 넘어간다.
P.3 ~ 4

소프트웨어의 목적은 사람들에게 도움을 주는 것이다.
P.5

오랜 시간 프로그래머들을 관찰한 결과 다음과 같이 확언할 수 있다. “좋은 소프트웨어를 만들 수 있는 잠재능력은 다른 이를 돕겠다는 생각을 얼마나 많이 하느냐에 달렸다.”
P.7

어떤 부분이 우선순위가 가장 높은가? “어떻게 우선순위를 정할 것인가”에 대해 더 알아야 할 것들이 있지만 “사용자를 얼마나 많이 돕는가?”가 소프트웨어 시스템의 변화를 이끌어 낼 수 있는 가장 기본이 되는 질문이다.
P.7

예를 들어, 설계자는 다음과 같이 생각 할 수 있다. “오늘 처리해야 할 항목이 100개 있다. 하지만 현재 2개를 겨우 처리할 수 있는 인력만 있다. 그럼 어떤 것을 먼저 처리해야 할까?”
P.10

적은 노력을 통해 많은 가치를 얻을 수 있는 변경이 더 좋다.
P.11

유지에 드는 노력을 줄이는 것이 구현에 드는 노력을 줄이는 것보다 더 중요하다.
P.19

요점은 무엇을 변경할지 예측할 필요가 없다는 것이다. 단지 변경될 것들을 알고만 있으면 된다. 가능한 합당한 범위 안에서 유연하게 소프트웨어를 개발하자. 그러면 다가올 어떤 미래에도 대응할 수 있을 것이다.
P.24

실제로 필요하기 전까지는 해당 코드를 작성하지 말자. 그리고 사용하지 않는 코드는 모두 제거하자.
즉, 필요 없는 코드는 제거해야 하며 필요해지면 그때 추가하면 된다.

또 다른 이들은 지금 여유롭게 작업을 해두면 미래에 시간을 절약할 수 있다고 믿는다. 이 생각이 맞는 경우도 있지만 필요 없는 코드를 작성할 때는 그렇지 않다. 그 코드가 미래에 사용하게 될지라도 미래에 다시 설계해야 하므로 실제로는 시간을 낭비하는 일이 될 것이다.
P.29

최고의 설계는 환경상에서는 최대한 변경을, 소프트웨어상에서는 최소의 변경을 할 수 있도록 하는 것이다.
P.39

이 분야에서 가장 유명한 에러는 ‘어설픈 최적화’다. 몇몇 프로그래머는 프로그램이 빨리 작동하게 만드는 것을 좋아하는 거 같은데, 이런 프로그래머는 프로그램의 작동이 느리다는 것을 알기도 전에 이미 프로그램의 코드를 최적화하려고 든다. 이는 자선단체가 부자들에게 음식을 제공하면서 우리는 단지 사람들을 도우려 했을 뿐이다라고 말하는 것과 같다. 얼마나 비논리적인가? 이런 프로그래머는 존재하지도 않는 문제를 해결하려고 한다.
속도에 대해 고려해야 할 부분은 오직 사용자에게 실제로 성능 문제가 발생한다고 보여줄 수 있는 정확한 부분이다. 나머지 코드를 위한 주요한 고려 사항은 유연성과 단순함이지 빠르게 처리되는 것이 아니다. 이 규칙을 위반할 수 있는 방법은 무수히 많지만 규칙을 따르는 것도 간단하다. 문제를 다루기 전에 정말 문제인지 증거를 찾아야 한다.
P.40

오랜 시간을 들여 코드를 작성했으므로 다른 프로그래머도 기꺼이 시간을 투자해 코드를 공부해야 한다고 생각한다. …
프로그래머는 일반적으로 똑똑한 집단이다. 그러나 자신 이외의 다른 프로그래머가 당연히 코드 단순화 또는 설명 없이도 모든 것을 이해할 것이라고 잘못 생각한다. …
코드가 학습하기 쉽게 단순하지 않다면 코드를 이해하는 데 어려움을 겪게 될 것이다. 정확하게 사용하지 못하고 버그를 만들게 되며 일을 망쳐버리게 될 것이다. 이런 일이 발생하면 이것을 누구에게 물어볼까? 당연히 이 코드를 작성한 여러분이다. 여러분은 질문에 답변하느라고 시간을 허비하게 될 것이다(음, 재미있지 않은가?).
P.48 ~ 49

소프트웨어 개발의 세계에서 항상 이야기해왔던 것처럼 코드는 작성하는 횟수보다 읽는 횟수가 더 많다. 그래서 읽기 쉽게 코드를 작성하는 것이 중요하다.
코드의 가독성은 주로 글자와 기호 사이 간격을 어떻게 조정하는지에 달렸다.
P.52

일반적으로, 읽기 어려운 버그성(buggy) 코드가 있다면 가장 먼저 해야 할 일이 바로 읽기 쉽게 만드는 것이다. 그럼 어디에 버그가 있는지 확실히 보일 것이다.
P.54

이름은 그것이 무엇을 나타내는지 완전히 의미를 파악할 수 있을 정도로 길어야 하 며, 읽기 어려울 정도로 너무 길면 안 된다.

[앞에는 의미없이 한두 글자로 된 나쁜 코드 예를 들었다. - 안형우] 좋은 이름의 동일한 코드다.

quarterly_total = sum(january, february, march); 
print(quarterly_total);

다음은 읽기 어려울 정도로 이름이 너무 긴 동일한 코드다.

quarterly_total_for_company_in_2011_as_of_today = add_all_of_these_together_and_return_the_result(january_total_amount, february_total_amount, march_total_amount);
send_to_screen_and_dont_wait_for_user_to_respond(quarterly_total_for_ company_in_2011_as_of_today);

위 코드는 읽기 어려울 정도로 너무 길다. 따라서 명명규칙은 글자와 기호가 공간을 얼마나 잡아먹는지로 돌아간다.
P.54 ~ 55

코드에 좋은 주석을 다는 것도 가독성을 높이는 방법이다. 그러나 일반적으로 각 코드가 무엇을 하는지에 대한 주석은 달면 안 된다. 코드의 의미는 코드를 읽는 것 만으로 명확해야 한다. 명확하지 않으면 코드를 더 간단하게 만들어야 한다.
코드를 더 이상 단순하게 만들 수 없다면, 그때 코드가 무엇을 하는지 설명하는 주석을 달아야 한다. 주석의 실질적인 목적은 이유가 분명하지 않을 때, 왜 그렇게 해야 하는지를 설명하는 데 있다. 설명하지 않는다면 다른 프로그래머를 혼란스럽게 만들 것이며, 코드를 변경하려 할 때 왜 그 코드가 있어야 하는지 모른 채 중요한 부분을 삭제할 수도 있다.
P.55

복잡함은 다시 복잡함을 만드는데, 이 비율이 꼭 선형적이지는 않다. 즉 다음과 같이 가정할 수는 없다. “10개의 기능이 있다. 기능을 1개 더 추가하면 단지 10%의 시간 만 더 들 것이다.” 사실, 새로운 기능 하나는 기존에 있던 기능 10개와 함께 동작해야 한다. 그래서 기능 10개를 개발하는 데 10시간이 걸렸다면, 새로운 기능과 기존의 기능을 적절히 연결하는 데 10시간이 또 필요할 수도 있다.
P.58

일반적으로, 소프트웨어의 목적을 절대 확대해서는 안 된다. 마케팅 부서에서는 소프트웨어가 세금도 처리하고 저녁도 만들 수 있다면 매우 좋아할 것이다. 그러나 이런 제안을 해 올 때마다 강력하게 대응해야 한다. 소프트웨어의 기존 목적을 고수하라. 목적만 잘 고수한다면 성공할 수 있다(소프트웨어는 사람들이 필요로 하고 도움 받기를 원하는 것만 해주면 된다).
P.59

불필요한 변경
무언가를 변경하려 할 때 복잡성이 가중된다. 요구사항, 설계, 코드 등 무엇이 됐든 버그가 생길 수 있으며, 변경에 대한 의사결정 시간이 필요하다. 또 변경을 위한 시간이 필요하며, 새로 변경된 부분이 소프트웨어 나머지 부분과 잘 돌아가는지 확인 할 시간이 필요하다. 그리고 테스트하는 시간도 필요하다. 각각의 변경은 복잡성을 가중시키므로 변경하면 할수록 새로운 변경에 더 오랜 시간이 필요하게 된다. 변경 을 하는 것이 중요하지만, 변경을 결정할 때는 현명하게 해야 하며, 기분에 따라 변경해선 안 된다.
P.59

기술을 사용하기 전에 선택하려는 기술이 나쁜지를 판단하려면 세 가지 요소를 살펴보면 된다. 바로 생존 가능성, 상호 운용성, 질에 대한 집중이다.
P.63

무엇인가 복잡해진다면 복잡성이 나타나는 수준보다 훨씬 낮은 수준 어딘가에서 설계상 오류가 있다는 의미다. …
실제로 프로그래머는 이런 문제를 매우 자주 경험한다. “코드가 엉망이어서 새로운 기능을 추가하는 게 너무 복잡해.”라고 말할 수 있다. 여기서 근본적인 문제는 코드가 엉망이라는 것이다. 코드를 정리하고, 이미 있던 코드는 단순하게 만들어라. 그리고 새로운 기능을 추가할 수 있을 정도로 단순해졌는지 살펴보자.
P.65

하지만 다행히도 기능을 구현하는 것과 복잡성을 다뤄야 하는 것의 균형을 맞추는 다양한 방법이 있다. 가장 좋은 방법은 특정 기능을 구현하기 쉽게 재설계한 다음 그 기능을 구현하는 것이다.
P.68

설계는 민주주의가 아니다. 결정은 개별적으로 이뤄져야 한다.
P.78