[클린코더: 엉클밥] 당신은 프로인가?

 클린코드로 유명한 엉클밥의 다른 책, 클린 코더다. 프로란 어때야하는가를 중점적으로 '이래라 저래라'하는 책이다. 프로에 대한 막연한 생각을 정리하는데 도움이 되었다. 엉클밥은 회사에 손해를 끼쳤다면 그 손해를 물어주는 것이 프로의 자세라고 말한다. 그런 일이 나에게 일어난다면 과연 그럴 수 있을까 라는 생각도 들지만, 더 책임감 있게, 개발에 최선을 다해야 겠다는 생각이 들었다. 손해를 감당해야 프로이기 때문이라기 보다는, 그래야 멋있으니까.

 집중력이 극에 달할 때 들어서는 영역인 '존'이 가독성 있는 개발에 도움이 되지 않는 다는 부분이 공감되었다. 존에서 개발했던 부분은 어느 정도는 삽질 영역이고 필요하지 않은 부분이었던 경우가 많았다. 엉클 밥은, 이런 경우에 다른 사람과 대화를 하면서 개발을 하는 것을 권한다. 다른 사람과 대화하면 더 어렵지 않은 방법으로 쉽게 해결할 수 있을 것이다.

 

책에서 다루는 내용

• 소프트웨어 프로란 무엇인가?
• 프로는 어떻게 행동해야 하는가?
• 프로는 어떻게 사람들 사이의 대립, 빡빡한 일정, 불합리한 관리자를 감당해 내는가?
• 프로는 언제 어떻게 '아니요'라고 말해야 하는가?
• 프로는 어떻게 주위의 압박을 처리하는가?

정직 명예 자기존중 긍지 + 책임 의무 기술장인이 되겠다는 막중한 책임을 기꺼이 짊어지겠다는 의지 그 책임은 일을 훌륭히 그리고 깔끔히 완수해야한다는 책임 원활히 의사소통하고 추정을 할 때 신뢰감을 줘야한다는 책임 시간을 잘 관리하고 위험 호상에 대한 힘든 결정을 감내하겠다는 책임

프로그래머에 대한 정의 태도,원칙,행동

기능에 해를 끼치지마라=오류에 책임져라 구조에 해를 끼치지마라=구조가 좋아야 코드가 유연

프로 소프트웨어 개발자라면

1. 전산 분야 지식을 익혀라.

   나씨 슈나이더만 차트? 밀리 상태 기계, 무어 상태 기계가 어떻게 다른가? 검색하지 않고 퀵소트 짤 수 있는가? 변환 분석이라는 용어를 아는가? 데이터 흐름도를 기능 분해할 수 있나? 떠돌이 데이터? 코너씬? 파나스 테이블이 무엇이나?

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

1. 끊임없이 배워라 최신 의학 논문을 보지 않는 의사를 찾아가고 싶은 맘이 드는가? 최신 판례와 세법에 신경쓰지 않는 세무사에게 일을 맡기고 싶은가?
2. 연습 품새!
3. 함께일하기
4. 멘토링 배우기에 가장 좋은 방법은 가르치는 것. 가르치고 배울때 더 큰 이득을 보는 쪽은 선생님이다. 마찬가지로 새로운 사람을 조직에 익숙하게 만드는 가장 좋은 방법은 옆에 앉아서 몇가지 작업 요령을 알려주는 일이다. 프로라면 후배들을 멘토링하는 책임을 져야한다. 후배들이 방치된 채 이리저리 떠돌게 둬선 안된다.
5. 업무지식을 익혀라 도메인에 대한 이해 없이 스펙만 개발하는 것은 최악. 프로답지 못하다
6. 회사와 고객에 동질감을 가져라 회사의 문제=자신의 문제
7. 겸손 프로그래밍은 창조행위. 과감히 혼돈에 질서를 부여한다. 피해를 입힐지도 모르는 위험을 무릎쓰고 자신만만하게 기계를 이리저리 정밀하게 움직이도록 명령한다. 그러므로 프로그래밍은 극도로 오만한 행위이다. 프로는 쫄지 않는다. 프로는 자신이 웃음거리가 됐을때, 가장 먼저 웃는다. 절대 다른 사람을 비웃지 않지만 자신이 비웃음거리가 될만하다면 기꺼이 받아들인다. 다른사람이 실수했다고 망신을 주지 않는다. 다음번 실패할 사람이 자신임을 알기때문이다.

