모던 소프트웨어 엔지니어링

1부 | 소프트웨어 엔지니어링이란 무엇인가

1장 소프트웨어 공학의 정의와 역사
_공학이란 과학의 실용적인 응용 분야
_소프트웨어 공학 정의의 재구성
_다시, ‘소프트웨어 공학’
___전진, 앞으로
_소프트웨어 공학의 탄생
_패러다임의 전환
_정리

2장 소프트웨어 ‘공학’의 참뜻
_프로덕션은 우리의 문제가 아니다
_프로덕션이 아닌, 설계를 위한 공학
_실무자를 위한 공학의 정의
___공학 != 코드
_수공예 vs 공학
_‘수공예’의 한계
_정밀도와 확장성
_복잡성을 관리하자
_측정은 반복적이며 정확해야 한다
_공학, 창의성, 장인정신
_우리가 하는 일이 소프트웨어 공학이 아닌 이유
_소프트웨어 제작의 트레이드오프: 결합도가 핵심이다
_기술 발전의 진보라는 환상
_수공예에서 공학으로 가는 여정
_수공예만으로 충분하지 않다
_지금 우리가 고민해야 할 것들은 무엇일까
_정리

3장 소프트웨어 공학을 이해하기 위한 기초 사항
_새것만을 좇는 소프트웨어 업계
_(비기능적인 요소의) 측정은 중요하다
_안정성과 처리량으로 생산성을 높이자
_우리는 어느 분야의 전문가가 되어야 할까
___학습의 전문가
___복잡성을 관리하는 전문가
_정리

2부 | 소프트웨어 프로세스 개선을 위한 구체적인 실천 방안

4장 개선을 위한 반복
_반복적인 작업의 복잡미묘한 장점
_방어적인 설계 전략으로서의 반복
_계획이라는 유혹
___반복 작업의 실제
_정리

5장 피드백: 우수한 의사결정을 위한 필수 요소
_피드백의 중요성을 보여주는 구체적인 사례
_코딩 피드백
_통합 과정 피드백
_설계 피드백
_아키텍처 피드백
_피드백은 빠를수록 좋다
_제품 설계 피드백
_조직과 문화 피드백
_정리

6장 점진주의: 조금씩, 조금씩, 앞으로
_우주선 예시로 살펴보는 모듈성
_효율 높은 조직 구성을 위한 비법
_점진주의를 적용하기 위한 실천 도구
_변경의 부작용을 최소화하자
_점진적인 설계
_정리

7장 경험주의: 현실을 자각하자
_꿈은 높게, 그러나 발은 땅에
_실험과 경험은 분리해야 한다
_“저 이 버그 알아요!”
_자기기만은 우리의 적
_우리의 주장에 맞는 현실을 발명하자
_추측보다는 실험: 현실에 입각한 경험주의
_정리

8장 실험주의: 과학적 사고와 실천
_물리학자 파인먼에게 배우는 ‘실험주의’
___피드백: 실험주의를 위한 원칙 1
___가설: 실험주의를 위한 원칙 2
___측정: 실험주의를 위한 원칙 3
___변수 통제: 실험주의를 위한 원칙 4
_TDD에서 배우는 자동화 테스트
_테스트는 새로운 지식을 끌어내는 원천
_품질을 높이는 TDD 적용 사례 하나
_정리

3부 | 소프트웨어 복잡성 관리를 위한 기본 원칙 5가지

9장 모듈성: 분리와 재조합을 위한 기준
_모듈성의 전형적인 특징
_설계는 언제나 중요하다
_TDD의 교훈: 테스트가 어렵다면 설계도 문제다
_TDD로 모듈성을 강화하자
_REST API로 모듈성을 강화하자
_배포 파이프라인으로 모듈성을 강화하자
_모듈성의 규모는 크고 작음이 없다
_고성과 개발 조직의 특징: 모듈형
_정리

10장 응집성: 소프트웨어의 관련 요소들은 한곳에
_모듈성과 응집성: 설계의 기초
_응집성을 개선하기 위한 리팩토링 사례 하나
_DDD의 컨텍스트를 활용한 응집성 개선
_소프트웨어에서 ‘고성능’의 의미란
_결합도와 응집성 사이의 관계
_TDD로 응집성을 높이자
_응집성 있는 소프트웨어를 만들려면
_응집성이 부족할 때 치러야 할 대가
_개발 조직 관점에서 응집성의 중요성
_정리

11장 관심사 분리: 고품질 코드의 가장 중요한 속성
_의존성 주입
_본질적인 복잡성과 우발적인 복잡성을 분리하자
_DDD는 중요하다: 경계 컨텍스트를 활용한 하향식 관심사 분리
_테스트하기 쉬운 코드 = 관심사가 분리된 코드
_육각형 아키텍처: 포트와 어댑터
_포트와 어댑터는 언제 채택해야 할까
_API가 단순한 함수 호출이 아닌 이유
_TDD를 이용한 상향식 관심사 분리
_정리

12장 정보 은닉과 추상화: 우리의 적인가 친구인가
_정보 은닉과 추상화는 한몸이다
_‘큰 진흙탕’이 된 코드의 원인을 찾아서
___조직적이고 문화적인 문제
___기술적인 문제와 설계의 문제
___과도하게 공들인 공학의 우려
_추상화를 높이려면 테스트 코드부터 작성하라
_좋은 추상화가 핵심이다
_구멍 난 추상화
_세계 지도와 지하철 노선도의 비유로 배우는 추상화 기법
_이벤트 스토밍으로 추상화를 달성하자
_추상화된 우발적인 복잡성
_타사 시스템과 타사 코드를 격리하자
_추상화와 구상화 사이의 트레이드오프
_정리

13장 결합도: 소프트웨어 모듈 간의 상호 연관 수준
_너무 느슨해도 너무 긴밀해도 문제
_수직 확장을 위해서는 결합도가 필수
_마이크로서비스: 결합도를 분리하기 위한 효과적인 방법
_느슨한 결합도의 대가: 더 크고 많아진 코드
_결합도 모델은 한 종류만이 아니다
_어쨌든, 느슨한 결합이 긴밀한 결합보다는 좋다
_느슨한 결합과 관심사 분리의 상관관계
_DRY는 너무 단순하다
_느슨한 결합을 위한 비동기식 구현 방법
_느슨한 결합을 위한 설계
_강건한 결합도로 영원히 고통받는 대규모 조직
_정리

4부 | 소프트웨어 엔지니어를 위한 아이디어

14장 실제 사례로 되짚어 본 소프트웨어 공학
_소프트웨어 개발, 그 진실에 대하여
_테스트 가능한 코드 사례 1
_시스템은 반드시 측정 가능해야 한다
_테스트 가능한 코드 사례 2
_테스트: 시스템의 시작
_배포: 시스템의 완성
_피드백의 속도: 더 나은 품질과 결과물을 위한 필수 요소
_시스템의 전 과정에서 변수를 통제하자
_지속적인 배포를 잊지 말자
_소프트웨어에서 고려해야 할 질문들
_정리

15장 모던 소프트웨어 엔지니어가 되려면
_팀이나 조직도 복잡성의 관리대상임을 잊지 말자
_디지털적으로 파괴적인 조직을 추구하자
_결과 vs 메커니즘, 무엇이 더 중요할까
_소프트웨어 공학 원칙은 머신러닝 시스템에도 유효하다
_모던 소프트웨어 엔지니어링의 핵심 아이디어
_정리