클린코더

프로의 마음가짐

함부로 바라지 마라

함부로 손쉽게 명예를 얻기를 바라지 마라!

프로페셔널리즘이란 당연히 명예와 긍지의 상징이기도 하지만, 동시에 책임과 의무를 나타내기도 한다. 책임지지도 못할 일에서 명예와 긍지를 얻을 수는 없다.

책임감을 가져라

프로가 실수하면, 스스로 뒷감당을 해야한다. 프로페셔널리즘은 책임이 전부라 해도 과언이 아니다.

테스트하지 않고 배포하는 일은 무책임한 짓이다.

기능에 해를 끼치지 마라

프로가 되려면 소프트웨어에 오류를 만들면 안된다.

“소프트웨어는 너무 복잡해서 오류가 생길 수밖에 없어요” 라고 항변하고 싶을지도 모른다. 안타깝지만 너무 복잡하다는 이유로 책임이 사라지진 않는다.

의사들은 신이 아니기 때문에 인체에 대해 전부 이해하지 못하지만, 여전히 환자에게 해를 끼치지 않는다는 히포크라테스 선서를 지키듯이 우리들도 의사들처럼 책임을 회피해서는 안된다.

완벽할순 없겠지만 오류를 만드는 비율을 한없이 0에 가깝게 만드는게 프로 코더의 책임이다.

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

소프트웨어를 출시할 때는 QA가 문제를 찾지 못할 것이라고 어느 정도 자신할 수 있어야 한다. 코드에 결함이 있는걸 알면서도 QA에게 코드를 보내는 일은 프로답지 못한 행동이다.

프로코더는 QA를 오류를 찾는 용도로 사용하면 안된다. QA가 문제를 찾을때마다 개발자는 놀라움과 분함을 느껴야 마땅하며, 다시는 그런일이 생기지 않도록 마음을 다져야 한다.

제대로 작동하는지 아닌지 알아야 한다.

그렇게 하려면 항상 테스트를 열심히 해야한다. 하지만 테스트는 시간이 너무 오래 걸리기 때문에 테스트를 자동화해야한다

테스트의 커버리지는 100%에 가까워야한다. 테스트코드도 완성된 코드의 일부이며. 테스트 하기 쉽게 코드를 짜는것도 실력이다.

구조에 해를 끼치지 마라

전체 구조를 희생하면서까지 기능을 추가하는 일이 헛수고라는 사실은 프로라면 당연히 알고 있어야 한다.

구조가 좋아야 코드가 유연해진다. 변경요청을 받았을때 터무니 없는 비용을 치르지 않고 변경하려면 항상 유연한 구조로 코드를 유지해야 한다.

보통 코더들은 동작중인 소프트웨어를 계속 바꾸는 일이 위험하도고 생각한다. 하지만 정말 위험한 일은 스프트웨어를 고정된 상태로 두는 일이다. 소프트웨어를 끊임없이 리팩토링 하는 시도를 하지 않는다면 정말 변화가 필요할때, 소프트웨어가 단단히 둑어 있을 것이다.

왜 프로가 아닌 개발자들은 코드 바꾸기를 무서워할까? 코드를 망가트릴까봐 겁이 나서다… 왜 코드를 망칠까 봐 겁이 날까? 테스트가 없기 때문이다. 프로 개발자는 코드외 테스트에 확신이 넘치기 때문에, 시도 때도 없이 코드를 이리 저리 바꿔도 마음이 평안하다.

직업윤리

프로라면 능력에 자신이 있어야하며, 능력을 갖추는 일은 회사 책임이 아니다. 자신이 책임져야 한다.

전산 분야 지식을 익혀라

지난 50년 동안 전산 분야에서 축적된 전문 지식을 익혀야 한다.

“우리 분야는 너무 급격히 발전해서, 오래된 아이디어들은 모두 쓸머없어지지 않을까?” 라고 생각할수 있다. 하지만 지난 50년 동안 쓸모없게 된 아이디어는 거의 없다. 몇몇 아이디어가 비주류로 물러나긴 했지만… (폭포수 개념에 대해 사람들의 관심이 줄어들긴 했지만, 폭포수 개발의 의미와 장단점을 몰라도 된다는 말은 아니다)

