1. 책을 읽게 된 이유

이번에 회사를 이직했는데… 무려 내 컴이 안왔다ㅋㅋㅋㅋㅋㅋ 근처에 계신 (무려) 과장님께서 노트북을 빌려주셨지만… 남의 컴을 쓰려니까 아무것도 못하겠더라

다행히(?) 과장님이 노트북을 주시면서 책도 같이 주셨는데, 그 책의 제목이 바로 “클린코드” 라는 책이었다. 어떤 프로그래머가 되라는 책은 열심히 읽지 않았다.(?) 그것 까지 읽으면 너무… geek한 개발자가 되버릴까봐 무서워서 였는데(좋은 프로그래머는 되고 싶지만 geek하고 싶지 않다)

읽어보니 지금상황에 딱 필요한 책이었던 것 같다.

2. 책 요약

어느정도 제 안에서 정리한 것이기 때문에, 제 언어로 쓰여있는 내용이 많다는 것을 이해해 주시기 바랍니다.

1장. 프로의 마음가짐

Test 100% coverage를 채워라

• 구조
  • 매일 구조 및 코드를 바꿔라.
  • 과거에 쓴 코드는 무조건 다 레거시다.
  • test만 잘 짜놨다면 멈출까봐 하는 두려움은 없어진다.
• 직업윤리
  • 회사에서 호의로 공부 하는 시간을 일하는 시간으로 준다면 좋지만 그것이 호의라는 사실을 기억하라.
  • 회사에서 공부시간을 안주면 자신이 알아서 공부시간을 확보해라.
  • 40시간 일을 한다면 20시간 공부해라.
• cs지식
  • 디자인 패턴: 24가지 GOF 패턴 설명가능 정도, POSA 패턴은 실무 적용까지 등등 …
  • 설계원칙: SOLID, 컴포넌트 개념 이해 등등…
  • 방법론: 스크럼 반 등등…
  • 원칙: TDD, 객체지향 설계 등등…
  • 도구: UML, PFB 등등…

끊임 없이 배우고 연습해야 한다는 사실을 잊으면 안된다.

• 일은 공연이고, 공부는 연습이다.
• 매일 problem solving을 업무전 한두개씩 풀어라.

그 뿐만 아니라 기본적으로 회사의 일원으로서 노력을 해야한다.

• 함께 일하고, 멘토링을 받기도하고 주기도 해라.
• 업무 지식을 익히고, 회사와 고객에게 동질감을 느껴라
• 겸손해라

2장. 아니라고 강하게 말하기

헛된 희망, 불가능한 노력을 명확하게 지속적으로 책임감을 가지고 말해야 능력있는 개발자이다.

대답하는 법

• 프로젝트을 제 때 완수할 수 있을 지에 대한 대답에는 Y or N 만 해야한다.
• 명확하게 기한을 제시하는데, 여기서 말하는 기한은 test code와 좋은 구조를 충분히 생각 후 짰을 기준으로 세운 기한이어야 한다.
• 상대가 기한을 절대로 양보하지 않을 때는 프로젝트 규모를 줄여야만 한다.
• 규모를 줄이는 것 역시 우리의 업무영역이라는 사실을 잊지 말고 말하자.

명확한 대답을 해야하는 이유

• 상대를 위해서 내 인생을 갈아서 만들어줘 봤자, 상대편은 내 노고를 매번 받아도 되는 것으로 생각한다.
• 심지어 갈아서 넣어주면 다음에는 더 심한 무리를 요구할 수 있다.
• 상대는 명확하게 대답을 안하면 자신에게 이로운 쪽으로 생각해서, 내 이미지만 나빠진다.

3장. 예라고 말하기

예라고 대답할 시는 원칙을 유지한 채 test code 짤 시간 확보와 개발 구조를 위한 충분한 생각 후 코드짜기 로 일을 해야하고, 일을 마치고 쉴 수 있는 상황을 만들어 달라고 반드시 말해야 더 오랫동안 이 일을 할 수 있다.

4장. 코딩

몸과 마음을 품질 높은 프로그래머로 오래 일할 수 있도록 지속적으로 잘 단련 시키자.

좋은 코드를 만들기 위한 자세

1. 코드 원하는 대로 동작시키기
2. 추가 코드 작성시 기능이 추가되는 느낌으로 만들기
3. readable하게 만들기

5장. 테스트 주도 개발 (red - green - refactor)

3법칙

1. 실패 단위 test 만들기 전까지 제품 코드 만들지 x
2. 컴파일 안되거나 실패 단위 test 있으면 더이상 단위 test 만들지 x
3. 실패한 단위 test 통과하는 이상, 제품코드는 만들지 x

