클린 코더를 보고 정리한 내용입니다.
- 클린 코더
- 목차
- 1장 프로의 마음 가짐
- 2장 아니라고 말하기
- 3장 예라고 말하기
- 4장 코딩
- 5장 테스트 주도 개발
- 6장 연습
- 7장 인수 테스트
- 8장 테스트 전략
- 9장 시간 관리
- 10장 추정
- 11장 압박
- 12장 함께 일하기
- 13장 팀과 프로젝트
프로페셔널리즘 이란 명예와 긍지의 상징이기도 하지만, 동시에 책임과 의무를 나타내기도 한다. 물론 두 가지는 뗄래야 뗼 수 없다. 책임지지도 못할 일에 명예와 긍지를 얻을 수는 없다. 프로가 아니라면 세상 상기가 훨씬 쉬워진다. 프로가 아니라면 하는 일에 책임을 느낄 필요가 없으며 회사에 고스란히 책임을 떠념겨도 된다. 프로가 아닌 사람이 잘못을 저지르면 회사가 뒤치다꺼리를 한다. 하지만 프로가 실수하면, 스스로 뒷감당을 해야 한다. 프로페셔널리즘은 책임이 전부라 해도 과언이 아니다.
소프트웨어는 너무 복잡해서 오류가 생길 수밖에 없다. 안타깝지만 너무 복잡하다는 이유로 책임이 사라지진 않는다. 프로가 되겠다는 포부를 가지고 있다면, 우선 사과하는 법을 익혀야 한다. 경력을 쌓아가면서 오류를 만드는 바율을 급격히 떨어뜨려 0에 가깝게 만들어야 한다. 0이 되지 않지만 가능한 0에 가깝게 만드는 게 당신책임이다.
QA가 문제를 찾지 못할 것이라고 어느정도 자신할 수 있어야 한다. 코드에 결함이 있는 걸 알면서도 QA에게 코드를 보내는 일은 매우 프로답지 못한 행동이다. QA가 오류를 찾을까? 십중팔구는 오류를 찾는다. 따라서 사과할 준비를 해야한다. 또한 오류가 어떻게 감시망을 뚫었는지 알아내 다시는 그런 일이 생기기 않도록 방비해야 한다. QA가 문제를 찾을 때마다 개발자는 놀라움과 분함을 느껴야 하며, 다시는 그런일이 생기지 않도록 마음을 다져야한다.
테스트하고 또 테스타하아. 월, 화, 수, 목, 금, 토, 일 일곱가지 방식으로 테스트하라. 그렇게 까지 테스트하면 시간이 너무 많이 걸리기 때문에 테스트를 자동화해야한다. 순간에 실행될 수 있는 테스트를 만들고 가능한 자주 돌려라. 100% 테스트 커버리지를 권장하냐고? 권장이 아니라 경력히 요구한다. 작성한 코드는 한 줄도 빠짐 없이 전부 테스트해야 한다. 군말은 필요 없다. 비현실적이라고? 전혀 그렇지 않다. 작성한 코드는 당연히 실행된다. 실행된다면 돌아가는지 알아야 한다. 알 수 있는 방법은 테스트 뿐이다. 어떤 코드는 테스트하기 어렵지 않나? 그렇다. 하지만 그 이유는 코드를 테스트하기 어렵게 설계했기 때문이다. 해결책은 테스트하기 쉽게 코드를 설계하는 것이다.
전체 구조를 희생하면서까지 기능을 추가하는 일은 헛수고라는 사실은 프로라면 당연히 알고 있다. 구조가 좋아야 코드가 유연해진다. 구조가 위태로우면 미래도 위태롭다. 소프트웨어는 변한다라는 생각은 모든 소프트웨어 프로젝트의 기본 가정이다. 이 가정을 어기고 구조를 유연하게 먼들지 못하면 수익 기반인 경제 모델이 취약해진다. 한마디로 변경을 할 때 터무니없는 비용을 치르지 않고 변경할 수 있어야 한다. 정말 위험한 일은 소프트웨어를 고정된 상태로 두는 일이다. 소프트웨어를 구부리지 않는다면, 정말 변화가 필요 할 때, 소프트웨어가 단단히 굳어있을 것이다. 왜 개발자들은 코드 바꾸기를 무서워할까? 테스트가 없기 때문이다.
자기 경력을 회사에 맡기는 개발자에게 재난이 있으라. 회사에서 컨퍼런스, 교육을 해주는 일은 좋은일이다. 회사에서 호의를 베푸는 것이다. 하지만 이런 일이 회사 책임이라고 생각하는 함정에 빠지면 안된다. 회사가 회의를 베풀지 않는다면, 스스로 방법을 찾아야 한다. 그런 호의를 당연시하면 안된다. 주 40시간 업무가 표준이라면 40시간은 회사의 문제를 푸는 데 써야 한다. 자신의 문제를 푸는데 쓰면 안된다.
한 주에 60시간 일할 계획을 짜야 한다. 40시간은 회사를 위해 쓰고 나머지 20시간은 자신을 위해 쓴다. 20시간은 읽고 연습하고 공부하고 경력에 도움이 되는 여러 가지를 하며 보내야 한다. 이렇게까지 시간을 쓰기 싫을지도 모른다. 그건 좋다. 하지만 자신을 프로라고 생각해선 안된다. 프로는 직업을 돌보는 데 시간을 투자한다. 그 20시간 동안은 회사를 위해 일해선 안된다. 경력을 위해 힘써야 한다. 회사와 경력 양쪽에 도움되는 일도 있다. 그렇다면 20시간을 투자하는 일도 합리적이다. 하지만 그 20시간을 자신을 위한 시간임을 명심해야한다. 그 시간은 프로로서 자신의 가치를 높이기 위헤 써야 한다. 소프트웨어 개발자가 된 이유는 소프트웨어에 열정을 느끼며, 그 열정이 프로가 되고 싶다는 바람을 복돋았기 때문일 것이다. 20시간 동안 그 열정을 강하게 만드는 일을 하라. 20시간을 즐겁게 보낼 것이다.
코딩하지 않은 아키텍처에게 재난이 있으라, 그들은 곧 시대에 뒤떨어진다. 새 언어를 배우지 않은 프로그래머에게 재난이 있으라.
프로는 연습한다. 진정한 프로는 기술을 날카롭게 갈고 닦아 항상 준비된 상태로 만들려 애쓴다. 일상적인 업무를 연습이라 부르면 안된다. 일상 업무는 연습이라기보다는 공연이다. 업무라는 공연을 떠나 기술을 개선하고 향상시키고자 하는 목적만으로 하는 훈련이 바로 연습이다.
음악가가 연주에 능숙해지는 방법이 뭘까? 공연이 아니라 연습이다. 그렇다면 음악가들은 어떻게 연습할까? 여러 훈련을 하겠지만 그중에서도 음계, 연습곡, 음계를 빠르게 연주하는 악구라는 특별한 훈련을 한다. 이 훈련들은 끊임없이 반복해서 손가락과 정신을 훈련하고 기술에 익숙해지도록 단련한다. 볼링 점수 계산이나 인수분해 프로그래밍 같은 간단한 훈련을 계속해서 반복한다. 이런 훈련을 폼새라 한다. 폼새는 종류가 다양해서 선택의 여지가 넓다. 품새의 핵심은 손가락과 두되들 단련시키는 일이다.
배움에 도움되는 두 번째 방법은 다른 사람들과 함께 일하는 것이다. 프로 소프트웨어 개발자는 함께 프로그래밍하고, 함께 연습하고, 함께 설계하고 계획하는 데 특히 노력을 기울인다.
배우기에 가장 좋은 방법은 가르치는 것이다. 쓸모 있는 내용을 머릿속에 가장 빠르고 강하게 넣는 방법은 자신이 책임지고 담당하는 사람들과 이야기를 주고 받는 일이다. 가르치고 배울 때 더 큰 이득을 보는 쪽은 선생님이다.
제품의 업무 분야 지식을 알아야한다. 회계 시스템을 만든다면 회계 분야를 알아야한다. 여행 애플리케이션을 만든다면 여행 산업을 알아야한다. 전문가가 될 필요까지는 없지만 적절한 수준에 도닥하기 위해 어느정도 노력을 기울여야 한다. 새로운 분야에 프로젝트를 시작하게 되면, 관련 분야의 책 한두 권 읽어 보자
프로그래밍은 창조 행위다. 코딩은 무에서 유를 만든다. 과감히 혼돈에 질서를 부여한다. 그러므로 프로그래밍은 극도로 오만한 행위다. 프로는 자신이 오만하며 겸손할 척할 생각이 없다는 사실을 안다. 프로는 자신의 일을 이해하고 그 일에 자부심을 가진다. 프로는 자기 능력을 확신하고, 그 확신을 바탕으로 계산한 위험을 과감히 짋어진다.
그러나 프로는 때때로 실패한다는 사실과 위험 계산이 틀릴지 모른다는 것 그리고 언젠가 자신의 능력이 부족해지는 날이 온다는 사실을 잘 안다. 그때가 왔을 때 거울을 보면 오만한 멍청이 하나가 웃는 모습을 보게된다.
그래서 프로는 자신이 웃음거리가 됐을 때, 가장 먼저 웃는다. 절대 다른 사람을 비웃지 않지만, 자신이 비웃음거리가 될 만하다면 기꺼이 받아들인다. 다른 사람이 실수했다고 망신을 주지 않는다, 다음 번 실패할 사람이 자신임을 알기 때문이다.
내일까지 완성하는 일은 불가능하다는 사실을 충분히 알고 있다면, "좋아요 한번 해볼게요" 라는 말하는 것은 업무를 처리하는 것이 아니다. 일을 제대로 처리하는 유일한 방법은 "아니요 불가능합니다" 라고 말하는 것이다.
최악의 선택은 "알았어요, 노력해볼게요"라고 대답하는 것이다. 노력 해본다 라는 말은 없다 노력한다는 약속은 추가로 힘을 쏙기만 하면 목표를 달성할 수 있다고 인정하는 뿐만 아니라, 추가로 힘을 쏟아 목표를 달성하기 위해 온 몽을 바치겠다고 말하는 셈이다. 이것은 무거운 짐이다. "노력"해도 원하는 결과를 만들지 못하면 실패다.
노력하겠다는 약속은 계획을 바꾼다는 약속이다. 지금 계획은 불충분하다고 인정한 셈이다. 새로운 계획도 없고, 어떻게 행동을 바꿔야 할지도 므르고, "노력"하겠다라고 약속 하기 전 그대로 일한다면, 대체 노력하겠다는게 무슨 의미인가? 비축해 둔 에너지도 없고 새 계획도 없고, 행동을 바꿀 생각도 없고, 이성적으로 봤을 때 원래 예측에 확신이 든다면, 노력하겠다라는 약속은 근본적으로 정직하지 못한 행동이며 거짓말이다. 아마 체면을 차리고 대답을 피하려 했음이 틀림 없다.
프로는 종종 영웅이 되기도 하지만 영우이 되려 애썼기 때문이 아니다. 프로가 영웅이 될 때는 업무를 충실히, 제시간에, 예산 안에서 완수했을 때다. 구세주라는 명예를 얻기 위해 존은 프로답지 못하게 행동했다. 성공하는 유일한 길은 프로답지 않게 행동하는 것이라 받아들였기에, 그에 맞는 대가를 치렀다. 좋은 코드는 불가능한가? 프로다운 일 처리는 불가능한가? 나의 답변은 다음과 같다 "아니요. 가능합니다."
약속을 하는 행동은 세 부분으로 나뉜다.
- 하겠다고 말한다.
- 진심을 담는다.
- 실제로 행동한다
적어도 한 명 이상이 지켜보는데 앞에서 어떤일에 완전한 책임을 져야한다. 사람 대 사람으로 다른 사람에게 바로 자신이 해내겠다고 말하는 일이다. 그것이 진심을 담은 약속의 시작이다. 뭔가를 해야만 하는 상황으로 자신을 밀어 넣어야 한다. 말할 때 약속을 담은 단어를 사용하면, 다음 두 단계인 진심을 담고 완수하는 단계로 나아가는 데 도움이 된다.
자신이 모든 상황을 제어할 수 있을 때만 약속해야 한다. 예를 들어 다른 팀에 의존하는 모듈을 끝내는 게 목표라면, 다른 팀과 완전히 하나가 되어서라도 모듈을 끝내겠다고 약속하면 안된다. 다만 목표를 달성하기 위해 아래처럼 구체적인 행동을 한다는 약속은 할 수 있다.
- 인프라스트럭처 팀의 개리 옆에 앉아 모듈의 의존성에 대해서 한 시간 정도 대화를 나눈다.
- 인터페이스를 만들어 다른 팀의 인프라스트럭처에 대한 의존성을 추상화 한다.
- 이번 주 에 빌드 담당자를 최소 세 번 이상 만나, 변경 사항이 회사 빌드 시스템에서 잘 동작하는지 확인한다
- 개인 빌드을 만들어, 모듈 통합 테스트를 실행 한다.
어쨋 거나 다른 사람에게 의존하긴 하지만, 목표 달성을 위해 구체적으로 어떤 일을 하겠다는 약속을 해야한다.
어떻게 할지 몰라도, 목표를 달성하기 위해 어떤 행동을 하겠다라는 약속은 할 수 있다. 출시 전 남은 오류 25개를 모두 고치겠다고 약속을 하는 대신 목적을 달성하기 위해 다음처럼 노력하겠다고 약속한다.
- 25개 오류를 모두 조사하고 재현해본다
- 각 오류를 발견한 QA와함께 오류를 재현해 본다.
- 이번 주에는 오류 수정에만 전념한다.
살다 보면 예상치 못한 일이 일어나기도한다. 그래도 예상했던 목표를 맞추고 싶다면, 지금 당장 예상치를 바꿔야 한다. 약속을 지키지 못하겠다면, 당장 약속한 사람에게 경고의 붉은 깃발을 휘두르는 일이 가장 중요하다.
- 정오에 동료들과 회의 시간에 늦을거 같다는 생각이 든다면 즉시 동료들애게 알려야 한다.
- 해결할 만해 보였던 오류가 발생보다 심각하다는 사실을 하게 됐다면, 깃발을 들여야 한다.
문제가 될지라도 모르는 사실을 다른 사람에게 즉시 알리지 않는다면, 약속을 완수하는 데 필요한 도움을 얻을 기회를 스스로 뺏게 된다.
몰입으로 알려진 극도로 생상적인 상태에 대한 글이 많다 프로그래머들은 코딩을 하는 동안 빠져드는 고도로 집중한 의식의 터널시야 상태다. 자신이 절대 옳다고 느낀다. 따라서 그 상태에 들어가고 싶어 하고 하루 종종 몰입 상태에서 얼마나 있었는지를 따져 스스로 가치를 재기도 한다. 몰입 경험을 꽤나 해본 사람으로서 여러분에게 조언을 하나 하고 싶다. 몰입에 빠지지마라 이 의식 상태는 사실 극도로 생상적이지도 않고 당연히 절대 옳은 상태도 아니다. 단지 가볍에 명상에 잠겨 속도 감각에 몰두한 나머지 확실한 이 성적 판단이 흐려진 상태다.
영역에 빠지면 더 많은 코드를 쓰려 한다. TDD 연습 중이라면 래드/그린/리팩터 주기를 더 빨리 돌려야 한다. 잔잔한 도취감이나 정복감을 느끼려 한다 문제는 영역에 빠진 상태에서는 큰 그림을 놓처, 나중에 되돌려야 할 결정을 내리기 쉽다는 것이다. 짝 프로그래밍이 주는 여러 이점 중 하나는 이 몰입 영역에 빠질 가능성이 없다는 점이다.
언젠가는 마감을 못 지키는 날이 온다. 최고 실력자에게 오고 가장 헌신적인 사람에게도 온다. 일정 지연을 관리하는 요령은 이른 감지와 투명성이다. 최악의 경우는 마지막 순간까지도 다른 사람들에게 제 시간에 맞출 거라고 말한 다음 모두를 실망시킬 때다. 이러지 마라, 대신 정기적으로 목표 대비 진척을 측정하고 사실을 바탕으로 한 세가지 완료일자, 즉 최선의 경우, 최악의 경우, 성공 가능성이 가장 높은 값인 명목 추정치를 마련하라. 세 날짜에 대해 최대한 정직해야 한다. 추정에 희망을 섞지 마라! 세 숫자를 팀과 관계자들에게 알려라, 매일 이 숫자들을 갱신 하라
열흘 안에 끝내리란 희망을 갖지 마라! 희망은 프로젝트 살해자다. 희망은 일정을 파괴하고 자신의 평판을 망가뜨린다. 희망 때문에 깊은 문제에 빠지게 된다. 추정이 12라면 일정을 맞추지 못한다. 팀과 관계자들이 이 상황을 확실히 이해하도록 만들고 무슨 일이 있어도 실패 대비용 후퇴 계획을 세우도록 해야 한다. 어떤 사람도 희망을 갖게 한들면 안된다.
관리자가 당신을 불러 마감을 지키도록 노력해보라면 어떻게해야할까? 이미 가능한 선택지를 모두 고려했고 일정을 개선할 유일한 길은 범위를 줄이는 방법뿐임을 상사에게 말하라. 질주하라는 부추김에 넘어가면 안된다. 압박에 굴복해 허리띠를 졸라매고 마감일을 지키려 노력해 보겠다고 동의하는 형편없는 개발자를 두려워 하라, 개발자들은 쉬운 길로만 가려 하고 초과 근무를 하며 기적을 바라는 헛된 희마을 가지게 되는 데 이는 스스로와 팀, 이해 관계자들에게 잘못된 희망을 주기 때문에 재앙으로 가는 길이다.
모든 사람들이 문제를 대면하는 것을 피하게 만들고, 힘들지만 꼭 필요한 결정이 늦어진다. 질주하는 방법은 없다. 스스로 코딩을 더 빨리하게 만들 수 없다. 문제를 더 빨리 풀게 만들 수 없다. 노력해보려는 시도는 단지 본인뿐만 아니라 다른 사람까지 더 느리게 만드는 엉망진창인 결과를 낳는다. 따라서 상사, 팀, 관계자에게 반드시 정확하게 대답해서 희망을 갖지 못하게 해야 한다.
프로답지 못한 행동중에서 가장 최악은 아마 끝내지도 않았는데 끝냈닥 말하는 것이다. 명백한 거짓말이고 아주 나쁜 짓이다. 하지만 더 교활한 경우도 있는데 '완료'의 뜻을 새롭게 정의해 합리화 할 때다. 충분히 끝냈다고 스스로를 설득하고 다음 업무로 넘어간다. 나중에 시간이 충분할 때 남아 있는 어떤 일도 처리할 수 있다고 합리화 한다.
개중에는 '완료'의 정의를 더 확장하는 사람도 나오고, 다른 이들은 새 정의를 받아들이게 된다. 아무것도 안하고 완료를 해도 된다면 '완료'하기는 식은 죽 먹기다!
서로를 도울 준비를 하는 일은 프로그래머의 의무다. 사무실 칸막이에 틀어박히거나 다른 사람의 질문을 거부하는 일은 프로가 갖출 윤리 위반이다. 타인을 돕기 위해 약간의 시간도 마련하지 못할 만큼 중요한 업무는 없다. 사실 프로라면 명예를 걸고 어떤 때든 도움을 줘야 한다. 같은 팀 동료가 어떤 상태인지 주의를 기얼야야 한다. 누군가 곤란에 빠진 것을 봤다면 도움을 줘야 한다. 자신의 도움으로 생기는 효과가 크다는 사실에 꽤 놀랄 것이다. 자신이 다른 이보다 영리해서가 아니라 그저 신선한 관점이 이 문제를 푸는 데 커다란 기폭제가 된 것이다.
다른 이가 나를 도울 때는 감사해야 한다. 고맙게 그리고 기꺼이 도움을 받아들여라. 영역을 지키는 듯한 행동은 하지마라. 몹시 바빠 정신이 없다는 이유로 도움을 거부하지마라. 30분 정도의 시간을 들여라. 그 정도 시간이 지나서 별 도움이 안됐다면 정중히 이해를 구하고 감사의 말로 협업을 끝내라. 명예를 걸고 타인을 도와야 하듯이 명예를 걸고 도움을 받아야 함을 기억하라
도움을 부탁하는 방법을 배워라 프로의 직업 윤리에 관련된 문제다. 쉽게 도움 받을 수 있는 데도 계속 막힌 상태를 유지하는 일은 프로답지 못하다.
프로그래머는 오만하고 자신에게만 열중하는 내향적인 경향이 있다. 우리는 사람 사귀기를 좋아해서 프로그래머가 된 게 아니다. 우리가 프로그래밍에 빠진 이유는 무미 건조한 세부사항에 깊이 집중하기, 많은 개념을 한 번에 교묘히 다루기, 자기 두뇌가 지구만큼 크다는 사실을 스스로에게 증명하기를 좋아하 기 때문이다. 또한 그러는 동안 골치 아프고 복잡한 대인관계를 피할 수 있다. 물론 방금 한 말은 편견이다. 예외가 많은 성급한 일봔하다. 하지만 프로그래머는 고분고분하게 협력하지 않은 경향이 많은 게 현실이다. 그러나 효과적인 프로그래밍은 협력에 매우 중요하다. 그러므로 우리 중 많은 사람에게 협력은 본능이 아니므로 협력으로 이끄는 원칙이 필요하다.
- 실패한 단위 테스를 만들기 전에 제품 코드를 만들지 않는다.
- 컴파일이 안 되거나 실패한 단위 테스트가 있으면 더 이상 단위 테스트를 만들지 않는다.
- 실패한 단위 테스트를 통과하는 이상의 제품 코드는 만들지 않는나.
이 세 가지 법칙을 지키면서 반복 주기는 대략 30초 길이를 유지 해야한다.
왜 나쁜 코드를 봐도 고치지 않을까? 손을 대면 뭔가 망가뜨릴지도 모른다는 위험을 무릅써야 한다는 사실을 알기 때문이다. 뭔가 망가지면 자신이 감당해야 한다. 믿음직한 테스트가 있으면 변경에 대한 두려움이 모두 사라진다.
테스트 코드를 만들려면 코드의 의존관계를 고립시켜야 한다는 어려움이 있다. 테스트를 먼저 만들지 않으면 여려 함수를 테스트 불가능한 덩어리로 뭉치는 익을 막아 줄 방어막이 사라진다. 테스트를 나중에 만들면 전체 덩어리의 입력과 출력은 테스트할지 몰라도 각각의 함수를 테스트하기는 힘들것이다. 따라서 세 가지 법칙에 따라 테스트를 먼저 만드는 일은 의존성이 낮은 좋은 설계를 만드는 힘이된다.
"근데 나는 테스트를 나중에 만들 수 있어요" 라는 말은 틀렸다. 사실이 아니며 만들 수 없다. 물론 테스트 일부분은 나중에 만둘 수 있다. 심지어 주의를 기울이면 높은 커버리지를 달성하기도 한다. 하지만 일이 벌어진 후에 만드는 테스트는 수비다. 먼저 만드는 테스트는 공력이다. 사후 테스트는 이미 코드에 익숙하고 어떻게 문제를 풀었는지 잘 아는 사람이 만든다. 사후 테스트는 먼저 만든 테스트만큼 예리하지 않는다.
무술과 프로그래밍 두 거지 경우 모두 속도는 연습에 달려 있다. 또한 연습하는 방법도 비슷하다. 해법이 있는 문제를 여러 개 골라 완전히 몸으로 익힐 때까지 몇 번이고 반복한다. 음각가들은 음계, 연습곡, 반복 악절을 완전히 몸으로 익힐 때까지 몇 번이고 반복한다.
폼새는 아름답지만 무대에서 공연하기 위한 용도로 배우지 않는다. 특정 격투 상황에 반응하도록 몸과 마음을 단련하려는 의도다. 완벽한 동작을 본능적으로 만들어 필요할 때 자동으로 움직이는게 목표다.
프로그래밍에서 품새란 어떤 문제 풀이를 가상해 만든 키 눌름과 마우스 조작을 졍교하게 짜 모은 것이다. 이미 해답을 알기 때문에 엄밀히 말해 문제풀이는 아니다. 그 보다 문제 풀이에 포함된 동작과 결졍 내리기를 연습하는 것이다.
이 또한 완벽에 가까워지는 게 목표다. 셀 수 없이 연습을 반복해 두뇌와 손가락이 어떻게 움직이고 반응해야 할지 훈련한다. 연습하면 할수록 움직임과 해결 방법에 미묘한 효율과 개선을 더하게 된다.
프로 프로그래머는 개인 시간에 연습한다. 직원의 기술 연마를 돕는 일은 회사가 꼭해야만 하는 일이 아니다. 직원의 이력서를 광내는 일도 회사가 하는 일이 아니다. 환자들은 봉합 기술을 연습하라고 의사에게 돈을 내지 않는다. 연주회 참석자는 음악가가 음계 연습하는 소리를 들으려고 돈내즈 읺는다. 마찬가지로 프로그래머를 고용한 회사는 연습 시간에 급여를 지불하지 않는다.
프로 소프트웨어 개발자로써 직면하는 가장 흔한 모호함들 중 하나는 '완료'라는 모호함이다. 개발자가 어떤 업무를 완료했다고 말할 때 그, 의미는 무엇인가? 개발자가 완전한 확신을 가지고 그 기능을 배포할 준비가 됐다면 완료를 한것인가? 아니면 QA 과정을 거칠 준비가 됐다는 말인가? 또는 다 만들고 한 번 돌려보기는 했으나, 아직 테스트가 제대로 하지 않은 상태를 말할지도 모른다.
프로 개발자에게 완료에 대한 정의는 단 하나 뿐이다. 완료란 다 됐다는 뜻이다. 완료란 모든 코드를 작성했고, 모든 테스트를 통과했을을 말하는 것이고, QA 전문가와 이해당사자들이 이를 인수했다는 뜻이다. 이게 완료이다.
언제나 CI 텟트가 동작하도록 유지하는 일은 매주 중요하다. CI 테스트는 결코 실패하면 안된다. 실패하면 전체 시스템의 실행을 멈추고 오류를 바로잡아 테스트가 다시 통과하는 데 집중해야한다. CI 시스템 내의 깨어진 빌드는 비상 상황, '출시 중단' 이벤트로 간주해야한다.
전에도 말했지만 다시 한 번 강조한다. 회사에 소프트웨어를 테스트하는 QA팀이 따로 있더라도, 개발팀은 QA가 잘못된 점을 찾지 못하는 상태를 목표로 삼아야 한다.
QA가 뭔가를 반견할 때마다 개발팀은 간담이 서늘해져야 정상이다. 개발팀은 오류가 어떻게 발생했는지 자신에게 물어보고 또 발생하지 않도록 조치를 취해야 한다.
회의는 비용이 비싼 행위이다. 다음은 회의에 대한 두 가지 진실이다.
- 회의는 필요하다
- 회의는 엄청난 시간 낭비다.
프로는 회의 비용이 비싸다는 사실을 안다. 자신의 시간이 소중하다는 사실 또한 안다. 일정에 맞추려면 코딩을 해야한다. 따라서 프로는 당장의 이익이나 큰 이득이 없는 회의는 적극적으로 참석을 거부한다.
회의 참석을 요청한 사람은 참석자의 시간 관리에 책임이 없다. 자신의 시간 관리는 자신만이 할 수 있다. 따라서 회의 참석을 요청받으면, 자신의 참석이 지금 처리 중인 업무에 당장 크게 필요치 않다면 회의 참석을 거부 하라.
주어진 시간을 책임지고 잘 관리해야 한다. 쓸모 없는 회의에 발이 묶였다면, 예의 바르게 회의에서 빠져나올 방법을 찾아야 한다. 유념해야 할 중요한 점은 시간이 헛되어 버리면서 다른 이들에게 그다지 도움도 안 되는 회의에 남는 일은 프로답지 못하다는 사실이다.
비용이 비싼 회의를 감내하는 이유는 특정 목표를 달성을 서로 도우려면 정말로 참석자들이 한 방에 모여야 하기 때문이다. 참석자들의 시간을 현명하게 사용하려면 회의에는 명확한 의제가 필요하며 주제별로 시간과 목표를 명확히 정해야 한다. 회의 참석을 요청받으면, 어떤 토론을 할 생각인지. 시간은 얼마나 할당했는지, 이루고자 하는 목표가 무엇인지를 확실히 해야 한다. 이런 질문에 명확한 대답을 얻지 못한다면 정중히 참석을 거부해야 한다.
일일 회의는 애자일 개발 규범 중 하나다. 참석 자들은 자기 차례가 되면 다음 3가지 질문에 답한다.
- 어제는 뭘 했나?
- 오늘은 뭘 할 예정인가?
- 방해요소는 없었나?
이게 전부다. 각 질문에 대답 답변은 20초를 넘기지 않아야 해서 참석자에게 필요한 시간은 1분도 안된다.
한 번은 켄트 백이 심오한 말을 했다.
어떤 논쟁이든 5분 안에 해결되지 않으면 논쟁으로는 해결 할 수 없다. 논쟁이 길어지는 이유는 양쪽 모두 근거가되는 명백한 증가가 없기 때문이다. 그런 논쟁은 아마 사실에 바탕을 두지 않은 종교적 논쟁일 가능성이 높다.
데이터가 앖으면, 단시간(5분 ~ 30분 사이)에 합의를 보지 못한 논쟁은 영원히 합의를 볼 수 없다. 합의를 보려면 데이터를 가져와야 한다.
어디 잘 되나 두고 보자는 심보인 수동적 공격성을 가진 부류도 있다. 논쟁을 끝내기 위해 동의를 하긴 하지만 해결방안에 참여하기를 거부하는 식으로 결과에 찬물을 끼얹는다. 이런 행동은 프로답지 못한 행동 중에서도 가장 프로담지 못한 행동이다. 절대로 이런 짓을 해선 안된다. 일단 동의를 했다면, 반드시 참여해야 한다.(동의한 주제에 능동적으로 행동 해야한다)
프로그래밍은 지적인 행위로 긴 시간 정신을 모아 집중해야 한다. 집중력은 소중한 자원으로 마나와 비슷하다. 집중력 마나를 다 쓰고 나면, 몇 시간 정도 집중이 필요 없는 행동으로 마나를 충전해야 한다.
프로 개발자는 집중력 마나를 잘 활용하기 위해 시간을 관리하는 법을 익혀야 한다. 집중력 마나가 많으면 코딩을 하고 많지 않으면 덜 생각적인 다른 일을 한다.
또한 집중력 마나는 차츰 사라지는 자원이다. 있을 때 사용하지 않으면 사라진다. 이게 바로 회의가 사람을 황폐하게 만드는 이유다. 회의에서 집중력 마나를 더 써 버리면 코딩에 쓸 마나가 남아나지 않는다.
시간관리와 집중을 관리하기 위해 토마토라고 알려진 포도로모라는 매우 효율적이며 유명한 기법을 사용한다.
타이머를 25분에 맞춘다. 타이머가 돌아가는 동안 다른 모든 일을 무시하고 정해진 일만 한다. 전화가 오면 25분 후에 통화해도 되는지 정중히 물어본다. 누군가 다가와 뭔가를 물어보면 25분 후에 다시 찾아올 수 있는지 정중히 물어본다. 어떤 방해든 그냥 타이머가 끝날 때까지 미룬다.
토마토 모양 타이머가 울리면 하던 일을 즉시 중단 한다. 토마토 시간 동안 일어났던 방해들을 처리한다. 그후 5분 정도 쉰다. 다시 25분 타이머를 참추고 다음 토마토를 시작한다. 토마토를 한 번 끝낼 때마다 30분 정도 길게 쉰다.
하루에 몇 번의 토마토를 할 수 있을까? 상태가 좋으면 12번, 심지어 15번까지도 가능하다. 안 좋은 날은 1번에서 3번밖에 못한다. 횟수를 세고 도표를 그려보면, 하루가 얼마나 생산적이 었는지 이것저것 처리하느라 얼마나 시간을 썻는지 한눈에 보인다. 생상적인 25분의 시간을 확보하고 모든 방해를 적극적으로 방어하는 일이 포모도로 기법의 진정한 혜택이다.
어떤 때는 그저 일이 손에 잡히지 않기도 한다. 해야 할 이링 무섭거나 불편하거나 지루해서 그럴지도 모른다. 아니면 단순히 하기 싫어서 그럴지도 모른다.
이유가 뭐든 간에 눈 앞의 업무를 피하는 길을 찾아볼 때가 있다.
지금 해야 일보다 다른 일이 더 급하다고 스스로를 설득하기도 한다. 이런 일을 우선 순위 뒤집기라 부른다. 다른 업무의 우선순위를 높여 정말 중요한 일을 뒤로 미룬다. 우선 순위 뒤집기는 스스로에게 하는 거짓말이다. 정말 끝나야 하는 업무를 마주할 수 없어서, 다른 업무가 더 중요하다고 자신을 설득한다. 아니라는 사실을 알면서 스스로에게 거짓말을 한다.
정확히 말하자면 거짓말이 아니다. 실은 다른 사람이 뭘 하는지 왜 그 일을 하는지 물을 때 대비해 거짓말을 준비하는 것이다. 다른 이들의 평가로부터 자신을 보호할 방어막을 쌓는 것이다.
당연히 프로답지 못한 행동이다. 프로는 개인적 두려움과 바람은 제쳐두고 각업무의 우선순위를 검토하고 우선순위에 따라 순서대로 업무를 진행한다.
막다른 길은 모든 소프트웨어 장인들이 피할 수 없는 삶의 현실이다. 결정이 확고할수록 황무지에서 헤매는 시간이 길어진다. 프로로서의 명성이 걸린 일이라면 영원히 헤메게 된다.
신중함과 경험으로 특정 막다른 길을 피할 수 있지만, 전부 피할 순 없다. 따라서 정말 필요한 기술은 막다른 길에 도달했을 때 재빨리 알아 채고 뒤로 물러날 용기를 가지는 일이다.
약속은 꼭 지켜야 한다. 특정 날짜까지 끝내겠다고 약속했으면 그냥 그날까지 끝내야 한다. 설사 하루에 12시간 일하고 주말 근무에 가족 휴가를 넘기는 한이 있어도 반드시 해야한다. 약속을 했으면 그 약속을 존중해야 한다.
프로는 달성할 수 있다는 사실을 알지 못하면 약속하지 않는다. 아주 단순하다 가능한지 확신이 없는데 약속해 달라고 부탁을 받으면 명예를 걸고 거절해야한다. 약속해 달라는 부탁을 받았는데 달성 가능하다는 사실을 알지만 그러려면 야근과 주말 근무까지 포기해야 한다면 그때는 자신이 선택해야 한다. 약속 했으면 그 대가를 감당해야 한다.
약속은 확실함에 관한 문제다. 다른 사람들은 당신의 약속을 받아들이고 거기에 기반해 계획을 짠다. 약속을 지키지 못할 때 그들에게 그리고 스스로의 명성에 손해가 되는 비용은 어마어마하다. 약속을 못 지키는 행위는 부정직한 일이며 대놓고 하는 거짓말과 큰 차이가 없다.
추정은 어림짐작이다. 약속은 포함되지 않는다. 아무런 약속도 하지 않는다. 추정이 빗나가는 일은 전혀 불명예가 아니다. 추정을 하는 이유는 얼마나 걸릴지 모르기 때문이다.
불행히도 개발자들은 대부분 추정 실력이 형편없다. 이는 추정에 개발자들이 모르는 특별한 기술이 있기 때문이 아니라 오히려 추정에는 특별한 기술이 없기 때문이다. 추정은 숫자가 아니다. 추정은 분포다.
프로는 추정과 약속 사이에 명확한 선을 그어 구분짓는다. 프로는 확실히 성공한다는 사살을 알기 전에 얏속하지 않는다. 프로는 넌지시 암시된 약속도 하지 않도록 주의를 기울인다. 의사소통할 때는 추정의 확률 분포에 대해 가능한 선명히 밝혀 관리자가 적잘한 계획을 세울 수 있도록 한다.
프로 개발자는 압박감을 느껴도 침착하고 결단력 있게 행동한다. 압박감이 커질수록 훈련과 규율을 따르는데, 이 방식이 압박의 주체인 마감일과 약속을 지키는 최선의 방법임을 알기 때문이다.
압박을 받을 때 침착을 유지할 수 있는 가장 좋은 방법은 압박감을 일으키는 상황을 피하는 것이다. 상황 회피는 압박을 완전히 사라지게 하지는 않지만 높은 압박을 받는 시간을 상당히 줄이고 최소화한다. 우리가 해야할 일은 위험의 크기를 확실하게 측정하고 적절하기 관리할 수 있음을 사업부에게 알리는 것이다.
10장에서 봤듯이 달성할 확신이 없는 마감일 약속을 피하는 것이 중요하다. 사업부는 위험을 없애려고 항상 약속을 원한다. 우리가 해야할 일은 위험이 크기를 확실히 측정하고 적절하히 관리할 수 있음을 사업부에게 알리는 것이다.
가끔은 이미 약속이 정해진 때도 있다. 사업부에서 우리와 상의 없이 고갹에 약속을 해버린 경우다. 이런 일이 생기면 명예를 걸고 사업부를 걸고 도와 약속을 지킬 방도를 찾아야 한다. 하지만 이 약속을 받아들여 얽매일 필요는 없다
이 차이가 중요하다. 프로라면 언제나 사업부를 도와 목표를 달성하는 법을 찾아 내야한다. 하지만 프로는 사업부에서 멋대로 한 약속을 받아들이지 않아도된다. 끝내 사업부에서 한 약속을 지킬 방법이 없다는 사실을 알게 되면 약속을 한 사람이 책임을 져야 한다.
이는 말로 하기는 쉽다. 하지만 약속을 못 지키는 바람에 사업이 실패하고 월급을 못 받게 된다는 압박감을 떨치기 힘들다. 하지만 프로답게 처신한다면 적어도 당당히 머리를 들고 새로운 일터를 구하면 된다.
마감일을 지키면서 빠르게 움직이는 방법은 언제나 깔끔한 상태를 유지하는 것이다, 프로는 빨리 움직이려고 마구잡이로 어지르고 싶은 유혹에 굴하지 않는다. 프로라면 '빠르고 지저분하게'라는 모순이란 사실을 깨닫는다 어떤 때라도 지저분함은 느리다는 의미다.
시스템, 코드, 설계를 가능한 깔끔하게 유지함으로써 압박을 피할 수 있다. 이는 코드를 정리하는라 끝없이 시간을 소모한다는 뜻이 아니다. 그저 엉망으로 어질러진 모습을 견디지 못한다는 뜻이다. 난장판은 우리를 느리게 만들고 날짜를 놓치고 약속을 지키지 못하게 한다. 따라서 최선을 다 해 일하고 만든 것을 가능한 깔끔히 유지해야 한다.
위기에 처했을 때 모습을 관찰하면 어떤 믿음을 가지고 있는지 알게 된다. 위기가 처했을 때 훈련과 규율을 따른다면 진정으로 그 규율을 믿는다는 뜻이다. 반대로 위기 때 행동이 바뀐다면 평소 행동을 진심으로 믿지 않는다는 뜻이다.
보통 TDD 규을을 따르지만 위기가 닥쳤을 때 포기한다면, 마음 속 싶은 곳에서 TDD가 도움이 된다는 사실을 믿지 않는다는 뜻이다. 평소에는 코드를 깔끔히 관리하다가도 위가가 닥쳤을 때 코드가 엉망이 된다는된다면, 마음 속 싶은 곳에서는 엉망진창 코드가 발목을 잡아 더 느리게 만든다는 사실을 믿지 않는다는 뜻이다.
위기상황에서도 편하게 느껴지는 규율을 골라라. 그리고 나서 그 규율을 항상 따라라. 이 규을을 따르는 일이야말로 위기상황을 피하는 최선의 방법이다. 마감 전 압박질주 할 때가 와도 태도를 바꾸지 마라. 규율을 따르는 것이 일을 잘 풀어나가는 최선의 방법이라면, 심각한 위기상황에서도 규율을 따라야 한다.
압박을 사전방지, 완화, 제거하는 행동들도 모두 좋지만, 아무리 주의를 기울이고 조심해도 압박은 찾아 온다. 어떤 때는 지키지도 못할 약속을 한다. 그럴 떈 어떻게 헤야할까?
스트레스를 관리하자. 잠 못드는 밤은 빠른 일 처리에 도움이 되지 않는다. 눌러앉아 불안해 하는 것도 마찬가지다. 최악의 행동은 급히 서루드는 것이다! 어떤 값을 치르더라도 이 유혹에 저항하라. 서두르면 빠진 구멍이 더 깊어질 뿐이다. 서두르지말고 속도를 늦춰라. 문제를 곰곰이 고민하자. 가능한 최선의 결과로 가는 길을 짜고 이성적으로 꾸준한 속도로 진행하자.
어려움에 빠진 사실을 팀 동료와 상사에게 알려야 한다. 어려움에서 벗어나는 최선의 계획을 짜서 다른 이들에게 알려라. 도움과 가르침을 부탁하라. 깜짝 사고는 피해야한다. 깜짝 사고야말로 사람들을 가장 화나고 비논리적으로 만든다. 감짝 사고는 압박을 열 배로 늘린다.
상황이 힘들어 지면 규율을 믿어라. 애초에 규율을 세운 이유는 압박이 심해질 때 길잡이로 삼기 위해서다. 이런 때야말로 자신이 가진 모든 규율에 특별히 주의를 기울여야 한다. 규율을 의심하거나 포기해야할 때란 없다.
어떤 일이 닥쳐도 두려움 땨문에 당황해 여기저기 두리번거리지 말고 자신이 고른 규율을 따른다면, 일을 빨리 끝내는 데 도움이 되고 부지런하고 열심히 일하게 된다. TDD 규율을 따른다면 평소보다 더 많은 테스트를 만들자. 함수를 작게 유지했다면, 더작게 만들어보자
우리는 사람들과 같이 일하는 게 좋아서 프로그래머가 된게 아니다. 일반적으로 사람들 사이의 관계는 뒤죽박죽이고 예측하기 힘들다. 우리는 프로그래밍한 기계가 깔끔하고 예측 가능하도록 움직일 때가 즐겁다. 제일 행복한 때는 홀로 방 안에서 아주 흥미로운 문제에 몇 시간이고 완전하게 집중할 때다. 물론 이는 과도한 일반화이며 예외도 많다. 하지만 평균적으로 보면 홀로 집중하기를 좋아하는 경향이 있다.
프로그래머의 첫번째 책임은 회사가 필요로 하는 일을 처리하는 것이다. 이는 관리자, 사업 분석가, 테스터, 팀 동료와 힘을 합쳐서 사업 목ㅍ표를 속속들이 이해해야 한다는 뜻이다. 사업 공부에 온 몸을 던지라는 소리는 아니다. 다만 왜 이런 코딩을 해야 하고 그 코드로부터 회사가 어떤 이득을 얻을지 알아야 한다는 뜻이다. 우리는 업무는 사업이 순조롭게 나아가도록 만드는 일이다. 따라서 프로 프로그래머는 사업을 이해 하는데 시간을 투자한다. 한 마디로 프로는 탑승한 배가 어떻게 항해하는지 관심을 기울인다.
삐걱대는 팀의 모습 중 가장 나쁜 모습은 각 프로그래머가 자신의 코드에 벽을 두르고 다른 프로그래머들이 건드리지 못하게 하는 행동이다. 이는 재앙으로 가는 지름길이다.
코드의 소유권의 벽을 무너뜨리고 팀 전체가 모든 코드의 소유권을 가지는 편이 낫다. 모든 팀원들은 어떤 모듈이라도 체크아웃할 수 있으며 적절하다고 생각하는 대로 수정도 할 수 있는 편이 좋다. 나는 개인이 아니라 팀이 코드를 소유하 길 바란다.
프로 개발자는 다른 사람의 코드 작업을 막지 않는다. 코드에 장벽 따윈 세우지 않는다. 오히려 함께 일하며 시스템의 최대한 많은 부분을 알아간다. 시스템의 여러 다른 부분을 서로 배우고 가르친다.
프로 개발자가 짝 프로그래밍을 하는 또 다른 이유는 짝 프로그래밍이 서로 아는 것을 주고 받는 최고의 방법이기 때문이다. 프로 개발자는 지식을 창고에 처박아 두지 않는다. 오히려 서로 짝을 이뤄 주고받으며 시스템의 다른 부분을 배워 나간다. 프로개발자가 짝 프로그래밍을 하는 이유를 한 가지 더 들자면 짝 프로그래밍은 코드를 검토하는 최고의 방법이기 때문이다.
팀이 만들어진 데는 시간이 걸린다. 팀 구성원들은 관계를 만들기 시작한다. 서로 어떻게 협력하는지를 배운다. 서로의 버릇, 장점, 약점을 배운다, 마침내 팀은 한덩어리가 되기 시작한다.
한 덩어리가 된 팀에는 정말 마법같은 무엇이 있다. 일하며 기적을 만든다. 서로의 요구를 미리 알아내 처리하고 서로 보호하며 서로 돕고 서로의 최선을 요구한다. 뭔가를 이뤄낸다.
팀원들이 각자의 차이점을 극복하고 서로를 받아들이고 진정한 한 덩어리가 되기에는 시간이 걸린다. 하지만 일단 한 덩어리가 되면 그것은 마법이다. 한 덩어리가 된 팀은 같이 계획을 세우고 같이 문제를 풀고 같이 문제에 맞서고 일을 완수한다. 일단 한 덩어리가 되고 나면 프로젝트가 끝났다고 팀이 해체하는 일은 우스운 짓이다. 팀원을 한 데 모아 프로젝트를 던져 주는 것이 최선이다.