클린 코더 (The Clean Coder, by Robert C. Martin) 1 ~ 4장

서문

개발을 공부하고 인턴으로 첫 회사에 갔을 때, 사수가 좋은 책이 있다며 소개해주신 게 있다.
로버트 마틴이 저서한 [ 클린 코더 ] 이다.

이 책은 개발 기술에 관한 내용도 물론 있지만, 개발을 할 때 어떤 마음가짐을 가져야 나와 동료들 및 이해관계에 있는 사람들에게 좋을 지와 프로 개발자란 어떻게 일하는 사람인지를 주로 소개한다.
나는 개발자로 전향한 초입에서 이 책을 읽을 수 있어서 행운이었다고 생각한다. 기존에 전혀 접근하지 않은 분야로 뛰어드는 것이었기 때문에 이 곳의 생태를 잘 알지 못했고 그렇기 때문에 알게 모르게 많은 실수와 시행착오를 겪을 가능성이 높았다. 그때 이 책을 읽으며 아주 간접적으로나마 개발자들이 어떻게 일하고 생각하는지를 보면서 나의 행동양식을 어떻게 할지 많은 고민을 가졌고, 이 고민의 시간 덕분에 현재 개발자로서 비교적 효율적이고 긍정적인 방향으로 나아갈 수 있었다고 생각한다.

나는 이 책을 전체적으로 요약하거나 기술하지 않을 것이다. 읽었던 구절 중 내 마음에 와닿고, 다른 이들에게 전하고 싶었던 내용만을 떼어 짧게 정리할 것이다.

---

(이하 글은 책의 문체를 대부분 그대로 가져왔습니다.)

본 내용

1장 프로의 마음가짐

책임감을 가져라

기한을 맞추기 위해 필요한 테스트를 놓치지 말자. 이는 '나는 시간을 맞추는 사람'이라는 체면을 세우기 위해 하는 무책임한 짓이다. 이 체면의 대가로 고객과 회사는 데이터를 손실하거나 기능을 사용하지 못하는 추가 피해를 감당해야 할 수 있다.

QA는 아무것도 찾지 못해야 한다

코드에 결함이 있는 걸 알면서도 QA에게 코드를 보내는 일은 매우 프로답지 못한 행동이다. 확신을 갖지 못하는 코드는 모두 결함이 있는 코드다. QA가 결함을 많이 찾는 것을 선호하는 문화는 일정을 망치고 개발팀의 모험심을 뿌리부터 갉아먹는 일이다. QA 혹은 사용자가 문제를 찾을 때마다 개발자는 놀라움과 분함을 느껴야 마땅하며, 다시는 그런 일이 생기지 않도록 방비해야 한다.

구조에 해를 끼치치 마라

구조가 좋아야 코드가 유연해진다. 코드를 변경할 때 터무니 없는 비용을 치르지 않고 변경할 수 있어야 하며, 이를 위해서는 구조가 유연하면서도 유지하기 쉬워야 한다. 전체 구조를 희생하면서까지 기능을 추가하는 일은 헛수고가 된다.

프로 개발자는 코드와 테스트에 확신이 넘치기 때문에, 시도 때도 없이 이리 저리 코드를 바꿔도 마음이 평안하다

마치 조각가가 진흙을 다루는 것처럼 코드도 끊임없이 모양을 바꾼다.

자신의 경력은 자신이 책임져야 한다

책을 사주고, 교육과 컨퍼런스에 보내주는 회사는 책임을 지는 것이 아닌 호의를 베푸는 것이다. 공부할 시간을 마련하는 일 또한 회사 책임이 아니다. 프로는 직업을 돌보는 데 시간을 투자한다.
끊임없이 배우고, 연습하고, 함께 일하고, 멘토링하고, 업무 지식을 익히고, 회사와 고객에 동질감을 가지며, 겸손하라.

IT 산업은 미친듯이 바뀌기 때문에, 어마어마하게 공부해도 간신히 시대를 따라잡는 정도이다. 끊임없이 배우면서, 후배들을 가르치면서 더 배워라. 프로라면 후배들을 멘토링하는 책임을 져야 한다.

프로답지 못한 행동 중에서도 최악은 제품 사양이 사업 진행에 이치가 맞는지 따져보지도 않고 그저 스펙에 따라 코딩하는 일이다. 사양에 오류가 있는지 알아보고 이의를 제기할 수 있을 만큼 업무를 알아야 한다.
또한 프로라면 문제가 무엇인지 이해하고 최선의 해결책을 만들기 위해 일해야 한다. 프로는 자신의 일을 이해하고 그 일에 자부심을 가지며, 자기 능력을 확신하고 그 확신을 바탕으로 계산한 위험을 과감히 짊어진다.

2장 아니라고 말하기

노력한다는 약속은 이전에는 최선을 다하지 않았다는 뜻이다

노력한다는 약속은 지금까지는 늑장을 부렸으며 힘을 비축했다고 인정하는 셈이며, 지금의 계획은 불충분하여 계획을 바꾼다는 약속이다.

수동적 공격성, 두고 보자는 심보

