[도서] 클린코드

 

소프트웨어 개발에서 아키텍처가 중요하다. 
책임 있는 전문가라면 프로젝트를 시작할 때 생각하고 계획할 시간을 확보해야 한다.

 

함수를 어떻게 짜죠? 

처음에는 길고 복잡하다. 들여쓰기 단계도 많고 중복된 루프도 많다. 인수 목록도 아주 길다. 이름은 즉흥적이고 코드는 중복된다. 하지만 나는 그 서투른 코드를 빠짐없이 테스트하는 단위 케이스도 만든다.

그런 다음 나는 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다. 메서드를 줄이고 순서를 바꾼다. 때로는 전체 클래스를 쪼개기도 한다. 이 와중에도 코드는 항상 단위 테스트를 통과한다.

최종적으로 이 장에서 설명한 규칙을 따르는 함수가 얻어진다. 처음부터 탁 짜내지 않는다. 그게 가능한 사람은 없으리라

 

대가(master) 프로그래머는 시스템을 (구현할) 프로그램이 아니라 (풀어갈) 이야기로 여긴다. 
프로그래밍 언어라는 수단을 사용해 좀 더 풍부하고 좀 더 표현력이 강한 언어를 만들어 이야기를 풀어간다. 

 

코드만이 자기가 하는 일을 진실되게 말한다. 코드만이 정확한 정보를 제공하는 유일한 출처다. 그러므로 우리는 주석을 가능한 줄이도록 꾸준히 노력해야 한다.

 

단순한 설계 규칙 네가지 
1. 모든 테스트를 실행한다.
2. 중복을 없앤다.
3. 프로그래머 의도를 표현한다.
4. 클래스와 메서드 수를 최소화한다.

 

TPM(Total Productive Management)의 5S 철학 

1. 정리 또는 정렬 (Seiri)
적절한 명명법 등과 같은 방법을 사용해 무엇이 어디에 있는지 알아야 한다.
2. 정돈 또는 단정함 (Seiton)
코드는 누구나 예상하는 위치에 있어야 한다.
3. 청소 또는 정리 (Seiso)
과거 이력이나 미래 바람을 기억한 주석 또는 주석으로 처리한 코드는 제거하기 바란다.
4. 청결 또는 표준화 (Seiketsu)
그룹 내에서 일반적인 구현 스타일과 기법을 표준화한다.
5. 생활화 또는 규율 (Shutsuke)
관례를 따르고, 자기 작품을 자주 돌아보고, 기꺼이 변경한다.

 

---

 

약 3년간 백엔드 개발 업무를 위주로 진행하면서 느낀점이 있다. 개발은 어렵지 않다. 개발을 하기 전 데이터 구조를 어떻게 짜야 하는지, 어떤 이벤트가 필요한지, 나중에 확장할 때 문제가 없을지 등 이러한 고민을 토대로 데이터를 설계하는 일이 더 어렵고 머리 아프다는 것을 깨닫게 되었다.

 

클린코드가 왜 개발자 필독도서인지 알거 같다. 책에서 말하는 핵심은 결국 TPM의 5S 철학을 지켜 코딩하자 이다. 머리로는 이미 알고 있으나 이를 코드에 적용시키는 것은 쉽지 않은 일인거 같다. 책을 읽고 난 후 레포지토리에 쌓여만 가고 있는 내 코드를 다시 한번 돌아보게 되었고, 책의 내용을 토대로 계속해서 리팩토링해 나갈 예정이다.

 

코드로 말하는 개발자가 되고 싶다.

 

 

 

고상한 통찰을 끝냈으니 이제 내 책상이나 치우러 가야겠다.