디자인 패턴: 24가지 GOF패턴을 설명할수 있어야 한다.
설계원칙 : SOLID 객체지향 원칙을 알아야 한다.
방법론 : XP, 스크럼, 린, 칸반, 폭포수, 구조적분석, 구조적 설계 개념을 충분히 이해해야 한다.
원칙: 테스트 주도 개발, 객체지향 설계, 구조적 프로그래밍, 지속적 통합, 짝 프로그래밍을 실천해야 한다.
도구 : UML, 데이터 흐름도, 구조차트 , 페트리 넷, 상태 전이 다이어그램, 호름도, 결정 테이블을 어떻게 쓰는지 알아야 한다.

끊임없이 배우기

새 언어를 배우지 않는 프로그래머에게는 재난이 있을것이다.

자바 개발자라면 루비를 배워야하며, C프로그래머라면 리스프를 배워라

최신 의학 논문을 보지 않는 의사를 찾아가고 싶은 마음이 드는가? 마찬가지로 최신 기술을 익히려 하지 않는 개발자를 과연 누가 고용할까?

연습

진정한 프로는 기술을 날카롭게 갈고 닦아 항상 준비된 상태로 만드려고 애써야 한다.

함께 일하기

배움에 도움이 되는 방법 중 하나는 다른사람들과 함께 일하는 것이다 (일도 빨리 끝나고 오류도 적다)

혼자만의 시간도 매우 중요하다. 프로그래머가 혼자만의 시간을 가질 수 없다면 정신이 나갈지도 모른다.

멘토링

배우기에 가장 좋은 방법은 가르치는 것이다. 가르치고 배울 때 더 큰 이익을 보는 쪽은 선생님이다.

프로라면 후배들을 멘토링하는 책임을 져야한다. 후배들이 방치된 채 이리저리 떠돌게 둬선 안 된다.

업무 지식을 익혀라

프로답지 못한 행동 중에서도 최악은 제품 사양이 사업 진행에 이치가 맞는지 따져보지도 않고 그저 사양에 따라 코딩하는 일이다. 사양에 오류가 있는지 알아보고 이의를 제기할 수 있을 만큼 업무를 알아야 한다.

겸손

프로는 자기 능력을 확신하고, 그 확신을 바탕으로 계산한 위험을 과감히 짊어진다. 프로는 쪽지 않는다. 하지만 항상 자신이 실패할 수도 있음을 알고 겸손해야 한다.

아니라고 말하기

프로라면 권위에 맞서 진실을 말할 수 있는 용기를 가져야 한다.

반대하는 역할

관리자는 관리자대로의 역할이 있고 프로그래머는 자신만의 역할이 있다.

관리자가 하라는대로 무조건 수긍해서는 안된다. 관리자가 요구하는 일이 불가능하다고 생각되면 일이 정상적으로 돌아가도록 적극적으로 방어하고 추진해야 한다. 관리자들도 프로그래머가 당연히 그러기를 바란다.

왜 그런지가 중요한가?

관리자에게 세부사항을 과하게 알려주는 일은 밀착 관리를 초래하게 되므로 조심해야 한다. 중요한 사실은 정확한 일정을 관리자에게 말해주는 것이지 리뷰나 어떤 12단계에 테스트에 대해서는 곧이곧대로 전부 설명할 필요는 없다.

이익과 손해관계가 높을때

어떤일의 일정에 의한 이익과 손해가 클때야 말로 정확하게 아닐땐 아니라고 말해야 한다. 압박감에 관리자에게 “예” 라고 잘못된 정보를 주는 순간, 더 큰 손해를 감수해야 할 확률이 높다.

팀플레이어

팀 플레이어라는 말은 맡은 위치에서 최선을 다해 책임을 완수하고, 동료의 일이 잘 안 풀릴 때 도와준다는 뜻이다.

협업 관계에서, 동료의 눈치를 살핀다고 ***“예”***를 말하는건 동료를 망하게 하겠다는 것과 같다.