협업 관계에 있는 타인이 벼랑 끝으로 걸어가도록 내버려두는 것은 프로답지 못하다. 그를 대신해 위험 부담을 지더라도 직접 나서 끔찍한 결과를 피하도록 하는 것이 팀 플레이어다운 일이다.

(원문: 폴란는 흥미로운 결정을 내렸다. 마이크가 돈에게 일정을 제대로 말하지 않았다고 의심했지만, 마이크가 벼랑 끝으로 걸어가도록 내버려뒀다. 폴라는 모든 서류의 복사본을 챙겨서 끔찍한 결과가 벌어졌을 때, 마이크에게 언제 무슨 말을 했는지 보여줄 수 있도록 만반의 준비를 갖췄다. 이것은 수동적 공격이다.)

예라고 말하는 비용

우리는 언제나 예라고 말하고 싶다. 잘 돌아가는 팀의 관리자와 개발자들은 서로 만족할 수 있는 계획이 나올 때까지 협상한다. 그러나 가끔은 두려움 없이 '아니'라고 말하는 것이 올바른 '예'를 말하는 방법일 수 있다.

3장 예라고 말하기

약속을 뜻하는 말

"말하고 진심을 담고 실행하라."

약속을 하는 행동은 세 부분으로 나뉜다.
1. 하겠다고 말한다.
2. 진심을 담는다.
3. 실제로 실행한다.

몇몇은 말은 진심이지만 절대 행동으로 옮기지 않는다. 다음 예는 약속이 아님을 알려주는 표시다.

• 필요/해야 한다: "이걸 끝내야 해." "살 좀 빼야 할 필요가 있어." "누군가는 해야 해."
• 희망/바람: "내일까지 끝나면 좋겠는데." "언젠가 다시 만나길 바라." "시간이 좀 더 있었으면 좋겠어." "컴퓨터가 더 빨랐으면 좋겠어."
• 하자: ("내가..."라는 말은 함께하지 않음) "언제 한 번 만나자." "이거 끝내자."

약속을 뜻하는 말은?

"나는 언제까지 할 것이다(I will ... by ...)"라는 말은 진심으로 하는 약속이다.

원칙을 가지고 의사소통하기

일정을 예로 들어보자. 무리한 일정을 감수해야 한다고 요청 받을 때, 개발자는 원칙(테스트 작성, 리팩토링, 전체 회귀 테스트 묶음 등)을 깨고 그 일정을 받아들여 해내고 싶은 유혹을 받는다.

여기가 바로 프로가 선을 그어야 할 자리다. 원칙을 깨면 느려질 뿐, 더 빨리 끝나지 않는다. 또한 프로는 특정 수준을 만족시켜야 할 책임이 있다.

자신의 한계를 안 채 효과적으로 일할 수 있는 초과 근무 시간이 어느 정도인지, 초과 근무 후 어느 정도의 시간이 있어야 컨디션을 회복할 수 있는지를 계산해 일정을 조정할 순 있으나, 원칙을 깨면 안 된다.

4장 코딩

준비된 자세

코딩은 여러 대립 요소를 한꺼번에 교묘히 양립시켜 다뤄야 하기 때문에 농축된 집중력이 필요한 지적 활동이다.

1. 코드는 반드시 동작해야 한다. 풀고자 하는 문제가 어떤 문제며 어떻게 풀어야 하는지 확실히 이해해야 한다. 코드에 믿음이 가는지 확인해야 하며, 구석구석 지속적으로 관리해야 한다.

2. 코드는 고객이 제시한 문제를 반드시 풀어야 한다. 고객의 진정한 요구사항을 파악하여 고객의 필요를 충족시키고 문제를 해결해야 한다.

3. 코드는 기존 시스템에 잘 녹아들어야 한다. 기존 시스템의 경직성, 취약함, 불투명도를 높이면 안되며, 의존성을 잘 관리해야 한다.

4. 코드는 가독성이 높아야 한다. 만든 사람의 의도가 드러나도록 코드를 잘 다듬어야 한다.

충분히 강한 집중이 수반되지 않으면, 잘못된 코드를 만들게 된다. 그러니 지치거나 주의력이 흩어졌다면 코드를 만들지 말고, 정신을 집중할 방법을 찾아라.

몰입 영역

몰입은 개발자들이 코딩을 하는 동안 빠져드는 고도로 집중한 의식의 터널시야 상태다. 이때가 생산적이라 느끼는 사람들이 많다.

몰입에 빠지지 마라. 이 의식 상태는 생산적이지 않다. 단지 가볍게 명상에 잠겨 속도 감각에 몰두한 나머지 확실한 이성적 판단이 흐려진 상태다. 영역에 빠진 상태에서는 큰 그림을 놓쳐, 나중에 되돌려야 할 결정을 내리기 쉽니다. 때문에 빠르게 코드를 만들지만, 나중에 다시 살펴야 하게 된다.

진퇴양난에 빠진 글쟁이

어떤 때는 그냥 코드가 써지지 않기도 한다. 글쓴이의 주된 원인은 수면인데, 이때 P.P를 하는게 큰 도움이 될 수 있다.
또한 창의적인 입력이 있을 때 창의적인 출력이 나오기 쉬우므로, 본인에게 창의력을 불러일으킬 수 있는 일들을 해보자.(여러 분야의 글 읽기 등)

