클린 코더 - The Clean Coder

이 책을 읽기 시작한지는 시간이 꽤 흘렀다. 하지만 시작과 동시에 여러 가지 일들로 인해 정신이 없었고, 책을 읽을 여유를 갖지 못했었다. 물론 핑계일지도 모르지만... 꽤 정신없이 시간이 흘러가다보니, 당초 책을 읽기 시작한 시점부터 1개월이 지난 지금에 이르러서야 글을 작성하게 되었는데.. 반성하자.. 그래도 멈추지 않고 꾸준히 무언가를 한다는 것은 중요한 일이니, 약간의 박수를 스스로에게 보내본다.

🧭 프로 소프트웨어 개발자란 어떤 존재인가?

저자는 우리에게 프로 개발자가 어떤 존재인지에 대해서 말해주고 있다. 저자 본인의 경험을 녹여서 이야기해주고 있으며, 친근한 동네 아저씨가 "옛날 옛적에 말이야~(라떼는...) 하면서 이야기를 술술 풀어놓는 느낌이다. 그래서 편하게 읽을 수 있었고, 도움이 되는 조언들이 정말 많았다. 모든 내용을 다룰 수는 없으니 궁금하다면 직접 읽어보시라. 전체적으로 '프로의 마음가짐'에 대해서 논하고 있다. 그 외에도 부수적이라 느껴지지만 반드시 필요한 여러 가지 것들(컨디션, 추정, 시간 관리 등등..)에 대해서도 말해주고 있다.

책 속의 내용 중에서 일부를 발췌해서 아래에 적어두었다. 공감이 될 수도, 아닐 수도 있겠지만 적어도 필자에게는 공감이 되었던 부분들이다. 테스트에 대해 언급하고 설명해주는 부분이 정말 좋았는데(지식적인 측면에서), 추후에 정리해두면 좋을 것 같다(정리하자 미래의 나).

• 프로페셜리즘(professionalism)이란 용어에는 숨은 뜻이 있다. 당연히 명예와 긍지의 상징이기도 하지만, 동시에 책임과 의무를 나타내기도 한다. 프로페셜리즘은 책임이 전부라 해도 과언이 아니다.

• 약속을 하는 행동은 세 부분으로 나뉜다. 첫 번째. 하겠다고 말한다. 두 번째. 진심을 담는다. 세 번째. 실제로 실행한다.

• 지쳤을 때는 코드를 만들지 마라. 헌신과 프로다운 모습은 무턱대고 많이 일하는 데서가 아니라 원칙을 지키는 모습에서 나온다.

• 소프트웨어 개발은 마라톤이지 단거리 질주가 아니다. 프로 프로그래머는 기력을 보존하고 창의성도 챙긴다.

• TDD는 확신, 용기, 오류 감소, 문서화, 설계를 향상시키는 원칙이다. 하지만 종교나 마법은 아니다.

• 모든 프로는 어떤 식으로든 연습을 한다. 개인 시간까지 바쳐 연습하는 이유는 기술을 갈고 닦는 일이 회사의 의무가 아니라 자신의 의무라는 사실을 알기 때문이다(매우 중요! 공부하자!).

• 개발은 물론이고 의사소통 또한 프로 개발자의 임무다. 입력이 형편없으면 출력도 형편없다(garbage-in/garbage-out)는 사실은 프로그래머에게도 해당된다는 사실을 명심하자. 따라서 프로 프로그래머는 팀 동료나 사업부와의 의사소통이 정확하고 도움이 되도록 신경 써야 한다.

• 프로 개발자에게 완료에 대한 정의는 단 하나 뿐이다. 완료란 모든 코드를 작성했고, 모든 테스트를 통과했음을 말하는 것이고, QA 전문가와 이해당사자들이 이를 인수했다는 뜻이다.

• 인수(acceptance) 테스트는 요구사항이 언제 완료되는지를 정의하기 위해 이해당사자들과 프로그래머들이 힘을 모아 작성하는 테스트라고 정의한다. 인수 테스트의 목적은 소통, 명확성 및 정밀성이다.

• 인수 테스트는 단위 테스트가 아니다. 단위 테스트는 프로그래머가 프로그래머들을 위해 만든다. 단위 테스트는 코드의 최하위 구조와 행동을 설명하는 공식 디자인 문서다. 단위 테스트를 읽는 사람은 사업부가 아니라 프로그래머다.

• 인수 테스트는 사업부를 위해 사업부가 작성한다(심지어 개발자가 마무리를 했더라도). 인수 테스트는 사업적 관점에서 시스템이 어떻게 운영되어야 하는지를 구체적으로 표시한 공식 요구사항 문서다. 보는 사람은 사업부와 프로그래머다.