또한 협업 관계에서, “노력해 보겠다.” 라고 말하는건 실패했을때 책임을 회피하겠다는 말과 같다. 진정 동료를 돕고 싶다면 예와 아니오 둘중에 정확히 하나를 말해주는게 좋다.

예라고 말하는 비용

프로답지 못한 행동은, 원칙을 무시하면서(테스트 코드나 높은 품질의 코드)를 포기하면서 일정에 대해 ***“예”***라고 말하는 것이다.

말도 안되는 일정에 대해 원칙을 무시하면서 ***“예”***라고 말한다고 영웅이 되지 못한다… 호구가 될 뿐이다.

진정한 영웅은 업무를 충실히 원칙에 맞게 제시간에 예산 안에서 완수했을 때다.

예라고 말하기

약속의 뜻을 담은 말을 사용하는 일은 얼필 두려워 보이지만. 내뱉은 말을 지키는 개발자로 인정받게되고, 이는 이 업계에서 개발자들이 바라는 최고의 일이다.

프로는 모든 업무 요청에 예라고 대답할 필요가 없다. 하지만 ***“예”***라고 대답할 수 있는 창의적인 방법을 찾는데 고심히야 한다. 프로가 예라고 대답할 때는 약속을 뜻하는 언어를 사용해서 내뱉은 말에 모호한 부분이 없도록 해야한다.

약속을 뜻하는 말

예라고 말하겠다고 결심했다면 아래 3단계를 반드시 거쳐야 한다.

하겠다고 말한다.
진심을 담는다.
실제로 실행한다.

약속의 부족함을 알아차리기

아래에 나열된 말들은 약속을 의미하지 않는다.

“이걸 끝내야해”
“살 좀 빼야 할 필요가 있어”
“내일까지 끝나면 좋겠는데”
“시간이 좀 더 있었으면 좋겠어”

이 일을 끝내려면 어떤 사람 x가 꼭 필요하기 때문에 안될꺼야

프로라면 아래처럼 한다고 한다고 구체적으로 약속할 수 있다.

의존 도움이 필요한 팀원과 한시간 정도 대화를 나눈다.
인터페이스를 만들어 다른 팀의 인프라스트럭처에 대한 의존성을 추상화 한다.
이번 주 빌드 담당자를 최소 세번 이상만나, 변경사항이나 빌드시스템에서 잘 동작하는지 확인한다.
개인 빌드를 만들어 모듈 통합테스트를 실행한다.

어떻게 해야할지 방법을 모르기 때문에 안될꺼야

어떻게 할지 몰라도 목표 달성을 위해 어떤 핻옹을 하겠다는 약속은 할 수 있다.

25개 오류를 모두 조사하고 재현해본다.
이번조는 어류 수정에만 전념한다.

가끔은 어쩔 도리가 없을때도 있어서 안될꺼야

해결할만해 보였던 오류가 생각보다 심하다는 사실을 알게됬다면, 관계자에게 즉시 알려야 한다. 그렇지 않으면 약속을 완수하는데 필요한 도움을 얻을 기회를 뺏기게 되는 것이다.

코딩

준비된 자세

코딩은 아래 사항들을 전부 만족시켜야 하는 농축된 집중력이 필요한 활동이다.

코드는 반드시 동작해야 한다.
코드는 고객이 제시한 문제를 반드시 풀어야 한다.
코드는 기존 시스템에 잘 녹아들어야 한다.
코드는 다른 프로그래머가 읽기 쉬어야 한다.

따라서 충분히 집중할 수 있는 상태일때 코딩해야 하며 좋은 컨디션을 항상 유지하려고 노력해야 한다.

새벽 3시에 짠 코드는 엉망일 확률이 높다

지쳤을 때는 코드를 만들지 마라. 프로다운 모습은 무턱대로 많이 일하는게 아니다. 충분히 자고 건강을 챙기고 건전한 생활습관으로 하루에 8시간씩 충실히 일하자.

근심이 있을때 짠 코드도 엉망일 확률이 높다

