2022.02.19 (SAT)
추천사 ~ 1장. 깨끗한 코드
- 소프트웨어는 80% 이상이 소위 "유지보수"다.
- 책임 있는 개발자라면 제품 수명 주기까지 고려해야 한다.
- 읽기 좋은 코드는 돌아가는 코드만큼이나 중요하다.
- 소프트웨어 설계에서 재작업은 가치를 가져온다.
- 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 바로 이것이 프로그래밍이다. 이렇게 명시한 결과가 바로 코드다. (p. 2)
- 나중은 결코 오지 않는다. (p. 4)
- 나는 우아하하고 효율적인 코드를 좋아한다. 깨끗한 코드는 한 가지를 제대로 한다. - Bjarne Stroustrup (p. 9)
- 깨끗한 코드는 세세한 사항까지 꼼꼼하게 처리하는 코드다. (p. 10)
- 깨끗한 코드는 단순하고 직접적이다. 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. - Grady Booch (p. 10)
- 깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. - Big Dave Thomas (p. 11)
- 깨끗한 코드는 주의 깊게 작성한 코드다. (p. 12)
- 간단한 코드는 아래와 같은 코드이다. - Ron Jeffries (p. 13)
- 모든 테스트를 통과한다.
- 중복이 없다.
- 시스템 내 모든 설계 아이디어를 표현한다.
- 클래스, 메서드, 함수 등을 최대한 줄인다.
- 중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기. 내게는 이 세 가지가 깨끗한 코드를 만드는 비결이다. - Ron Jeffries (p. 14)
- 보이스카우트 규칙 (p. 18-19)
- 잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다.
- "캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라"
- 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 충분하다.
- Agile Software Development: Principles, Patterns, and Practices(PPP)에서 이야기하는 원칙
SRP (The Single Responsibility Principle): 클래스에는 한 가지, 단 한 가지 변경 이유만 존재해야 한다.OCP (The Open Closed Principle): 클래스는 확장에 열려 있어야 하며, 변경에 닫혀 있어야 한다.LSP (The Liskov Substitution Principle): 상속받은 클래스는 기초 클래스를 대체할 수 있어야 한다.DIP (The Dependency Inversion Principle): 추상화에 의존해야 하며, 구체화에 의존하면 안 된다.ISP (The Interface Segregation Principle): 클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지한다.
"나중은 결코 오지 않는다"
- 이 말이 참 와닿았다. 지금까지 개발을 하며 '이 부분 개선할 수 있을 것 같은데... 바쁘니까 리펙터링은 나중에 하자' 라고 했던 순간들이 머릿속을 지나갔다.
- 미래의 나에게 맡기지 말고, 현재의 내가 해결해야겠다고 다짐했다. 변화는 오늘부터!
"깨끗한 코드는 한 가지를 제대로 한다."
- 내가 짠 함수는 한 가지를 제대로 할까? 하나의 함수에서 여러 가지 일을 하려고 한 것은 아닐까?
- 깨끗한 코드가 될 수 있도록 이 말을 명심해야겠다.
- PPP에서 이야기하는 원칙 5가지
SOLID 법칙으로 알고 있으나, 그 내용을 깊이 알지 못했던 것 같다.- 이 부분을 사례와 함께 좀 더 깊게 알아봐야겠다