The Clean Coder (더 클린 꼰대)

밥 아저씨(로버트 마틴) 시리즈..

클린 코드

더 클린 코더

클린 코더 : 단순 기술자에서 진정한 소프트웨어 장인이 되기까지

코딩의 달인이라도 반드시 프로라 말하기는 힘들다. 이 책은 프로를 향한 여정을 서술한다.
지난번 책 `클린 코드`가 코딩의 달인이 되는데 도움이 되었다면, `클린 코더`는 장인(프로)이 되는데 도움이 되는 그런 책.
저자가 1969년 시간제 프로그래머로 취업 후 저지른 잘못한 일(범죄의 사건일지)들, 초년생 때 했던 실수들을 피할 수 있도록 만들어주는 안내서.

 

1장 프로의 마음가짐

프로의 마음가짐(프로페셔널리즘)은 명예와 긍지의 상징이기도 하지만, 책임과 의무를 나타낸다.
프로가 아닌 사람이 잘못을 저지르면 회사가 뒤치다꺼리를 한다. 하지만 프로가 실수하면, 스스로 뒷감당을 해야 한다.
프로페셔널리즘은 책임이 전부라 해도 과언이 아니다.

책임감을 가져라

1979년의 장애) 테스트를 소흘히 한 이유는 제때 선적했다고 떠벌리고 싶었기 때문이다. 그게 내 체면을 세우는 일이었다. 고객이나 회사는 뒷전이었다. 관심을 가졌던 건 내 평판뿐이었다. 책임감을 가지고 미리 톰에게 테스트가 끝나지 않아서 제때 선적할 수 없다고 말했어야 옳았다.

무엇보다도 해를 끼치지 마라

기능에 해를 끼치지 마라

소프트웨어는 너무 복잡해서 오류가 생길 수밖에 없다. 안타깝지만 너무 복잡하다는 이유로 책임이 사라지진 않는다. 인체는 너무 복잡해서 전부 이해하지 못하지만, 의사들은 여전히 해를 끼치지 않는다는 히포크라테스 선서를 지킨다.
완벽한 소프트웨어를 만드는 일이 사실상 불가능하다는 것이지 완벽하지 않아도 괜찮다는 뜻은 아니다.
우선 사과하는 법을 익혀야 한다. 같은 오류를 반복하면 안 된다. 0이 되지는 않겠지만 가능한 0에 가깝게 만드는 게 당신 책임이다.
QA는 아무것도 찾지 못해야 한다
QA가 문제를 찾을 때마다, 더 나쁜 경우 사용자가 문제를 찾을 때마다, 개발자는 놀라움과 분함을 느껴야 마땅하며, 다시는 그런 일이 생기지 않도록 마음을 다져야 한다.
제대로 작동하는지 아닌지 알아야 한다
코드가 잘 돌아가는지 아닌지 알려면 어떻게 해야 할까? 간단하다. 테스트하고 또 테스트하라.

구조에 해를 끼치지 마라

전체 구조를 희생하면서까지 기능을 추가하는 일이 헛수고라는 사실은 프로라면 당연히 알고 있다. 구조가 좋아야 코드가 유연해진다. 구조가 위태로우면 미래도 위태롭다.
소프트웨어가 바꾸기 쉬운지 아닌지 증명하는 유일한 길은 실제로 조금 바꿔보는 것이다. 바꾸기가 생각만큼 쉽지 않다면, 설계를 갈고 닦아서 다음 번에는 더 쉽게 바꿀 수 있도록 만들어야 한다.
보통 사람들은 동작 중인 소프트웨어를 계속 바꾸는 일이 위험하다고 생각한다. 아니다! 정말 위험한 일은 소프트웨어를 고정된 상태로 두는 일이다. 소프트웨어를 구부리지 않는다면, 정말 변화가 필요할 때, 소프트웨어가 단단히 굳어있을 것이다.
왜 코드를 망칠까 봐 겁이 날까? 테스트가 없기 때문이다. 프로 개발자는 코드와 테스트에 확신이 넘치기 때문에, 시도 때도 없이 이리 저리 코드를 바꿔도 마음이 평안하다.

직업 윤리

한 주는 168시간이다. 회사 일에 40시간, 자기 개발에 20시간, 56시간 잠을 자면 52시간을 다른 일에 쓸 수 있다. 이렇게까지 시간을 쓰기 싫을지도 모른다. 그건 좋다. 하지만 자신을 프로라고 생각해선 안 된다. 프로는 직업을 돌보는 데 시간을 투자한다.

전산 분야 지식을 익혀라

