들어가기 전에
제조업 메타포
- 스크럼, 애자일 → 제품을 신속하게 시장에 출시하는 방법론을 강조
- 개발자들은 제품 백로그나 사용자 스토리를 토대로 제품을 생산한다고 생각하고, 느낀다.
- 소프트웨어는 80% 이상의 활동이 유지보수다.
TPM(Total Productive Management)
- 1951년 일본 제조업에서 등장한 품질 관리론
- TPM은 생산이 아니라 유지보수에 초점을 맞춘다.
- TPM의 5S 원칙은 후에 린(Lean)의 토대가 된다.
TPM의 5S 원칙
- Seiri - 정리, 조직, 정렬
- 작업 공간에서 무엇이 어디에 있는지 알아야 한다.
- 적절한 명명법을 사용한다.
- Seiton - 정돈, 단정함, 체계화
- 작업 공간 내의 물건은 모두 제자리에 있어야 한다.
- 코드는 누구나 예상하는 위치에 있어야 한다.
- Seiso - 청소, 정리, 광내기
- 작업 공간에서 불필요한 것들은 치운다.
- 과거 이력이나 미래에 할 일을 기록한 주석, 주석 처리된 코드는 제거한다.
- Seiketsu - 청결, 표준화
- 작업 공간을 청소하는 방식에 그룹이 동의한다.
- 일관적인 구현 스타일과 기법을 따른다.
- Shutsuke - 생활화, 규율
- 정해진 관례를 숙지하고, 따르고, 습관화한다.
기억하기
- 책임 있는 개발자라면 제품 생명주기까지 고려해야 한다.
- 읽기 좋은 코드는 돌아가는 코드만큼 중요하다.
- 코드가 곧 설계다.
- 지속적인 개선과 보살핌은 중요하다.
- 디테일에 몰두하는 태도는 탁월함을 추구하는 모든 노력에서 공통으로 발견된다.
- 품질은 사심 없이 기울이는 무수한 관심에서 얻어진다.
장인 정신 익히기
- 이론: 필요한 원칙, 패턴, 기법, 경험이라는 지식을 습득한다.
- 실전: 열심히 일하고 연습해 지식을 몸과 마음으로 체득한다.
수련하라
- 깨끗한 코드를 작성하는 방법은 배우기 어렵다.
- 단순히 원칙과 패턴을 안다고 깨끗한 코드가 나오지는 않는다.
- 고생을 해야 한다. 스스로 연습하고 실패도 맛봐야 한다.
- 코드를 분석하고 이해하며 코드에 가하는 변경과 이유를 납득해야 한다.
깨끗한 코드
코드는 사라지지 않는다.
- 코드는 요구사항을 상세히 표현하는 언어다.
- 코드의 도움 없이 요구사항을 상세하게 표현하는 것은 불가능하다.
- 프로그래밍은 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업이고, 그 결과가 바로 코드다.
- 어떤 언어를 사용하든 코드는 기계가 이해하고 실행할 정도로 엄밀하고 정확하고 상세하고 정형화되어야 한다.
- 제대로 명시한 요구사항은 코드만큼 정형적이며 테스트 케이스로 사용해도 좋다.
나쁜 코드로 치르는 대가
- 나쁜 코드는 개발 속도를 크게 떨어뜨린다.
- 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다.
- 시간을 들여 꺠끗한 코드를 만드는 노력이 비용을 절감하는 방법이자 전문가로서 살아남는 길이다.
좋은 코드를 사수하라
- 일정에 쫓기더라도 대다수 관리자는 좋은 코드를 원한다.
- 좋은 코드를 사수하는 일은 프로그래머의 책임이다.
- 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.
- 일정과 기한을 맞추는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.
깨끗한 코드의 특징
심미성과 가독성이 좋다
- 우아하여 보기에 즐겁다.
- 가독성이 좋아 잘 쓴 문장처럼 읽힌다.
- 다른 사람이 읽기 쉽고, 고치기 쉽다.
- 의미 있는 이름을 사용하여 표현력이 높다.
설계자의 의도가 잘 드러난다
- 단순하고 직접적이다.
- 명쾌한 추상화와 단순한 제어문으로 이루어진다.
- 짐작한 대로 동작하므로 놀랄 일이 없다.
- 시스템 내 모든 설계 아이디어를 표현한다.
한 가지를 제대로 한다
- 논리가 간단하여 버그가 숨어들지 못한다.
- 특정 목적을 달성하는 방법을 하나만 제공한다.
꼼꼼하다
- 오류 처리, 메모리 누수, 레이스 컨디션 등 세세한 사항까지 꼼꼼히 처리한다.
- 오류를 명백한 전략에 의거해 철저히 처리한다.
- 누군가 시간을 들여 주의 깊게 짰다는 느낌을 주며, 고치려고 살펴봐도 딱히 손 댈 곳이 없다.
군더더기가 없다
- 중복이 없으며, 반드시 필요한 내용만을 담고 있다.
- 클래스, 메서드, 함수 등이 명확하며 최소이다.
- 의존성이 최소이며 각 의존성을 명확히 정의한다.
성능이 좋다
- 이미 성능이 효율적으로 최적화되어 있어 원칙 없는 최적화의 유혹을 불러일으키지 않는다.
테스트하기 쉽다
- 단위 테스트 케이스와 인수 테스트 케이스가 존재한다.
- 모든 테스트를 통과한다.
프로그래머들이 대충 넘어가는 부분들
- 오류 처리
- 메모리 누수
- 레이스 컨디션
- 일관성 없는 명명법
보이스카우트 규칙
- 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
- 코드는 시간이 지나도 언제나 깨끗하게 유지해야 한다.
- 체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다.
PPP(Principles, Patterns, and Practice) - SOLID 원칙
- SRP(Single Responsibility Principle): 클래스에는 단 한 가지 변경 이유만 존재해야 한다.
- OCP(Open Closed Principle): 클래스는 확장에는 열려 있고, 변경에는 닫혀 있어야 한다.
- LSP(Liskov Substituion Principle): 자식 클래스는 부모 클래스를 대체할 수 있어야 한다.
- DIP(Dependency Inversion Principle): 구체화에 의존하지 말고, 추상화에 의존해야 한다.
- ISP(Interface Segregation Principle): 클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지해야 한다.
@kmong