디버깅 시간

디버깅 시간을 가능한 한 0에 가깝게 줄이는 일은 프로가 짊어진 의무다. 오류를 만드는 소프트웨어 개발자는 프로답지 않다. 테스트 주도 개발을 했을 때, 디버깅 시간을 현저히 줄일 수 있다.

속도 조절

프로 개발자는 기력을 보존하고 창의성을 챙겨야 한다. 피곤하면 창의성과 총명함이 사라진다. 곤경에 빠졌을 때나 피곤할 때는 잠시 자리를 떠나라. 자신과 팀의 속도를 조절하라.

창의적이고 영리하게 일하는 형태를 배우고 그것들로부터 이득을 얻어내야지, 그 반대가 되어서는 안 된다.

문제 해결

너무 강한 집중에 억눌렸을 때 창의성이 떨어지기도 한다. 글쓴이는 집까지 운전을 하거나 샤워를 할 때 수많은 문제를 풀었다. 가끔 문제를 푸는 최고의 방법은 집에 가서 저녁을 먹고 TV를 보고 잠을 잔 다음 다음날 아침에 일어나서 샤워하는 것이다.

일정을 못 지키다

언젠가는 마감을 못 지키는 날이 온다.
일정 지연을 관리하는 요령은 이른 감지와 투명성이다. 정기적으로 목표 대비 진척을 측정하고, 사실을 바탕으로 한 세 가지 완료일자 - 최선의 경우, 최악의 경우, 성공 가능성이 가장 높은 값인 nominal 추정치 - 를 마련하라. 추정에 희망을 섞지 말고, 매일 이 숫자들을 갱신하고, 팀과 관계자들에게 공유하라.

희망

위에서 언급한 세 숫자들이 마감일을 놓칠지도 모른다는 사실을 보여준다면, 팀과 관계자들이 이 상황을 확실히 이해하도록 만들고 반드시 '실패 대비용 후퇴 계획'을 세우도록 해야 한다. 어떤 사람도 희망을 갖게 만들면 안 된다.

질주

관리자가 당신에게 마감을 지키도록 무슨 짓이든 해보라고 한대도, 추정을 고수해야 한다. 상사의 압박에 굴복해 마감일을 지키려 노력해보겠다고 동의하는 개발자는 형편없는 개발자이다. 이는 스스로와 팀, 이해 관계자들에게 잘못된 희망을 주기 때문에 재앙으로 가는 레시피이다. 모든 사람이 문제를 대면하는 것을 피하게 만들고, 힘들지만 꼭 필요한 결정이 늦어진다.

초과 근무

20% 시간을 더 일한다고 20% 더 작업이 완료되지 않는다. 더구나 초과 근무는 2~3주 이상 지나면 확실히 실패한다.

1) 개인적으로 감당 못할 정도거나 2) 2주 이하인 단기간이 아니거나 3) 초과 근무 노력이 실패할 때를 대비한 후퇴 계획을 상사가 가지고 있지 않다면 초과 근무에 동의하면 안 된다.

가짜 출시

끝내지 않았는데 끝냈다고 말하는 짓은 개발자가 할 수 있는 가장 최악의 일이다.

이보다 더 교활한 경우는 '완료'의 뜻을 새롭게 정의해 합리화할 때다. 충분히 끝냈다고 스스로를 설득하고 다음 업무로 넘어간다. 나중에 시간이 충분할 때 남아 있는 어떤 일도 처리할 수 있다고 합리화한다.

이는 전염성이 있는 행동 방식이다. 팀이 이런 함정에 빠지면 관리자는 모든 일이 순조롭다는 말을 듣고 문제가 곪을 때까지 아무도 보지 못한다.

도움 & 다른 사람 돕기 & 도움 받기

아무리 기술이 뛰어나도 반드시 다른 프로그래머의 생각과 아이디어에서 도움을 받는다.

따라서 서로를 도울 준비를 하는 일은 프로그래머의 의무다. 타인을 돕기 위해 약간의 시간도 마련하지 못할 만큼 중요한 업무는 없다. 같은 팀 동료가 어떤 상태인지 주의를 기울여야 한다. 누군가 곤란에 빠진 것을 봤다면 도움을 줘야 한다.

다른 이가 나를 도울 때는 감사해 하고 기꺼이 도움을 받아들여라. 영역을 지키는 듯한 행동은 하지 마라. 도움을 부탁하는 방법을 배워라.

멘토링

경험이 적은 프로그래머를 훈련시키는 일은 경험이 더 많은 프로그래머의 의무다. 선배가 주는 효과적인 멘토링 말고는 본인의 노력 이상으로 더 빨리 젊은 개발자가 제대로 일하게 만들 방법이 없다.
그러므로 후배 개발자를 보살피고 멘토링하는 데 시간을 들이는 일은 프로로서의 윤리 문제다. 같은 맥락에서 후배 개발자는 선배에게 멘토링을 구하는 일이 프로로서의 의무다.