시립도서관에 놀러갔다가 우연히 발견해서 읽기 시작한 책.
책 내용은 2파트로 나뉘어져 있다. 앞부분은 프로그래밍적인 조언을 해주고 있고, 뒷부분은 회사 생활에 대해 얘기하고 있다.
앞 부분의 프로그래밍 팁들은 그동안 내가 실무에서 느꼈던 추상적인 생각을 구체적인 말로 풀이해준 것 같아서 좋았다. 덕분에 그 동안의 생각들은 정리할 수 있었다.
예를 들면, 항상 테스트의 중요성을 느껴왔지만, 단위테스트, 인수테스트, 부하테스트, 호환성테스트, 장기테스트 등등의 용어로 카테고리화 되어 있지 않았었다. 머릿속에 퍼져있던 개념들이 체계화되어 정리할 수 있었다. 또 다른 예로는 코드 리뷰이다. 평소에 회사에서 코드 리뷰 받는 것을 매우 좋아하고 친구들한테도 코드 리뷰의 필요성에 대해 극찬하며 다녔지만 무엇이 좋은지, 어떻게 코드 검토를 제대로 받을 수 있는지는 정리되지 않았었다. 책에서 단계별로 정리해주었다. 첫번째, 수정한 파일 목록을 생성하라, ... 세번째, 변경 사항을 스스로 살펴보고 모든 것을 설명할 수 있는지 확인하라 등등... (아주 잘하고 있었구만!! 다만, 원본과 사본 사이에서 바뀐 부분을 강조해 보여줄 수 있는 winmerge 이런 툴을 이용해 리뷰를 받도록 해야겠다~) 후반부 사회생활에 관련된 내용은 이 책으로부터 기대하는 내용은 아닐 수 있다.
그치만 유익했다. 알쓸신잡 같은 느낌이랄까?ㅎㅎ
Tip 8. 처음부터 코드 검토를 자주 하라. => "코드 리뷰"
코드 검토가 잘 안되는 이유는 프로그래머가 코드의 가치와 자신의 가치를 연결 짓기 때문이다.
'결함'이라는 것은 버그부터 스타일 문제에 이르기까지 다양하다.
멋지고 죽여주는 코드일 필요가 없다. 단지 견고한 코드면 된다.
이것은 설계와 스타일에 관해 토론할 기회다. 검토 중에 받을 것 같은 비판에 대해 준비하고 내가 사람과 관점에 대해 언급한 문제들을 염두에 두라.
끝까지 파고들 것이다. 왜 이러저러한 설계를 선택했나? 이 가정을 증명하기 위해 어떤 데이터를 갖고 있는가? 구현이 올바른지 어떻게 증명(테스트)할 것인가? .... 프로그램을 짜면서 같은 질문을 자신에게 해보라는 것이다.
Tip 12. 어려운 작업은 자동화하라
프로그래머로서 여러분의 가치는 아이디어에 있지, 타자에 있지 않다.
자동화는 지루한 작업을 대신 해 주는 것뿐 아니라 실수도 줄인다.
Tip 18. 연말 평가에서 A 받기
자기 평가 : 최근에 회사를 위해 한 일이 무엇인가
품질 : 무엇보다 흠 없는 코드를 짤 수 있음을 보여야 한다. 코드 라인당 오류율, 버그 수정 수, 테스트 케이스 작성 수 등, 여러분이 적용하기 시작한 설계 원칙, 팀의 테스트 인프라스트럭처에 기여한 개선 사항
양 : 완성한 기능 개수, 릴리스한 제품 개수, 커밋한 소스 개수 등
일정 관리 : 여러분이 일정을 맞춘 횟수를 따져보기
회사 비용 절약
진급: 그것은 여러분이 그 역할을 얻기 전에 그 역할을 하고 있어야 한다는 것이다.
감각(또는 데이터)지향적 vs 직관과 연상에 의지
말은 하는데 이유를 설명하기 어려워한다면, 그의 의견을 밀쳐버리기보다 받아주려고 하라.
그가 설명할 수 없다고 해서 ... 뇌의 선형적이고 논리적인 사고를 하는 곳에서 온 생각이 아닐 뿐이다.
사람들은 대부분 감각/직관의 척도 위에서 어느 한쪽으로 약간 쏠려 있으며, 날마다 감각과 직관 둘 다 사용한다는 점을 기억하라.
- 생각에 의지하는 사람은 외부에서 문제를 살펴보며 가장 좋은 행동을 이성적으로 찾아내려고 한다. 아주 친절하고 인정 많은 성격일 수 있지만, 최종 결론은 상황에 대한 그들의 느낌보다 논리에 더 근거한다.
- 감정에 의존하는 사람은 특정 상황에 감정적으로 자신을 넣어버린다. 사람들과 환경에 개인적인 차원에서 공감한다. 엄청나게 이성적일 수 있으나, 결국에는 근본적으로 옳다고 느끼는 것에 따라 행동하는 사람들이다.
감정형 사람들의 판단 방식을 열등한 것으로 치부하지는 말라. 넓게 보면 여러분은 날마다 ‘사람’들과 일하고 있으며,...
처음 자신에게 주어진 작은 일에 파묻히지 말고, 큰 그림 속에서 프로젝트를 이해하는 것이 날마다 판단을 내리는 데 중요한 역할을 할 것이다.
프로그래머들은 기능 한 가지를 더 추가하거나 버그를 하나 더 수정하려는 유혹에 늘 빠진다. 더 잘 만들 수 있다는 생각에, 제품을 내놓으려고 하지 않는다. 그와 반대로 관리자들은 하루라도 더 빨리 출시하고자 한다. 누가 옳을까?
양쪽 시각 모두 제품을 더 좋은 것으로 만든다. 모든 제품의 버전 1.1은 원래 버전 1.0이었어야 한다는 기술 세상의 격언도 있다. 1.0 버전에 대한 현실 세계의 피드백이 1.1을 만들게 하는 원동력이기 때문이다. 지름길이란 없다. 아무리 울퉁불퉁해도 1.0을 출시해야만 고객들이 바라는 1.1의 모습을 들을 수 있다.
세세한 것에 신경 쓰기, 꼼꼼한 테스트, 회사의 출시 프로세스를 제대로 따르는 일 등
독립적인 엔지니어로서 평판을 쌓을 수 있는 기회로 삼으라
프로그래밍 일에서 지속적인 향상과 완벽함을 추구하는 방법은 뻔하다. 새로운 프로그래밍 언어를 학습하거나 컴퓨팅의 새로운 영역으로 기술들을 넓혀나가거나 오픈 소스 프로젝트에 기여해 자신만의 기술을 만들어 가는 것 등이 있다.
“이거 형편없네”에서 “이렇게 하면 썩 괜찮지 않을까?”로 시각을 바꾸면 패배주의적 마음가짐에서 창조적 마음가짐으로 전환하게 된다.
추천 책 리스트
- 켄트 벡 - Test-Driven Development: By Example
- Test Deriven Development for Embedded C
- 피어스 - Types and Programming Languages
- 킴 부르스 - Foundations of Object-Oriented Languages: Types and Semantics
- Growing Object-Oriented Software, Guided by Tests
- 마이클 페더스 - Working Effectively with Legacy Code
- 마틴 파울러 - Refactoring: Improving the Design of Existing Code
- 앤디 헌트 - Pragmatic thinking and learning