디자인 패턴 : 24가지 GOF 패턴과 POSA 패턴
설계 원칙 : SOLID 객체지향 원칙, 컴포넌트 개념
방법론 : XP, 스크럼, 린, 칸반, 폭포수, 구조적 분석, 구조적 설계 개념
원칙 : 테스트 주도 개발, 객체지향 설계, 구조적 프로그래밍, 지속적 통합, 짝 프로그래밍 실천
도구 : UML, 데이터 흐름도, 구조 차트, 페트리 넷, 상태전이 다이어그램과 테이블, 흐름도, 결정 테이블

끊임없이 배우기

IT 산업은 미친듯이 바뀌기 때문에, 어마어마하게 공부해도 간신히 따라잡는 정도다.

연습

일상적인 업무를 연습이라 부르면 안 된다. 일상 업무는 연습이라기보다 공연이다. 업무라는 공연을 떠나 기술을 개선하고 향상시키고자 하는 목적만으로 하는 훈련이 바로 연습이다.

함께 일하기

서로 많이 배울 뿐 아니라, 일도 빨리 끝나고 오류가 더 적다. (짝 프로그래밍) 때때로 혼자만의 시간을 가질 수 없다면 정신이 나갈지도 모른다.

멘토링

배우기에 가장 좋은 방법은 가르치는 것이다. 프로라면 후배들을 멘토링하는 책임을 져야 한다.

업무 지식을 익혀라

프로 소프트웨어 개발자는 자신이 프로그래밍하는 제품의 업무 분야 지식을 알아야 한다.
프로답지 못한 행동 중에서도 최악은 제품 사양이 사업 진행에 이치가 맞는지 따져보지도 않고 그저 사양(spec)에 따라 코딩하는 일이다.
사양에 오류가 있는지 알아보고 이의를 제기할 수 있을 만큼 업무를 알아야 한다.

회사와 고객에 동질감을 가져라

회사의 문제가 자신의 문제다. 문제가 무엇인지 이해하고 최선의 해결책을 만들기 위해 일해야 한다.
개발자들끼리는 동질감을 가지기 쉽다. 회사를 대할 때 우리 vs 우리가 아닌 나머지라는 태도에 빠지기 쉽다. 프로라면 무슨 짓을 해서라도 이런 일을 피해야 한다.

겸손

자칫하면 어마어마한 피해를 입힐지도 모르는 위험을 무릅쓰고, 자신만만하게 기계를 이리저리 정밀하게 움직이도록 명령한다. 그러므로 프로그래밍은 극도로 오만한 행위다. 프로는 자신이 오만하며 겸손한 척할 생각이 없다는 사실을 안다.
그러나 프로는 때때로 실패한다는 사실과 위험 계산이 틀릴지도 모른다는 것 그리고 언젠가 자신의 능력이 부족해지는 날이 온다는 사실을 잘 안다.
절대 다른 사람을 비웃지 않지만, 자신이 비웃음거리가 될 만하다면 기꺼이 받아들인다. 다른 사람이 실수했다고 망신을 주지 않는다. 다음 번 실패할 사람이 자신임을 알기 때문이다.

2장 아니라고 말하기

노예들에겐 아니라는 말이 허락되지 않는다. 단순 일꾼들은 아니라고 말하길 꺼린다. 하지만 프로는 아니라고 말해야 마땅하다. 아니라고 말하는 일이야 말로 맡은 작업을 완료하는 유일한 길이다.
확신이 없는 긍정적인 답변("한 번 해볼게요")은 다정하고 대립도 없고 서로 웃을 수 있지만, 프로답지 못한 처신일 수 있다.
최선의 결과를 이끌어내기 위해 아니라고 말하며 상호 협의하에 해결책을 만들자.
언쟁을 하고, 어색한 순간이 있더라도 목표가 완벽히 정의되지 않은 상황에서 적극적으로 목적 달성을 위해 노력하는 것이 중요하다.

3장 예라고 말하기

프로는 모든 업무 요청에 예라고 대답할 필요는 없다. 하지만, "예"라고 대답할 수 있는 창의적인 방법을 찾는 데 고심해야 한다. 프로가 예라고 대답할 때는 약속을 뜻하는 언어를 사용해서 내뱉은 말에 모호한 부분이 없도록 해야 한다.
- 개인적으로 책임을 지지 않으려는 표현 (x)
- 업무를 통제하려 하지 않고 오히려 상황 때문에 피해자가 된 것처럼 행동 (x)
올바른 예로 "나는 언제까지 할 것이다.". 어떤 일에 완전한 책임을 져야 한다.

4장 코딩

코드 차체에 대한 규칙과 원칙이 아닌, 코드를 짤 때 행동과 기분, 태도에 대한 규칙과 원칙. 자신감과 오류 감각의 근본.

