개발자로 밥을 먹고 있으면서 수년동안 읽은 개발서 중에 머리가 아닌 가슴을 에이게 하는 책이 있다면 그중 하나가 바로 이책입니다. 개발서 치고는 얊은 데다가 타이포그래피가 구닥다리 냄새를 풍기고 있기는 하죠.
많은 좋은 내용이 있지만 그중 머릿속에 멤도는 몇가지는 아래와 같습니다.
만일 어떤 함수가 에러값을 리턴한다면, 그 함수를 호출한 모든 곳에서 에러를 처리해야 한다. p.168
C 언어를 처음 배울때 실패시에는 -1 또는 0을 성공시에는 1을 리턴하라는 가르침은 그 후에 어떤 언어를 배우더라도 성공, 실패를 값으로 리턴하려는 습관이 생겨 버립니다. 이 습관은 exception을 이해해고 적절하게 사용하는데 가장 걸림돌이 된다고 생각하며, C#이나 자바와 같은 고급언어를 공부한 후, C 나 C++ 언어를 공부하는 것이 더 좋다 라고 생각하는 이유 중 하나 입니다. 에러값을 리턴하는 함수를 사용하지 말자는 철학은 고급언어에 exception 메커니즘이 적용된 이유입니다.
Unix와 C에 기초한 시스템들은 전통적으로 루틴의 성공 또는 실패를 나타내는 리턴 코드를 사용한다. 자바는 예외(exception)라는 더 좋은 수단을 가지고 있다. 예외는 일반적인 처리 과정과 예외 처리 과정을 명확하게 분리하기 때문에 더 좋다. 이는 프로그램을 이해하기 쉽게 만든다. 프로그램을 쉽게 이해할 수 있도록 작성하는 것이 매우 중요하다는 사실을 이제는 믿어 주기 바란다.
리팩토링, 마틴 파울러 지음/윤성준,조재박 옮김, 대청, p.358
프로그래머들 가운데에는, 아무리 사소하 것이라도 효율을 향상시킬 수 있는 부분을 포기하는 것을 마치 죄악처럼 여기는 사람들도 있다. 가장 이상적인 것은 효율을 약간 희생하더 라도 안전한 설계와 구현 방법을 선택하여 위험을 줄이는 것이다. p.214
개발조직에서 논쟁을 하다 보면 효율성을 위해서 이상적인 설계와 구현 방법, 도구를 포기하자는 목소리가 클때가 많습니다. 효율과 이상적인 설계중 선택하라면, 저는 이상적인 설계를 선택합니다. 효율성 자체로서 크리티컬한 도메인 이라면 그 의견에 동의 하겠지만, 그러한 경우는 극히 드뭅니다. 효율을 약간 희생하더라도 안전한 설계와 구현 방법을 선택하는 것이 대부분의 경우에 적합하다 라는 것은 매우 동의하는 구절중의 하나 입니다.
페인트 깡통의 뚜껑을 열고 페인트를 휘젓는 데에 드라이버를 사용하는 것은, 아주 오래 전부터 집집마다 통상적으로 써 오던 방법이다. 나도 그 방법을 즐겨 사용했었다. 그 결과, 우리 집에는 여러 색의 페인트로 겹겹이 덮인 드라이버거 여러 개 있다. 사람들은 그래서는 안된다는 것을 알면서도, 왜 드라이버로 페인트를 젓는 것일까? 이유는 자명하다. 그 당시에는 드라이버가 편리하게 생각되었고, 실제로 페인트도 잘 저어졌기 때문이다. 페인트 젓는 막대가 된 드라이버 처럼, 편리하게 사용할 수도 있고 프로그램도 제대로 작동하지만 원래의 목적에서는 벗어나는 방법들이 코딩 과정에도 많이 사용된다. ~ 이 기준은, 마치 법률을 피하면서 세금을 적게 내는 방법을 가르쳐 주는 납세 지침서와 마찬가지이기 때문이다. 납세 지침서는 모두, 의도의 불순성을 무시하고 목적의 달성만을 추구하고 있는 것이다. 앞 페이지 예의 진짜 문제점은 코드에 있는 것이 아니라, 프로그래머의 자세에 있다. 수치적 연산을 위하여 논리적 연산을 사용하고도 마음이 편한 프로그래머라면, 다음엔 어떤 기상천외한 방법을 동원할까? 그 방법들을 어떻게 믿을 수 있을까? p.252,253
페인트까지 저을 수 있는 드라이버를 개발에서는 재사용이 가능하며 유연하며 활용도가 높은 객체라고 생각하기 쉬울수 있습니다. 엄밀히 말하자면 원래의 용도가 아닌 객체를 동작한다는 이유로 다른 용도로 사용하게 되는 것이죠.
때로는 실용적이라는 변명으로 목적이 수단을 합리화하는 일은 우리의 일상 뿐만이 아니라 개발에서도 발생합니다. 어떤 때는 적절한 행동처럼 보이기도 하구요. 거기에 동조하기도 하고, 눈을 살짝 감기도 합니다. 결과가 좋았더라도 가슴한 구석이 편치 않았던 때가 많았었죠. 살면서 그렇게 행했던 때, 개발하면서 그런 선택을 했을때, 페인트 통을 또한 번 드라이버로 저었다라는 생각을 합니다. 그러한 선택이 많아 질 수록 그 회사, 조직, 서비스, 나 자신이 어떠한 모습으로 변해갈지. 그러한 방법들을 어떻게 신뢰할 수 있을지.
앤토니 로빈스(Anthony Robbins)는 그의 책 [내 안의 거인을 일깨우자]에서 어떤 의사의 이야기를 하고 있다. 한 의사가 물살이 빠른 강의 제방에 서 있다가, 물에 떠내려가며 살려 달라고 외치는 비명소리를 들었다. 자기 이외에는 도와줄 사람이 없다는 것을 안 그 의사는, 주저하지 않고 물 속으로 뛰어들었다. 물에 빠진 사람을 강가로 끌어 낸 뒤, 의사는 인공호흡으로 그를 소생시키려 했다. 그런데 그가 소생되기도 전에, 강에서 두사람의 비명 소리가 또 들려왔다. 의사가 두 사람을 구조하여 소생시키기 무섭게, 강에서는 또다시 네 사람의 비명 소리가 들려 왔다. 어어서, 여덟명의 비명이 들려 왔다... 안타깝게도, 이 의사는 사람들을 구조하기에 너무 바쁜 나머지, 상류로 올라가서 도대체 누가 사람을 물에 빠뜨리는가 찾아 볼 시간이 없었다. p.273
증상만 치료하다가 정작 중요한 일을 하지 못하는 조직, 서비스. 자신의 조직이 아니라고 말 할 수 있는 개발자가 몇이나 될까요? 시간이 소요되더라도 원인을 제거해야 진짜 중요한 일을 할 수 있으며, 개발자도 발전 할 수 있습니다.
융통성이 크다 는 것이 '사용하기 쉽다'는 뜻이 아니다. 함수나 기능을 설계할 때는, 사용상의 용이성에 초점을 맞추어라. 함수나 기능이 융통성이 크다면, 아무리 애를 써도 그것들을 사용하기 쉽게 만들기는 어려울 것이다. 그 대신, 버그 찾기만 더욱 어렵게 만들 것이다. p.299
커다란 유혹입니다."지금 필요하진 않지만 나중에 필요할 지 모르니 그걸 붙일수 있게 개발해! 그렇게 하면 나중에 붙이기만 하면 되잖아!" 내가 개발하는 프로그램이 융통성이 있게 하자. 이 유혹과 소프트웨어를 단순 레고블록으로 취급하는 마인드는 오버 엔지니어링을 유발하고, 유연하기는 하지만 용이성을 잃어 버리기 쉽습니다. 그리고 버그의 온상이 되기 쉽죠. 이 균형을 맞추는 일은 성장이냐 분배냐의 질문에 대답하는 것 만큼이나 어렵습니다. 이럴 때마다 머리속으로 생각하는 답이 있습니다.
YAGNI You ain't gonna need it! KISS Keep it simple, stupid!