필요하다면 중요한 코드는 근심거리가 없을때까지 우선순위를 낮추어서 짜는게 좋다. 근심고민을 잠시 잊고 코딩하는 마인드 컨트롤을 익히는 것도 좋다.

몰입역역

코딩에 너무 몰입할때는 주의해야한다. 코딩 시야가 좁아지고, 너무 생상성에만 집중한 나머지 잘못된 코딩을 할 수도 있다.

외부방해

사무실에서 코딩중에 다른사람이 도움을 요청하면 집중이 깨지고 짜증이 날것이다.

외부 방해는 어떻게든 찾아와서 우리를 괴롭힌다. 하지만 다음 번에는 자신이 남을 방해할 필요가 있을지도 모른다는 사실을 기억하라. 그래서 프로다운 태도로 예의 바르게 기꺼이 도와야 한다.

짝 프로그래밍이나 TDD는 외부방해 상태에 대한 스트레스를 어느정도 방지할 수 있다.

창의적인 입력

창의적인 출력은 창의적인 입력에 의존한다.

많은 독서량은 코딩을 잘 하는데도 도움이 된다. 코딩이 막힐때는 영화나 소설을 보는것도 도움이 된다.

디버깅

디버깅에는 은근히 시간이 많이든다. 디버깅시간을 가능한 0에 가깝게 줄이느 일은 프로가 짊어진 의무다.

의사는 저지른 잘못을 고치려고 환자를 다시 수술하는 것을 좋아하지 않는다. 이런일을 너무 자주 하는 의사는 프로로 취급받지 못한다. 프로그래머도 마찬가지다.

속도 조절

소프트웨어 개발은 마라톤이지 단거리 질주가 아니다. 속도를 조절해야 이긴다. 프로그래머는 기력을 보존하고 창의성도 챙길줄 알아야 한다.

언제 걸어 나갈지 알기

풀고 있는 문제를 다 풀기 전에는 집에 못 간다고? 아니다. 잘 안풀릴때는 꼭 집에 가야된다.

피곤하면 창의성과 총명함이 사라지고 코드에도 영향을 미친다.

집까지 운전한다거나 샤워할때 안풀리던 문제의 해결책을 발견할 때가 많다. 창의적이고 영리하게 일하는 형태를 알고 활용하는 것이 프로 개발자다.

일정을 못 지키다

최고 실력자에게도 일정을 못 지키는 날이 온다. 일정 지연을 관리하는 요령은 이른 감지와 투명성이다.

정기적으로 목표대비 진척을 측정하고 사실을 바탕으로 완료일자, 최선의 일자, 최악의 일자의 추정치를 마련하라. 추정치에 희망을 섞지 마라! 그리고 세 숫자를 관계자들에게 알려라. 추정치는 매일 갱신하라

희망

목표일정이 추정치보다 빠를경우 희망을 갖지 말고 관계자들에게 확실하게 이해시키고 후퇴계획을 세우도록 해야한다. 어떤 사람도 희망을 갖게해서는 안된다.

질주

관리자가 무리한 목표일을 지키도록 노력해보라고 하면 어떨까? 질주하라는 부추김에 넘어가서는 안된다.

부추김에 넘어가는 순간 확실하지도 못한 약속을 하는 형편없는 개발자가 되는 것이다 (나 뿐만 아니라 모든 이해관계자들을 재앙으로 몰고간다).

질주하는 방법은 없다. 코딩을 더 빨리할수는 없고 오히려 엉망진창이 된다.

초과근무

물론 초과근무가 효과적일때도 있다. 하지만 20%더 일한다고 20% 더 빨리 작업이 완료되는건 아니다.

특히 초과 근무는 2~3주 이상 지나면 확실히 실패한다. 따라서 아래의 상황중 하나에 해당한다면 초과근무에 찬성하면 안된다.

개인적으로 감당 못할 초과근무일때
2주 이하인 단기간이 아닐때
초과 근무 노력이 실패할 때를 대비한 후퇴 계획을 상사가 갖고 있지 않을때