준비된 자세

1. 첫째, 코드는 반드시 동작해야 한다.
2. 코드는 고객이 제시한 문제를 반드시 풀어야 한다. (요구사항 충족)
3. 코드는 기존 시스템에 잘 녹아들어야 한다.
4. 코드는 다른 프로그래머가 읽기 쉬워야 한다. (만든 사람의 의도가 드러나도록 다음어야 한다)

몰입 영역

코딩하는 동안 빠져드는 고도로 집중한 의식의 터널시야 상태. 몰입 경험을 꽤나 해본 사람으로서  이 의식 상태는 사실 극도로 생산적이지도 않고 절대 옳은 상태도 아니다. 몰두한 나머지 이성적 판단이 흐려진 상태이다.
이런 상태에 빠진다고 느껴질 때면, 짝 프로그래밍을 하라. (짝 프로그래밍의 무시무시함을 여러번 강조!)
다만, 훈련을 할 때는 반드시 영역에 빠져야 한다.

속도 조절

개발은 마라톤이지 단거리 질주가 아니다. 곤경에 빠졌을 때나 피곤할 때는 잠시 자리를 떠나라.

일정을 못 지키다

일정 지연을 관리하는 요령은 이른 감지와 투명성이다.
최악의 경우는 마지막 순간까지도 다른 사람들에게 제 시간에 맞출 거라고 말한 다음 모두를 실망시킬 때다.
최선의 경우, 최악의 경우, 가능성이 가장 높은 추정치를 마련하여 공유하고 갱신하라.

질주

이미 가능한 선택지를 모두 고려했고(정말 고려했기 때문) 일정을 개선할 유일한 길은 범위를 줄이는 방법뿐임을 상사에게 말하라. 질주하라는 부추김에 넘어가면 안 된다.
압박에 굴복해 허리띠를 졸라매고 마감일을 지키려 노력해 보겠다고 동의하는 형편없는 개발자를 두려워하라. 손쉬운 길로만 가려 하고 초과 근무를 하며 기적을 바라는 헛된 희망은 재앙으로 가는 길이다.

가짜 출시

프로그래머가 저지르는 여러 가지 프로답지 못한 행동 중에서도 가장 최악은 끝내지도 않았는데 끝냈다고 말하는 짓이다. 더 교활한 경우는 '완료'의 뜻을 새롭게 정의해 합리화할 때다. 아무것도 안해도 된다면 '완료'하기는 식은 죽 먹기다!
팀이 이런 함정에 빠지면 관리자는 모든 일이 순조롭다는 말을 듣는다. 마치 장님이 철길 위에서 소풍하는 것과 같다. 미완료 작업이라는 화물 열차가 자신들을 덮친다는 사실을 너무 늦을 때까지 아무도 보지 못한다.

도움

프로그래밍은 어렵다. 젊을수록 이 말이 믿기지 않을 것이다. 어찌됐건 프로그래밍은 수많은 if와 while 문장의 덩어리다. 두 문장을 듬뿍 끼얹어 놓고 최고가 되기를 바라면 안 된다. 그보다는 시스템을 작고 알기 쉬운 단위로 주의깊게 쪼개야 한다. 그 단위는 가능한 한 서로 간섭이 적도록 만들어야 하는데, 이 부분이 어렵다.
사실 프로그래밍은 너무 어려워서 한 사람의 능력으로는 잘 해내기가 어렵다. 아무리 기술이 뛰어나도 반드시 다른 프로그래머의 생각과 아이디어에서 도움을 받는다.

이런 이유로 서로 도울 준비를 하는 일은 프로그래머의 의무다. 다른 사람의 질문을 거부하는 일은 프로가 갖출 윤리 위반이다. 사실 프로라면 명예를 걸고 어떤 때든 도움을 줘야 한다.
같은 팀 동료가 어떤 상태인지 주의를 기울여야 한다. 누군가 곤란에 빠진 것을 봤다면 도움을 줘야 한다. 자신의 도움으로 생기는 효과가 크다는 사실에 꽤 놀랄 것이다. 자신이 다른 이보다 영리해서가 아니라 그저 신선한 관점이 문제를 푸는 데 커다란 기폭제가 된 것이다.