혜택

• 코드 리팩시 test를 다 짜놨기에 용기 있게 할 수 있다.
• 프로그램 로직 관련 test는 문서화와 비슷한 이점이 있다.
• 경우의 생각을 많이 생각하다 보니 설계에 이점이 있다.
• 프로로서의 간지

6장. 연습

혼자서던 여러명이서던 열심히 연습하자. 오픈소스로 공부 시 기술 목록 다양화를 위해 다른 언어로 하는 것을 추천한다.

7장. 인수 테스트

요구사항이 언제 완료 되는지 정의를 위해 이해당사자들과 프로그래머들이 함께 작성하는 TEST

• 모호함을 제거하는것이 중요
• 소통, 명확성, 정밀성
• 자동화해야한다.
• 단위테스트는 개발자끼리 소통인 반면 인수테스트는 사업팀과 개발자간의 소통이다.
• GUI TEST는 최소화

8장. 테스트 전략

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

• 단위 TEST
  • 프로그래머가 프로그래머를 위한 test
  • 지속적 통합을 위한거면 일부로 실행되어, 의도한 바를 지킨다.
• 컴포넌트 TEST
  • 인수 test 일종
  • 시스템의 독립 컴포넌트가 컴포넌트 test의 대상이다.
  • 시스템 컴포넌트는 업무 규칙을 감싸고 있기에, 컴포넌트를 대상으로 한 test는 해당 업무 규칙 test하는 인수 test이다.
  • 컴포넌트에 입력 Data를 넣고, 출력값을 모아서 TEST
• 통합 TEST
  • 컴포넌트 묶음을 모아 상호작용이 제대로 되는지 확인하는 TEST
  • 여러 컴포넌트로 이루어진 시스템에서만 의미있다.
  • 시스템 구조 설계를 튼튼히 하고, 사실 보장, 성능 test와 throughput test가 가능
  • 시간이 많이 걸린다.
  • 컴포넌트에는 mock component, test Double이 있어 test와 분리된다.
• 시스템 TEST
  • 시스템 전체를 대상으로 하는 자동화 test(통합 test)
  • 성능, 처리량 test
  • 시스템 test는 시스템 아키텍쳐나 기술 책임자가 만든다.
  • 자주 돌릴수로 good
• 수동 TEST
  • 직접 손으로 하는 test

9장. 시간 관리

회의는 필요할 때도 있고 낭비일 때도 있다. 그럼으로 자신만의 규칙을 세우는게 매우 중요하다.

• 거부하기
  • 참석할 회의, 거절할 회의 신중히 골라야 한다.
  • 자기 시간은 본인이 챙겨라
• 빠져나오기
  • 적당히 필요하지 않는 회의는 빠지자
• 의제와 목표
  • 참석자 분들의 시간 역시 잘 쓸 수 있도록 하자
  • 내가 참석할 때는 토론할 것, 이루고자 하는 목표 없음 참석 x
• 일일 회의
  • 20초선
  • 1. 어제 무엇을 했나. 2. 오늘 무엇을 할 예정인가. 3. 업무 방해요소는 무엇인가
• 반복 계획 회의
  • 목적: backlog에서 다음 반복 주기(iteration)동안 처리할 항목 고르는 일
  • 1주일 2시간 이내
• 반복 회고와 시연
  • 각 반복 주기가 끝날 때마다 시행
  • 1주, 2주에 한번 45분 이내가 적정량
  • 반복 주기의 마지막 날 업무 종료시간에 하는게 좋다.
• 논쟁 / 의견차이
  • 5분 안에 해결되지 않으면 쉽게 해결 x
  • data를 가지고 합의
    • simulation, modeling
  • 회의 시간 50분 이하로
• 집중력 마나, 수면, 카페인, 재충전, 집중력 근육
  • 집중력과 체력은 소모자원이니 관리를 잘하자
• 다른 사람들의 창의력 탐방
• 뽀모도르
• 피하기, 우선순위 뒤집지 말자, 막다른 길 만나면 피할줄도 알아라
• 진흙탕은 최대한 빨리 수습하며 상사에게 빠르게 알려라

10장. 추정

너무 어렵다(못한다면 정상이긴 하다.)

• 약속(확실함이 있지 않은 한 절대 NO, 하면 무조건 지켜야 한다.)
• 추정하기
  • 이 능력을 키우기 위한 특별한 기술이 없기 때문에 모두가 못한다.
  • 안지켜도 되고, 짐작이다.
  • 추정은 분포다
    • ex) 1일에 끝날 확률 50% 2-3일에 끝날 확률 80% 4일에 끝날 확률 70% 10일에 끝날 확률 10%
  • 엉겹결에 약속 x
    • 동료와 함께 고민하는게 good
  • 많은 방법론이 있다.(PERT(방법론), 업무추정(주변 사람과 함께 추정))

