목차
1부 프로그래머를 위한 원칙
- 1장 시작하기 전에
- 할 거면 잘해라
- 2장 엔지니어의 자세
- 3장 능력자 프로그래머의 한 가지 비밀
- 4장 두 문장으로 요약한 소프트웨어 설계
2부 소프트웨어의 복잡성과 원인
- 5장 복잡성의 간서
- 6장 복잡성을 키우는 방법: API 분리
- 7장 하위 호환성이 가치를 잃는 시점은 언제인가?
- 8장 복잡성은 감옥이다.
3부 단순성과 소프트웨어 설계
- 9장 설계는 프로젝트 초반에 하라
- 올바른 방법 도입하기
- 10장 미래 예측의 정확성
- 11장 단순성과 엄격성
- 12장 둘은 너무 많다
- 리팩토링
- 13장 분별있는 소프트웨어 설계
- 잘못된 방법
- 잘못된 방법 분석
- 이 작업을 여러 사람이 함께 한다면?
- 올바른 방법
- 우리는 소프트웨어 설계 법칙을 따랐다
4장 디버깅
- 14장 버그란 무엇인가?
- 하드웨어
- 15장 버그의 원인
- 복합적인 복잡성
- 16장 재발을 방지하라
- 재발 방지 예시
- 토끼굴로 들어가기
- 17장 디버깅의 기본 철학
- 버그 파악하기
- 시스템 살펴보기
- 진짜 원인 찾기
- 4단계
5부 엔지니어링 팀에서 일하기
- 18장 엔지니어링 생산성을 효과적으로 개선하기
- 그러면 어떻게 해야 할까?
- 해결책
- 신뢰와 문제 해결
- 장애물
- 근원적 문제를 향해 나아가기
- 19장 개발자 생산성 측정하기
- '생산성'의 정의
- 'LOC'는 어떻까?
- 유효한 기준 정하기
- 코드가 제품이라면?
- 개발자 생산성 개선 담당자라면?
- 결론
- 20장 소프트웨어 회사에서 코드 복잡성을 다루는 법
- 1단계: 문제 목록
- 2단계: 회의
- 3단계: 버그 리포트
- 4단계: 우선순위 선정
- 5단계: 과제
- 6단계: 계획
- 21장 리팩토링할 때는 기능에 주목하라
- 효과적으로 일하기
- 리팩토링 한계 설정하기
- 리팩토링을 하면 시간이 절약된다
- 명확하게 만들어라
- 정리
- 22장 친절과 코드
- 소프트웨어에서 중요한 건 사람이다
- 친절의 예
- 친절하게 더 나은 프로그램을 만들어라
- 23장 간략하게 살펴보는 오픈 소스 커뮤니티
- 기여자 유지하기
- 장벽 없애기
- 관심 유도하기
- 아주 인기있는 제품이 돼라
- 인기있는 프로그래밍 언어로 만들어라
- 정리
6부 소프트웨어 이해하기
- 24장 컴퓨터랑 무엇인가?
- 25장 소프트웨어 구성 요소: 구조, 동작, 결과
- 26장 소프트웨어 개정판: (I)SAR 구별하기
- 구조
- 동작
- 결과
- 코드 한 줄에 담긴 ISAR
- SAR 정리
- 27장 지식으로서의 소프트웨어
- 28장 기술의 목적
- 반대 사례도 있을까?
- 기술의 발전이 '좋은' 것인가?
- 29장 간략하게 살펴보는 프라이버시 문제
- 공간의 프라이버시
- 정보의 프라이버시
- 정리
- 30장 단순성과 보안
- 31장 테스트 주도 개발과 관찰 주기
- ODA 사례
- 개발 프로세스와 생산성
- 첫번째 ODA
- 32장 테스트 철학
- 테스트 가치
- 테스트 단언문
- 테스트 범위
- 테스트 가정
- 테스트 설계
- E2E 테스트
- 통합 테스트
- 단위 테스트
- 현실
- 가짜
- 결정론
- 속도
- 커버리지
- 결론: 테스트의 전반적인 목표
7부 나아지기
- 33장 성공의 비밀: 나아지기
- 이 방법이 왜 효과가 있었을까?
- 34장 개떡같은 부분을 찾는 방법
- 35장 '아니요'의 힘
- 나쁜 아이디어 알아내기
- 나쁜 아이디어 내지 않기
- 거절과 무례는 다르다
- 36장 프로그래머가 개떡같은 이유
- 무엇을 배워야 할까?
- 37장 빠른 프로그래밍의 비결: 생각하지 않기
- 이해하기
- 그리기
- 시작하기
- 단계 건너뛰기
- 신체적 문제
- 주의 집중하기
- 자기 회의
- 잘못된 통념
- 주의 사항
- 38장 개발자의 자만심
- 39장 '일관성'과 '획일성'은 다르다
- 40장 사용자는 문제를 알려주고 개발자는 해결책을 만든다
- 신뢰와 정보
- 문제는 사용자에게서 나온다
- 41장 즉각적인 만족감 = 즉각적인 실패
- 해결책은 장기적인 관점으로 찾아라
- 소프트웨어 회사를 망가뜨리는 방법
- 42장 성공은 혁신이 아니라 실행에서 온다
- 43장 훌륭한 소프트웨어
- 1. 사용자의 명령을 정확하게 따른다
- 2. 사용자가 예상한 대로 작동한다
- 3. 사용자의 의도 전달을 막지 않는다
- 코드를 단순하게 만드는 것보다 탁월하게 만드는 게 더 중요하다.
- 이 둘은 상충되지 않는다
이 책은 개발자라면 한 번 읽어보면 좋다고 생각한다.
228장의 소책자이지만 여러가지 챕터로 나뉘며 각 세부사항들이 여태까지 개발에 임하는 태도를 돌아보게 해준다.
많은 챕터 중 가장 기억에 남는 챕터는 아래와 같다.
- 2장 엔지니어의 자세
- 9장 설계는 프로젝트 초반에 하라
- 22장 친절과 코드
- 35장 '아니요'의 힘
- 37장 빠른 프로그래밍의 비결: 생각하지 않기
- 38장 개발자의 자만심
- 42장 성공은 혁신이 아니라 실행에서 온다
어느덧 6년차 개발자가 되어 커리어를 이어가다 보니 '내가 잘하고 있나?'라는 회의감이 자주 찾아온다.
'내가 제대로 알고 일한게 얼마나 됐을까?'
'선배 개발자들의 요구사항이 이상하다고 느꼈을 때, 아니요라고 말한 적이 있었나?'
'내가 설계한 코드들은 예전보다 나아졌을까?'
'열심히 살아온 것 일까?'
...
여러가지 자문자답을 하다 보면 다른 사람들은 어떻게 생활하는지 둘러보게 된다.
주변 환경에 시니어보다 주니어가 많아 그들은 어떻게 생활하는지 살펴보면 '내가 저 연차였을 때 저정도 실력이 과연 됐을까?', '나보다 저 친구들이 더 업무에 몰입을 잘하는 것 같네?' 라는 생각을 받기도 한다.
또 내가 주니어였을 때와 다르게 이상한 점이 발견되면 '아니요'라고 확실하게 말한다는 점과 친절한 점이 많은 귀감이 된다. 그러면서 나이가 적은 사람한테서 배울 점도 많구나라는 것을 새삼 느낀다.
기본적으로 아래의 목차 내용을 기본 탑재한 사람들이었다.
- 2장 엔지니어의 자세
- 22장 친절과 코드
- 35장 '아니요'의 힘
혼자 코드를 개발하다 보면 생각에 빠져 그 설계가 옳다고 생각되지만 옆에서 누군가 '아니요'라고 말해주면 바른 설계로 수정이 가능하다. 이 때 필요한 자세는 자만하지 않고 겸손하게 주변의 말을 경청하는 것이다.
이 부분이 참 어려웠고 고치려 부단히 노력했었다.
내가 최고라는 자만심을 내려 놓으면 주변이 보이고 코드의 품질이 향상되어 갔다.
(나는 사실 최고라고 말하기도 어려운 사람인데 참 어리석었다.)
설계를 하다보면 '이 방식이 맞을까?'라는 고민을 참 많이 한다. 완벽한 방법을 찾으려고 시간을 허비하는 것이다.
그러다보니 시작은 못하고 생각만 많아져 정해진 납기일을 놓치는 경우도 많았다.
이와 관련된 내용이 아래 챕터에 나온다.
- 9장 설계는 프로젝트 초반에 하라
- 37장 빠른 프로그래밍의 비결: 생각하지 않기
- 42장 성공은 혁신이 아니라 실행에서 온다
초반에 설계를 하고 나서 나중에 개선 점이 발견되더라도 일단 쭉 진행하는 것이 낫다고 생각하며,
실행하지 않은 좋은 아이디어는 평가를 받을 수 없으니 남들에게 드러나도록 결과로써 보여줘야 한다.