다른 이가 나를 도울 때는 감사해야 한다. 고맙게 그리고 기꺼이 도움을 받아들여라. 영역을 지키는 듯한 행동은 하지 마라. 몹시 바빠 정신이 없다는 이유로 도움을 거부하지 마라. 명예를 걸고 타인을 도와야 하듯이 명예를 걸고 도움을 받아야 함을 기억하라.
도움을 부탁하는 방법을 배워라. 도움을 요청해라. 다시 한 번 말하지만 이는 프로의 직업 윤리에 관련된 문제이다. 쉽게 도움을 받을 수 있는 데도 계속 막힌 상태를 유지하는 일은 프로답지 않다.
* 프로그래머는 오만하고 자신에게만 열중하는 내향적인 경향이 있다. 우리는 사람 사귀기를 좋아해서 프로그래머가 된 게 아니다. 우리가 프로그래밍에 빠지는 이유는 무미건조한 세부사항에 깊게 집중하기, 많은 개념을 한 번에 교묘히 다루기, 자기 두뇌가 지구만큼 크다는 사실을 스스로에게 증명하기를 좋아하기 때문이다. 또한 그러는 동안은 골치 아프고 복잡한 대인관계를 피할 수 있다. * 그러나 효과적인 프로그래밍에는 협력이 매우 중요하다. 그러므로 우리 중 많은 사람에게 협력은 본능이 아니므로 협력으로 이끄는 원칙이 필요하다.

경험이 적은 프로그래머를 훈련시키는 일은 경험이 더 많은 프로그래머의 의무다. 마찬가지 맥락에서 젊은 프로그래머는 선배에게 멘토링을 구하는 일이 프로로서의 의무다.

---

나머지 내용들

테스트 주도 개발

TDD 짱. 하지만 종교나 마법이 아니기 때문에 적절하게..

연습

어떤 식으로든 연습하라. 회사의 의무가 아니라 자신의 의무.

인수 테스트

개발은 물론이고 의사소통 또한 프로 개발자의 임무이다.

테스트 전략

단위 테스트나 인수 테스트 작성은 훌륭한 일이긴 하지만 충분치 않다. 훌륭한 테스트 전략이 필요하다.
QA는 오류를 찾지 못해야 한다. 다시 한 번 강조.
테스트 자동화 피라미드 ( 단위 테스트 > 컴포넌트 테스트 > 통합 테스트 > 시스템 테스트 > 탐색 테스트 )

시간 관리

프로 개발자는 부지런히 시간과 집중력(마나)을 관리해야 한다.
진흙탕은 막다른 길보다 더 나쁘다. 진흙탕이 막다른 길보다 나쁜 이유는 앞으로 가야 할 길이 눈에 보이며 그 길은 되돌아가는 것보다 더 짧아 보이기 때문이다(하지만 짧지 않다). 그 상태로 전진하는 일은 스스로를 속이고 팀과 회사와 고객까지 속이는 짓. 프로는 막다른 길보다 진흙탕을 더 무서워해야 한다. 항상 경계하고 최대한 일찍 신속하게 벗어나자.

추정

사업 가치가 추정에 따라 좌지우지. 우리 평판도 달려있다.
지킬 수 없는 약속은 하지 않으며, 달성할 수 있다는 확신이 없는 일은 약속하지 않는다.
예상 완료 시간과 가능성 분산을 나타내는 가능성의 추정 값.
추정 값을 만드는 여러 방법들 소개 : PERT 기법(3방 분석), 광대역 델파이의 기법의 변종들(계획 포커, 관계 추정, 3방 추정 등), 큰 수의 법칙(여러 개의 작은 업무로 쪼개 추정하여 오류를 상쇄)

압박

피할 수 있으면 피하고 피할 수 없을 때는 극복해라.
피하기: 주의 깊게 약속하고, 규율을 따르고, 깔끔히 유지.
극복하기: 침착함을 유지하고, 의사소통하고, 규율을 따르고, 도움을 받는 것(짝 프로그래밍).

함께 일하기

코드 소유: 삐걱대는 팀의 모습 중 가장 나쁜 모습은 각 프로그래머가 자신의 코드에 벽을 두르고 다른 프로그래머들이 건드리지 못하게 하는 행동이다. 재앙으로 가는 지름길. 팀 전체가 모든 코드의 소유권을 가지는 편이 좋다. 개인이 아니라 팀이 코드를 소유하라.
짝 프로그래밍은 최고다. (반복)

팀과 프로젝트

팀은 프로젝트보다 만들기 더 어렵다. 팀을 만들어 여러 프로젝트를 맡기는 게 낫다.

스승과 제자 그리고 장인 정신

멘토링에 대한 이야기.
우선 장인이 된 다음 자신의 장인 정신을 보여주도록 해라.
장인 정신은 장인들이 지니고 있는 사고방식으로써 가치, 규율, 기술, 자세 및 답변을 포함하는 밈(mem)이다.
이것은 관찰로써 전해진다.