개요
코드 작성을 마무리한 후 오늘 ‘오늘 아주 잘했어!’라고 말할수 있는지.
많은 이가 찝찝한 기분으로 하루를 마무리한다.
조악한 품질은 피할 수 없다고, 빠른 속도를 위해 어쩔 수 없다고 느끼며, 너무 많은 이가 생산성과 품질이 반비례한다고 생각한다.
🧸 - 내 갈비뼈 한 120개는 부서진듯...
이 책에서는 훌륭하게 일하는 법, 일을 잘 해내는 법을 다루며
모든 프로그래머가 빠르게 일하고, 생선적이 되고, 매일 쓰는 코드에 자부심을 갖기 위해 알아야 하는 규율과 실천 방법을 설명한다.
장인 정신(Craftsmanship)
이 책에서는 비행기의 발전과, 프로그래밍의 발전을 비교하며 장인 정신에 대해 설명하고 있다.
두 기술의 진보는 갑작스러운 100~200년내에 진행되었다.
비행기의 발전
비행기의 발전은 부력의 발견, 엔진의 발명 등 여러 기술의 진보에 따라 비행기의 성능은 좋아졌다.
그럼에도 수 많은 사람이 비행기를 조종하며 목숨을 잃었고,
비행 기술의 발전으로 점차 안전하게 비행기를 만들고 띄우는 방법에 대해 배우게 되었다.
프로그래밍의 발전
인류는 숫자를 세기 위해 손가락, 나뭇가지 등을 사용했고, 기억 장치와 연산 장치의 발명을 하기 시작했다.
여러 개념들이 정리되고, 발전되어가며 새로운 기술을 사용한 기계장치들이 발명되었다.
지금보다 50년 전인 1970년대에 프로그래밍을 학습하고, 사용하는 사람들은 매우 적은수였다.
2000년대에 와서는 어마어마한 하드웨어의 발전이 있었고, 많은 프로그래머들이 양산되어 ‘프로그래머’로써 일하고 있다.
비교해보면
이 책에서는 2가지의 분야를 비교하며 물어본다.
비행 기술의 장인처럼, 항공 조종사들만큼 자기가 사용하는 기술을 깊이 이해하는 프로그래머를 양성했는지.
프로그래밍에 장인은 필요한것은 분명하나 현재 우리에게 장인은 있는것인지.
1부 - 규율(The Disciplines)
규율(規律) - 명사
規 - 법 규 / 律 - 규칙 률
질서를 유지하기 위하여 정해 놓은, 행위의 준칙이 되는 본보기.
책에서는 일련의 규칙들을 규율이라 표현하며, 두가지로 구성된다고 말한다.
본질적인 규칙
규율의 권위를 부여하는 규칙
애초에 규율이 존재하는 이유에 해당함
임의적인 규칙
형태와 실체를 부여하는 규칙
임의적인 부분 없이는 규율이 존재할 수 없음.
책에서는…
소프트웨어 장인 정신의 5가지 규율을 탐구한다.
읽다보면 거부감이 드는 규율이 있을것이다.
→ 규율의 본질적인 요소 때문인지, 임의적인 요소 때문인지 판단해 보길
→ 임의적인 요소 때문에 잘못된 판단을 하지 않도록 주의
→ 각 규율의 본질적인 요소를 보면 임의적인 형태는 중요한 것이 아니게 됨
익스트림 프로그래밍
익스트림 프로그래밍의 실천 방법을 보여주는 그림.
책에서 다루는 주제
- 테스트 주도 개발(Test-Driven Development - TDD)
- 리펙터링(Refactoring)
- 단순한 설계(Simple Design)
- 짝 프로그래밍(Pairing)
- 인수 테스트(Acceptance Test)
- 익스트림 프로그래밍의 비지니스 실천 방법 중 가장 기술적이고 엔지니어링에 초점을 둔 실천 방법.
위 5가지의 실천 방법이 소프트웨어 장인 정신의 기본 규율에 속한다고 말한다.
1. 테스트 주도 개발(TDD)
일 하는 방식을 초단위로 통제하는 규율.
핵심 규율이며, 테스트 주도 개발 없이 다른 규율은 지키기 어렵거나 지켜 봐야 의미가 없다.
핵심
- 작은 순환 주기를 따르고 테스트를 우선한다는 것.
- 모든 일에서 테스트가 우선
- 테스트를 먼저 쓰고 테스트를 먼저 정리
- 모든 활동에서 테스트가 먼저
- 모든 활동을 가장 작은 순환 주기로 쪼개는 것.
테스트 주도 개발의 목표는 전적으로 신뢰하는 테스트 묶음을 만드는 것.
- 테스트 묶음을 통과한 코드는 마음 편히 배포할 수 있어야 함.
테스트 주도 개발은 익히기 어렵지만 헤아릴 수 없는 가치가 있는 정교하고 복잡한 기술.
2. 리펙터링(Refactoring)
깨끗한 코드를 쓰도록 하는 규율.
테스트 주도 개발이 없다면 리펙터링은 어렵가나 아예 불가능할 수도 있음.
- 깨끗한 코드를 쓰는 것도 마찬가지로 어렵거나 불가능함.
리펙터링은 동작을 바꾸지 않으면서 형편없는 구조를 가진 코드를 더 나은 구조의 코드로 고치는 규율.
동작을 바꾸지 않는다는 점이 중요!!!
동작을 바꾸지 않는다는 게 보장되면 구조를 개선해도 ‘안전’하다고 보장할 수 있다.
개선사항이 동작에 영향을 주지 않는다고 어떻게 보장할 수 있나
→ 테스트 주도 개발로 만든 테스트가 있다면 가능.
리펙터링은 복잡한 규율임.
→ 형편없는 구조를 만드는 방법이 많다 보니 깨끗한 코드로 바꾸는 전략도 많은 탓.
3. 단순한 설계(Simple Design)
프로그램이나 시스템, 어플리케이션의 더 큰 구조에 잘 들어맞도록 단순하고 아주 작은 단위로 설계하는 규율
테스트 주도 개발이나 리펙터링과는 다르게 정의가 느슨한 규율.
→ 판단과 경험에 의존함.
단순한 설계를 잘할 수 있다면 시니어로써 한 단계 올라섰다는 첫 신호가 될 것.
4. 짝 프로그래밍(Pairing)
책에서는 공동 프로그래밍이라 표현한다.
소프트웨어 팀에서 함께 일하는 규율
짝 프로그래밍, 몹 프로그래밍, 코드 리뷰, 브레인 스토밍 같은 하부 규율이 포함되는 규율임.
부서에 상관없이 모든 팀원이 참여하여 지식을 공유하고, 일관성을 보장하며, 팀을 한 몸으로 작동하도록 묶는 주요 수단이다.
다른 규율에 비해 공동 프로그래밍은 제일 기술적이지도 않고 지시 사항도 제일 적다.
그럼에도 가장 중요할 수 있다.
→ 효과적인 팀을 꾸리는 일은 흔히 경험할 수 없고 소중한 일이다.
5. 인수 테스트(Acceptance Test)
소프트웨어 개발 팀을 사업과 묶어 주는 규율
시스템이 동작해야 하는 방식을 사업 목표로 명시함.
사업 부서는 인수 테스트를 쓰고 읽고 통과하는 것을 확인함으로써 소프트웨어가 무엇을 하는지,
그리고 사업 부서에 필요한 일을 하는지 알 수 있다.
추가 공부 (책에 언급은 되었으나, 설명되어있지 않은 내용.)
🧸 S.O.L.I.D 원칙 - 객체 지향 5대 원칙1. SRP(Single Responsibility Principle) - 단일 책임 원칙
→ 소프트웨어의 설계 부품(클래스, 함수 등)은 단 하나의 책임만을 가져야 한다.
2. OCP(Open-Closed Principle) - 개방-패쇄 원칙
→ 기존의 코드를 변경하지 않고(Closed) 기능을 수정하거나 추가할 수 있도록(Open) 설계해야 한다.
3. LSP(Liskov Substitution Principle) - 리스코프 치환 원칙
→ 자식 클래스는 부모 클래스에서 가능한 행위를 수행할 수 있어야 한다.
4. DIP(Dependency Inversion Principle) - 의존 역전 원칙
→ 의존 관계를 맺을 때, 변화하기 쉬운것 보단 변화하기 어려운 것에 의존해야 한다는 원칙.
5. ISP(Interface Segregation Principle) - 인터페이스 분리 원칙
→ 클라이언트는 자신이 사용하지 않는 메소드에 의존 관계를 맺으면 안된다.