가짜 출시

가장 프로답지 못한 행동은 끝내지도 않았는데 끝냈다고 말하는 것이다.

완료 정의

독자적인 '완료’의 정의를 만들어서 가짜 출시 문제를 피해야 한다. 가장 좋은 방법은 자동화된 인수 테스트를 만들어서 완료됬다고 말하기 전에 테스트를 통과시키는 것이다.

테스트는 비 개발자들도 이해할수 있어야 하고, 자주 돌려볼 수 있어야 한다.

도움

프로그래밍은 어려워서 한 사람의 능력으로는 잘 해내기 어렵다. 다른 사람의 도움이 필요하다.

다른 사람 돕기

서러를 도울 준비를 하는 일은 프로그래머의 의무다. 프로라면 명예를 걸고 어떤 때는 동료에게 도움을 줘야 한다.

도움을 주는 자신이나 동료가 영리해서가 아니라 그저 신선한 관점이 문제를 푸는데 기폭제가 된다.

도움 받기

명예를 걸고 도움을 주듯, 명예를 걸고 도움을 받아야 하며, 고맙게 기꺼이 도움을 받아들여라.

도움을 부탁하는 방법을 배워라. 막혔거나 혼란스럽거나 마음대로 안될때 다른 이에게 수단과 방법을 가리지 말고 도움을 요청하라.

이것은 프로의 직업윤리에 대한 문제다. 쉽게 도움을 받아 해결할 문제를 계속 막힌 상태로 유지하는 일은 프로답지 않다.

프로그래머는 오만하고 자신에게만 열중하는 내향적인 경향이 있다. 하지만 효고적인 프로그래밍에는 협력이 매우 중요하다는걸 인정해야 한다.

멘토링

경험이 적은 프로그래머를 훈련시키는 일은 시니어 개발자의 의무다. 그 어떤 교육과정이나 책도 멘토링을 대체할 수 는 없다.

멘토링은 프로의 의무이다. 마찬가지로 멘토링을 구하는 일도 프로로서의 의무다.

테스트 주도 개발

자연스럽게 테스트로 아웃풋을 확인하면서 코딩하게 된다. 테스트 주도 개발을 하면 테스트 주기를 빠르게 생산적인 코딩을 할수 있다.
테스트 주도 개발을 하면 테스트가 용이한 좋은 구조로 코드가 자연스레 설계되는 장점이 있다.
- 코드가 이미 나온 후 테스트를 짜려고 하면 테스트 코드를 짜기가 쉽지 않고 테스트를 못하는 코드가 생길 수 있다.
- 도중에 테스트를 위해 코드를 고치는 작업이 더 고통스러울 수 있다.
코드에 대한 확신히 생기며 리팩토링의 공포로 부터 해방될 수 있다
테스트 코드 자체가 코드 사용자에겐 최고의 문서가 될 수 있다.
거의 모든 경우 TDD는 장점이 많지만, 그렇지 않은 경우도 있으며 그런 경우에는 규칙을 따라서는 안된다.

연습

모든 프로는 자신의 기술은 연습한다.

변해버린 시대

요즘은 컴퓨터의 속도가 빨라지면서 코딩도 빠르게 작성해보고 테스트 해보는 것이 가능하므로, 빠르게 코딩하면 생산성을 높일 수 있다. 코드 테스트 주기를 빠르게 돌려야 생산성이 높아질때도 있다. 빠르게 처리하려면 연습이 필요하다.

경험의 폭 넓히기

회사에 다니다 보면 회사 업무에 필요한 단 하나의 언어만 사용해야 하는 경우가 많다. 하지만 그렇게 하다보면 경력과 사고방식이 좁아질 수 있다. 주기적으로 산업기반이 바뀌는 개발자의 경우 다른 언어나 플랫폼을 항상 연습해야 한다.

인수 테스트

프로그래머는 팀 동료나 사업부와의 의사소통이 정확하도록 신경써야 하는 의무가 있다.

시기상조의 정밀도