• 회의는 필요하다. 하지만 동시에, 회의는 엄청난 시간 낭비다.

• 자신의 시간관리는 자신만이 할 수 있다.

• 진흙탕은 막다른 길보다 더 나쁘다. 진흙탕이 막다른 길보다 나쁜 이유는 앞으로 가야 할 길이 눈에 보이며 그 길은 되돌아가는 것보다 더 짧아 보이기 때문이다(하지만 짧지 않다).

• 약속은 꼭 지켜야 한다. 프로는 달성할 수 있다는 사실을 알지 못하면 약속하지 않는다. 약속은 확실함에 관한 문제다. 다른 사람들은 당신의 약속을 받아들이고 거기에 기반해 계획을 짠다. 약속을 지키지 못랄 때 그들에게 그리고 스스로의 명성에 손해가 되는 비용은 어마어마하다. 약속을 못 지키는 행위는 부정직한 일이며 대놓고 하는 거짓말과 큰 차이가 없다.

• 추정은 어림짐작이다. 약속은 포함되지 않는다. 아무런 약속도 하지 않는다. 추정이 빗나가는 일은 전혀 불명예가 아니다. 추정을 하는 이유는 얼마나 걸릴지 모르기 때문이다. 추정은 숫자가 아니다. 추정은 분포다.

• 위기 상황에서도 편하게 느껴지는 규율을 골라라. 그러고 나서 그 규율을 항상 따라라. 이 규율을 따르는 일이야말로 위기상황을 피하는 최선의 방법이다. 마감 전 압박질주를 할 때가 와도 태도를 바꾸지 마라.

• 소프트웨어는 대부분 팀 단위로 만든다. 팀원들이 프로답게 힘을 모을 때 팀은 가장 효율적이다. 독불장군이나 은둔자는 프로답지 못한 사람이다.

• 프로는 탑승한 배가 어떻게 항해하는지 관심을 기울인다. 프로 프로그래머는 사업을 이해하는 데 시간을 투자한다. 즉, 사업 목표를 속속들이 이해해야 한다는 뜻이다. 왜 코드를 작성하고, 그 코드로부터 회사가 어떤 이득을 얻을지 알아야 한다.

• 가장 효율적이고 효과적인 코드 검토 방법은 코드를 만들 때부터 힘을 모으는 것이다. 프로는 함께 일한다. 추가로, 혼자 일할 때 더 잘 할 가능성은 그리 높지 않다. 물론 혼자 일하는 게 적절한 경우도 있다.

• 프로그래밍은 온전히 다른 사람과 함꼐 일하는 것에 관한 업무다. 프로그래밍을 하며 일과 시간을 보내고 싶다면, 우리가 대화하고자 노력해야 할 상대는 바로 사람이다.

• 이런 법칙이 있다. 절반의 사람이란 없다.

• 팀은 프로젝트보다 만들기가 더 어렵다.

• 장인이란 서두르지 않으면서도 일을 빠르게 처리하며 합리적인 평가를 제공하고 업무를 처리하는 사람이다. 장인은 프로다.

• 장인 정신은 장인들이 지니고 있는 사고방식으로써 가치, 규율, 기술, 자세 및 답변을 포함하는 밈(meme)이다. 장신 정신 밈은 사람을 통해 전해진다. 밈의 수용은 이성적인 결정이라기보다는 정서적인 것이며, 매우 인간적이다.

🛠 프로 소프트웨어 개발자라면 알아야 하는 최소한의 기술 목록

저자는 아래의 기술들은 최소한 알아야 한다고 말하고 있다. 처음보는 것들도 굉장히 많은데, 공부하도록 하자.

• 디자인패턴 : 24가지 GOF 패턴을 설명할 수 있고, POSA 패턴을 실무에 적용할 수준으로 알아야 한다.
• 설계원칙 : SOLID 객체지향 원칙을 알아야 하고 컴포넌트 개발 개념을 충분히 이해해야 한다.
• 방법론 : XP, 스크럼, 린, 칸반(kanban), 폭포수, 구조적 분석, 구조적 설계 개념을 충분히 이해해야 한다.
• 원칙 : 테스트 주도 개발(TDD), 객체지향 설계, 구조적 프로그래밍, 지속적 통합, 짝 프로그래밍을 실천해야 한다.
• 도구 : UML, 데이터 흐름도(DFD), 구조 차트(Structure Chart), 페트리 넷(Petri Net), 상태 전이 다이어그램과 테이블(State Transition Diagram and Table), 흐름도(flow chart), 결정 테이블(decision table)을 어떻게 쓰는지 알아야 한다.

참고자료

• 클린 코더 (저자 : 로버트 C. 마틴)