---

코딩 . 준비된 자세 힘든 일정 수준의 농축된 집중력 필요하다. 여러 대립 요소를 한꺼번에 교묘히 양립시켜 다뤄야하기 때문이다. 지치거나 주의력이 흩어졌다면 코드를 만들지마라. 해봤자 결국 재작업해야한다.

1. 코드는 반드시 동작해야한다. 풀고자하는 문제가 어떤 문제며 어떻게 풀어야하는지 확실히 이해해야한다.
2. 고객이 제시한 문제를 반드시 풀어야한다
3. 기존 시스템에 잘 녹아들어야한다. SOLID!
4. 다른 프로그래머가 읽기 쉬어야한다.

- 새벽 3시에 짠 코드 . 근심이 담긴 코드 . 몰입 영역

흔히 flow 혹은 zone이라 말하는 영역에 빠지는 것은 대부분의 사람들이 생각하는 것 만큼 좋지 않다. 물론 개발자는 단일 작업에 계속 집중할 수 있지만 큰 단점은 현재 수행 중인 작업의 컨텍스트인 큰 그림을 보지 못하게 한다. 버그, 코드 복제 및 현재 코드 조각이 시스템의 다른 부분과 어떻게 통신해야하는지 minunderstanding으로 이어질 수 있다. 이런 경우 pair programming이 도움이 된다. . 음악 . 외부 방해 (tdd + 짝프로그램. context유지에 도움). 방해가 찾아오면, 다음 번에는 자신이 남을 방해할 필요가 있을지도 모른다는 사실을 기억하라. 그래서 프로다운 태도로 예의바르게 기꺼이 도와야한다 . 진퇴양난에 빠진 글쟁이(짝프로그래밍!) . 창의적 입력

- 디버깅, 디버깅시간(tdd 추천) . 속도조절.

개발은 마라톤이기때문에, 자원을 보존하고 속도를 조절해야한다. 프로 프로그래머는 기력을 보존하고 창의성도 챙긴다 . 언제 걸어 나가야 할지 알기 . 집까지 운전하기 . 샤워 . 도움받기가 도움이 된다. 프로그래밍은 너무 어려워서 한 사람의 능력으로는 잘 해내기가 어렵다. 아무리 기술이 뛰어나도 반드시 다른 프로그래머의 생각과 아이디어에서 도움을 받는다. 이런 이유때문에 서로를 도울 준비를 하는 일은 프로그래머의 의무. 타인을 돕기 위해 약간의 시간도 마련하지 못할 만큼 중요한 업무는 없다. 프로라면 명예를 걸고 어떤 때든 도움을 줘야한다. 혼자만의 시간도 당연 필요. 하지만 공정하고 예의바르게.

- 멘토링 젊은 프로그래머는 선배에게 멘토링을 구하는 일이 프로로서의 의무다.

선배가 주는 효과적인 멘토링 말고는 본인의 노력 이상으로 더 빨리 젊은 소프트웨어 개발자가 제대로 일하게 만들 수 있는 방법이 없다. 책도 교육 강의 과정도 해낼 수 없음(ㅜㅜ)

- TDD 장점 확신 용기 오류감소 문서화 설계 = 프로다움 사후 테스트는 먼저 만든 테스트만큼 예리하지 않다.

- 오픈소스 변화의 물결을 따라잡는 한가지 방법은 의사나 변호사처럼 하는 것이다. 오픈 소스 프로젝트에 기여해 공익에 봉사 하라.

- 회의 회의는 참석자마다 시간당 약 20만원 정도의 비용이 든다.

1. 회의는 필요하다
2. 회의는 시간낭비다.

논쟁/의견 차이 켄트벡 "어떤 논쟁이든 5분 안에 해결되지 않으면 논쟁으로는 해결 할 수 없다." 논쟁이 길어지는 이유는 양쪽 모두 근거가 되는 명백한 증거가 없기 때문. 기술적인 면에서 나타나는 의견 차이는 보통 대기권을 돌파하는 경우가 많다.

- 프로 개발자는 집중력 마나를 잘 활용하기 위해 시간을 관리하는 법을 익혀야한다. 수면 카페인 재충전 근육집중(신체적집중) 입력vs출력

타임박스와 뽀모도로 우선순위 뒤집기: 프로는 개인적 두려움과 바람은 제쳐두고 각 업무의 우선순위를 검토하고 우선순위에 따라 순서대로 업무를 진행한다.