사업부는 프로젝트를 승인하기 전에 일이 어떻게 진행될지 정확히 알고싶어 한다. 개발자들은 프로젝트를 추정하기 전에 어떤 제품을 만들어야 하는지 정확히 알고싶어 한다. 결국 프로젝트 초반의 일정을 정밀하게 추정하는건 불가능하다.
요구사항은 항상 변하므로, 초반에 정밀한 추정은 말도 안되고 필요하지도 않다. 프로 개발자는 이런 사실을 잘 알고 있다.
- 프로 개발자는 이런 오차 범위를 알고 관계자들을 잘 이해해게 만들어야한다.

완료에 대한 정의

완료란 테스트코드를 포함한 모든 코드를 작성했고, 모든 테스트를 통과했음을 의미하며 QA전문가와 이해당사자들이 이를 인수했다는 뜻이다.

인수테스트를 작성하면 사업부와 개발자가 생각하는 요구사항을 정확히 정의 하여 일정을 추정하는데 도움이 될 수 있다.

인수테스트란 요구사항이 언제 완료되는지를 정의하기 위해 이해당사자들과 프로그래머가 힘을 모아 작성하는 테스트를 말한다.

요구사항을 전달하는 과정에서 개발자와 함께 QA전문가도 항상 함께 하여 테스트 케이스가 만들어져야 한다.

테스트 자동화

요구사항을 정의할때 QA전문가와 함께 요구사항의 정의를 정확하게 명시하고, 자동화된 인수 테스트를 만들어야 한다. 모든걸 수작업으로 테스트 하는건 비용이 너무 많이 들고. 매번 테스트하는데 많은 시간이 걸리게 된다.

테스트 자동화는 잘못된 시스템구현을 막고 어플리케이션 구현의 완료 시점을 명확하게 해준다.

테스트 작성자

테스트 작성자는 기능 개발자와 분리되어야 한다. 기능 개발자가 인수 테스트를 작성한다면 "행복한 경로"의 버전만 작성할 가능성이 높기 때문이다. QA 기간의 중반에는 인수테스트가 완성되어야 하며, 시기를 노친다면 그 팀에 더 많은 QA 인력이 추가되어야 한다.

단위테스트와 인수테스트

단위테스트와 인수테스트는 분리되어야 하며 서로 다른 역할을 갖는다.

GUI테스트의 문제점

GUI는 항상 변화하기때문에 테스트가 어렵다. 그러므로 단일책임의 원칙에 따라 GUI도 기능 단위로 추상화 하여 API처럼 사용되도록 하는것이 좋다(GUI변동에 최대한 영향을 덜 받도록)

예를들면 페이지의 위치를 기반으로 클릭하도록 테스트를 설계하기 보다는, 버튼의 이름에 기초해 클릭을 하도록 할 수 있다.

GUI테스트와 API테스트를 분리

인수 테스트 작성시 GUI테스트와 비지니스 룰을 테스트 하기위한 API테스트는 최대한 분리하여 테스트를 작성하는게 좋다. GUI테스트 코드가 너무 많으면 테스트코드를 유지하기 힘들다.

지속적 통합

모든 단위테스트와 인수테스트를 하루에 몇번이라도 실행할수 있다록 CI시스템을 도입하자.

CI테스트가 깨졌다면 심각하게 받아들여야 한다(배포 중단)

테스트 전략

단위 테스트나 인수테스트를 보강하는 테스트 전략이 필요하다

QA는 오류를 찾지 못해야 한다

QA팀이 잘못된 점을 찾아내지 못하는 상태를 최종 목표로 삼아야 한다. QA팀이 뭔가를 찾아낼 때 마다 간담이 서늘해져야 정상이다. 하지만 그래도 QA는 같은 팀이라는걸 잊지 말아야 한다.

테스트 자동화 피라미드

1. 단위 테스트

실제 코드의 기능을 명세하는 개발자가 코드를 테스트 하기위함

2. 컴포넌트 테스트

코드를 실제 업무케이스로 묶은 컴포넌트를 테스트. 불행한 경로가 없는 아주 명백한 케이스만 테스트한다. QA 테스트의 영역이다.