11장. 압박

피할 수 있으면 피하고, 피할 수 없음 극복해라

• 압박 피하기
  • 피하는 법은 주의 깊게 약속하고 규율을 따르고 깔끔한 코드를 유지한다.
  • 극복하는 법은 침착을 유지, 상사와의 의사소통, 규율을 따르고 도움을 받는다.
  • 압박은 보통 약속 때문이니, 달성할 확신이 없는 마감일 약속은 피한다.
• 압박 다루기
  • 서두르면 fail하니 당황하지 말자
  • 상사에게 ASAP 알려서 의사소통을 한다.
  • 압박이 심할 때 길잡이가 됨으로 규율에 잘 의지한다.
  • pair programming을 하여서 도움을 받는다.

12장. 함께 일하기

프로그래머의 종특이 홀로 일하기이다.

• 너무 기술에 파묻혀서 회사임을 잊지 말자
• 회사에도 적응해야한다.
• 회사 내 코드는 공동 소유하고, pair programming을 하자

13장. 팀과 프로젝트

팀 위주로 프로젝트를 꾸며야지, 프로젝트로 팀을 꾸려서는 안된다.

• 팀원들은 적어도 한 프로젝트에 deep 다이브 되어 있어야 한다.
• 숙성되는 데 시간은 오래 걸릴 수도 있다.
  • 되면 존굿인 것이다.
• 끝나도 절대로 팀 해체하지 말고 그 팀에 새 프로젝트를 주는게 자원적으로 효율적이다.
• 영구적인 팀을 만들어 그 팀이 각 프로젝트들을 하나씩 끝내가는게 제일 좋은 방법이다.
• 팀을 만드는 목적은 한 덩어리로 뭉칠 시간을 충분히 줘서 여러 프로젝트를 완수할 원동력을 제공하는 것

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

• 견습기간
  • 회사는 신입 프로그래머한테 어느정도 일에 적응하기 위해 교육기간이 필요하다는 것을 인정하고 받아들여야한다.
  • 이건 모든 직무에서 다들 그렇다는 것을 인정해라 ㅠㅠ
• 장인들
  • 10 년 이상 일을 한 사람들
  • 여러 플랫폼, 시스템, 언어에 익숙한 사람들
  • 경영직의 제안을 받고도 거절한 정도의 사람들
  • 어느 프로젝트에 대한 기술 책임을 할당 되는 사람들
• 숙련공
  • 평균 5년 정도 일한 사람들
  • 훈련 받은, 능숙한, 열정적 프로그래머
  • 팀 내 일을 배워 리더가 된 사람들
  • 한 언어, 시스템, 플랫폼에만 익숙해 다양한 시스템에는 경험이 부족
• 견습생/인턴
  • 졸업생들
  • 숙련 프로그래머들에게 밀착 지도 당하는 사람들
  • 1년정도의 기간
• 현실
  • 절차에 따라 승진만 된다.
• 장인 정신
  • craftmanship
  • 서두르지 않으면서도 일을 빠르게 처리하며, 합리적인 평가를 제공하고 임무를 처리
  • “아니오”인 상황에서 “예”라고 대답하려 노력
• 확신 심어주기
  • 장인이 될 수 있다는 확신은 줄 수 없다.
  • 장인정신은 감염이 된다. 그러므로 너가 롤모델되라

3. 느낀점

꽤 많은 것이 충격적이었고, 잘못 생각하고 있다는 사실을 알았다. 가장 크게 달라질 것은…

• 테스트는 무조건 짜야겠다는 생각을 했다. test를 짜다보면 이게 뭔가 짜야되겠다는 건 알겠는데 이거 왜짜.. 귀찮아 라고 생각했는데 확실히 매번 리팩할 때마다 멈추면 어쩌지라는 생각에서 해방을 줄 거라는 말은 정말 논리적이라고 생각했다.
• 개발 기한은 충분히 코드를 좋게 짤 생각을 할 시간과 test 코드까지 다 짠 시간을 말하는 것이다. 어차피 지금쓰는 코드는 다 레거시가 된다. 그럼으로 무조건 저 작업들을 해야만 한다.
• 좋은 개발자가 되라는 책 읽는다고 나쁘지는 않은 것 같다. 그치만… 여전히 geek해질까봐 좀 무섭다 ㅠㅠ 이러다가 데니스 리치같이 생겨질까봐 무섭다 ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