심플 소프트웨어
더북(TheBook)

심플 소프트웨어

100년 뒤에도 유용할 소프트웨어 설계 원칙 & 프로그래머의 바른 길!

Google의 코드 건강(Code Health), 즉 코드의 가독성, 안정성, 단순성, 유지보수성은 어떻게 개선되어 왔을까? 오픈소스 버그질라(Bugwilla)는 어떻게 침체기를 벗어나 다운로드 수를 10배 이상 늘렸을까? 그 중심에는 이 책의 저자 맥스-카넷 알렉산더가 있다. Google의 기술 책임자로서, 버그질라 프로젝트의 수석 아키텍트로서 활동하면서 얻은 통찰과 깨달음을 이 한 권에 담았다. 수많은 프로그래머가 올바른 방법으로 소프트웨어를 설계하고, 더 나은 코드를 작성하도록 도와준 ‘소프트웨어 설계 원칙’을 차근차근 이야기해 준다.

«심플 소프트웨어»는 3~4부(9~17장)를 공개합니다.

목차

  • Part 1 프로그래머를 위한 원칙
  • CHAPTER 1 시작하기 전에
  • 할 거면 잘하라
  • CHAPTER 2 엔지니어의 자세
  • CHAPTER 3 능력자 프로그래머의 한 가지 비밀
  • CHAPTER 4 두 문장으로 요약한 소프트웨어 설계
  • Part 2 소프트웨어의 복잡성과 원인
  • CHAPTER 5 복잡성의 단서
  • CHAPTER 6 복잡성을 키우는 방법: API 분리
  • CHAPTER 7 하위 호환성이 가치를 잃는 시점은 언제인가?
  • CHAPTER 8 복잡성은 감옥이다
  • Part 3 단순성과 소프트웨어 설계
  • CHAPTER 9 설계는 프로젝트 초반에 하라
  • 올바른 방법 도입하기
  • CHAPTER 10 미래 예측의 정확성
  • CHAPTER 11 단순성과 엄격성
  • CHAPTER 12 둘은 너무 많다
  • 리팩토링
  • CHAPTER 13 분별 있는 소프트웨어 설계
  • 잘못된 방법
  • 잘못된 방법 분석
  • 이 작업을 여러 사람이 함께한다면?
  • 올바른 방법
  • 우리는 소프트웨어 설계 법칙을 따랐다
  • Part 4 디버깅
  • CHAPTER 14 버그란 무엇인가?
  • 하드웨어
  • CHAPTER 15 버그의 원인
  • 복합적인 복잡성
  • CHAPTER 16 재발을 방지하라
  • 재발 방지 예시
  • 토끼굴로 들어가기
  • CHAPTER 17 디버깅의 기본 철학
  • 버그 파악하기
  • 시스템 살펴보기
  • 진짜 원인 찾기
  • 4단계
  • Part 5 엔지니어링 팀에서 일하기
  • CHAPTER 18 엔지니어링 생산성을 효과적으로 개선하기
  • 그러면 어떻게 해야 할까?
  • 해결책
  • 신뢰와 문제 해결
  • 장애물
  • 근원적 문제를 향해 나아가기
  • CHAPTER 19 개발자 생산성 측정하기
  • ‘생산성’의 정의
  • ‘LOC’는 어떨까?
  • 유효한 기준 정하기
  • 코드가 제품이라면?
  • 개발자 생산성 개선 담당자라면?
  • 결론
  • CHAPTER 20 소프트웨어 회사에서 코드 복잡성을 다루는 법
  • 1단계 : 문제 목록
  • 2단계 : 회의
  • 3단계 : 버그 리포트
  • 4단계 : 우선순위 선정
  • 5단계 : 과제
  • 6단계 : 계획
  • CHAPTER 21 리팩토링할 때는 기능에 주목하라
  • 효과적으로 일하기
  • 리팩토링 한계 설정하기
  • 리팩토링을 하면 시간이 절약된다
  • 명확하게 만들어라
  • 정리
  • CHAPTER 22 친절과 코드
  • 소프트웨어에서 중요한 건 사람이다
  • 친절의 예
  • 친절하게 더 나은 프로그램을 만들어라
  • CHAPTER 23 간략하게 살펴보는 오픈 소스 커뮤니티
  • 기여자 유지하기
  • 장벽 없애기
  • 관심 유도하기
  • 아주 인기 있는 제품이 돼라
  • 인기 있는 프로그래밍 언어로 만들어라
  • Part 6 소프트웨어 이해하
  • CHAPTER 24 컴퓨터란 무엇인가?
  • CHAPTER 25 소프트웨어 구성 요소: 구조, 동작, 결과
  • CHAPTER 26 소프트웨어 개정판: (I)SAR 구별하기
  • 구조
  • 동작
  • 결과
  • 코드 한 줄에 담긴 ISAR
  • SAR 정리
  • CHAPTER 27 지식으로서의 소프트웨어
  • CHAPTER 28 기술의 목적
  • 반대 사례도 있을까?
  • 기술의 발전이 ‘좋은’ 것인가?
  • CHAPTER 29 간략하게 살펴보는 프라이버시 문제
  • 공간의 프라이버시
  • 정보의 프라이버시
  • 정리
  • CHAPTER 30 단순성과 보안
  • CHAPTER 31 테스트 주도 개발과 관찰 주기
  • ODA 사례
  • 개발 프로세스와 생산성
  • 첫 번째 ODA
  • CHAPTER 32 테스트 철
  • 테스트 가치
  • 테스트 단언문
  • 테스트 범위
  • 테스트 가정
  • 테스트 설계
  • E2E 테스트
  • 통합 테스트
  • 단위 테스트
  • 현실
  • 가짜
  • 결정론
  • 속도
  • 커버리지
  • 결론: 테스트의 전반적인 목표
  • Part 7 나아지기
  • CHAPTER 33 성공의 비밀: 나아지기
  • 이 방법이 왜 효과가 있었을까?
  • CHAPTER 34 개떡 같은 부분을 찾는 방법
  • 나쁜 아이디어 알아내기
  • 나쁜 아이디어 내지 않기
  • 거절과 무례는 다르다
  • CHAPTER 35 ‘아니요’의 힘
  • CHAPTER 36 프로그래머가 개떡 같은 이유
  • 무엇을 배워야 할까?
  • CHAPTER 37 빠른 프로그래밍의 비결: 생각하지 않기
  • 이해하기
  • 그리기
  • 시작하기
  • 단계 건너뛰기
  • 신체적 문제
  • 주의 집중하기
  • 자기 회의
  • 잘못된 통념
  • 주의 사항
  • CHAPTER 38 개발자의 자만심
  • CHAPTER 39 ‘일관성’과 ‘획일성’은 다르다
  • CHAPTER 40 사용자는 문제를 알려주고 개발자는 해결책을 만든다
  • 신뢰와 정보
  • 문제는 사용자에게서 나온다
  • CHAPTER 41 즉각적인 만족감 = 즉각적인 실패
  • 해결책은 장기적인 관점으로 찾아라
  • 소프트웨어 회사를 망가뜨리는 방법
  • CHAPTER 42 성공은 혁신이 아니라 실행에서 온다
  • CHAPTER 43 훌륭한 소프트웨어
  • 1. 사용자의 명령을 정확하게 따른다
  • 2. 사용자가 예상한 대로 작동한다
  • 3. 사용자의 의도 전달을 막지 않는다
  • 코드를 단순하게 만드는 것보다 탁월하게 만드는 게 더 중요하다. 이 둘은 상충되지 않는다
신간 소식 구독하기
뉴스레터에 가입하시고 이메일로 신간 소식을 받아 보세요.