3. 통합 테스트

아주 큰 시스템의 경우 컴포넌트 끼리의 관계를 테스트하며. 컴포넌트끼리 춤춘다고하여 안무 테스트라고도 한다.

보통 수석 개발자가 테스트하며. 시간이 오래 걸리기 때문에 빌드과정에서는 제외하며 필요할때마다 테스트를 돌린다.

4. 시스템 테스트

빌드가 잘 되었는지 테스트 하며. 성능이나 처리량 테스트를 한다.

5. 탐색 테스트

테스트 케이스에 상관없이 시스템을 무작위로 마구 두드려 보는 테스트를 한다.

시간 관리

프로는 시간관리를 잘해야 한다. 개발자는 시간을 열리하게 사용해야 한다.

회의

프로는 큰 이득이 없는 회의에는 적극적으로 참석을 거부해야 한다. 개발자의 시간은 소중하다.

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

1. 거부하기

너무 많은 회의에 참석하는 것은 프로답지 못한 행위이다. 자신이 꼭 필요하지 않다고 생각되는 회의는 정중히 거절할줄도 알아야 한다.

2. 빠져나오기

시간을 헛되이 보내면서 다른 이들에게 그다지 도움도 안되는 회의에 남는 일은 프로답지 못한 일이므로 빠져나와야 한다.

3. 목표를 확실히 하기

회의에 주제가 명확하지 않다면 주제를 확실히 하자고 주장해야 한다. 주제가 확실하지 않다면 예의있게 회의에서 빠져나와야 한다

4. 일일회의

최대한 짧게 어제한일 오늘한일 방해요소에 대해 사람당 1분 내외로 말한다.

5. 반복계획회의

백로그에 일감들ㅇ중 다음 반복 주기동안 처리해야할 일을 고르는 일이다. 일정 추정은 이미 끝내둬야 한다. 한 항목당 5분을 넘기지 않는다.

6. 논쟁과 의견차이

논쟁이 길어지는 이유는 주장을 뒷바침 하는 데이터가 없기 때문이다. 데이터가 있는 논쟁의 경우 팀 전체 투표로 결정한다.

집중력 마나

프로 개발자는 집중력을 관리해야 한다. 집중력은 차ㅊ참 사라지는 자원이다. 회의에 집중력을 다 쓰면 실제로 일하는데 필요한 집중력이 남아있지 않다.

1. 수면

충분한 수면이 다음날 최고 상태의 집중력 마나를 제공한다

2. 카페인

적당량의 카페인은 집중력을 강화시키지만, 너무 과섭취하면 이상한 방향으로 집중력을 날려 버린다.

3. 재충전

명상이나 낮잠 또는 잠깐의 휴식은 집중력 마나를 빠르게 회복시킨다. 한번 바닥을 친 집중력 마나는 잘 회복이 안되니 잘 관리해야 한다.

4. 근육집중

신체 운동은 정신 집중의 용량을 늘어나게 한다.

5. 입력과 출력

다른 창의력을 접할때 내 창의력도 높아진다. 코딩만 하지말고 예술작품을 즐기는 등의 다양한 경험을 하는게 좋다.

6. 포모도로 타이머

20분씩 타이머를 맞춰놓고 집중하는 시간을 기록하는 방법으로 집중력을 높일 수 있다.

방해요소 관리

1. 피하기, 우선순위 뒤집기

특정한 일은 그냥 하기싫을 수도 있다. 그리고 중요도와 상관없이 그냥 하기 싫어서 뒤로 미루는일도 있다. 해야할 특정한 일을 피하는 것은 프로답지 못한 행동이다

2. 막다른 길

코딩을 하다 막히면 무모하게 계속 덤벼들지 말고 열려 있는 다른 방법을 찾는것이 좋다.

3. 진흙탕

진흙탕은 막다른길 보다 더 나쁘다. 진흙탕은 조금만 더 하면 될것 같이 짧아 보여서 진도를 나아가지만 결국은 더욱 상황이 복잡해 지는 상황이다.

점점 범위와 복잡도가 커지면서 코드를 확장하기 어려운 상태가 된다. 이때가 변곡점이다. 뒤로 물어나서 설계를 고쳐야 한다. 뒤로 물러나서 처음부터 재작업 하는것은 언뜻 비싼 비용을 치루는 듯 하지만 이때야 말로 되돌이키기 가장 쉬운 지점이다. 이 때를 노치면 다시 올바르게 되잡기는 더욱 힘들어 진다.

추정

개발자는 특정 기능을 완성하는데 걸리는 시간을 추정한다. 추정은 어림짐작이다.

추정에는 비관적 추정, 낙관적추정, 확률이 가장 높은 추정으로 나눌수 있다. 일정을 약속할때는 비관적 추정시간을 고려하여 약속해야 한다.

추정의 확률분포

사업부와 이야기 할때는 항상 비관적, 낙관적 추정을 함께 말해주는 것이 좋으며, 일정을 약속해야 할때는 추정 확률 분포를 수학적으로 계산하여 제시하는 것도 좋은 방법이다.

추정기간 = (낙권적 추정기간 + (4 * 가장 높은 확률의 추정기간) + 비관적 추정기간) / 6

날아다니는 손가락

추정이 힘든경우 동료들의 의견을 물어보는 것도 좋은 방법이다. 일정을 손가락으로 표시하여 특정 카운트에 동시에 손을 내민 후, 의견 일치를 볼때까지 반복한다.

압박

시간제한이 다급한 프로젝트의 경우 개발자는 압박을 느낀다. 프로 개발자는 압박감을 느껴도 침착하고 결단ㅍ력 있게 행동해야 한다.

압박 피하기

1. 약속

애초부터 무모한 일정 약속을 피하면 압박상황을 피할수 있다.

2. 깔끔함 유지

마감일을 지키면서 가장 빠르게 움직니는 방법은 코드를 언제나 깔끔하게 유지하는 것이다. 빨리 하려고 마구잡이로 어지르면 진흙탕에 빠지게 된다. ‘빠르고 지저분한’ 상태는 실제하지 않은 환상이다. 빠르려면 항상 깔끔해야 한다.

3. 규율을 따른다

자신이 진정으로 믿는 규율을 정하고 위기상황에서도 따라라. 보통 때는 테스트 주도 개발 규율을 따르지만 위기가 닥쳤을 때 포기한다면, 마음속 깊은 곳에서는 TDD가 도움이 된다는 사실을 믿지 않는 것이다.

자신이 위기상황에서도 진심으로 도움이 된다고 생각하는 마으우로 정한 규율을 따라라. 리팩토링이 평소 도움이 된다면 위기상황에서도 무자비 하게 리팩트토링을 하는 것이 도움이 된다.

4. 도움을 청하자

위기상황에서 도움을 청할줄 아는 사람이 프로다. 프로는 도움 받는걸 두려와 하지 않는다.

5. 서두르지 말자

압박상황에서 최악의 행동은 조금하게 서두르는 것이다. 압박상황에서는 속도를 늦춰라. 문제를 서두르지 말고 꼼꼼히 고민하는게 가능한 최선의 결과로 가는 길이다.

함께일하기

개발도 결국 사람들과 협업으로 해야 하는 일이다. 독불장군처럼 굴지 말고 상황과 사람을 보고 움직이자.

코드를 나만 소유하려 하지말고 여러 사람이 수정할 수 있도록 하고 서로 배우고 가르치자

팀과 프로젝트

팀은 프로젝트보다 만들기 더 어렵다. 그러므로 영구적인 팀을 만들어 이 프로젝트에서 저 프로젝트로 움직이게 하고 한번에 여러 프로젝트를 맡기는 게 낫다.

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

학교에서는 프로그래밍이론을 가르치지만, 장인의 규율 태도를 가르치지는 않는다. 장인정신은 정서적인 것이며 가르치기 힘들다. 그러므로 선배 프로그래머라면 장인정신을 후배애ㅔ게 몸소 보여주도록 하자. 될성부른 후배는 선배를 보고 그대로 배울것이다.