[Book][Clean Code][TIL] 책 리뷰 09

Clean Code 클린코드 TIL(Today I Learned) 2022.03.09

📖 DAY 9

📝 오늘 읽은 범위

10장. 클래스

📝 책에서 기억하고 싶은 내용을 써보세요.

• 추상화 단계 : 정적 공개 상수 –> 정적 비공개 변수 –> 비공개 인스턴스 변수 –> 공개 함수 –> 비공개 함수(자신을 호출하는 공개 함수 직후) - 순차적으로 내려감 (p.172)
• 같은 패키지 안에서 테스트 코드가 함수를 호출하거나 변수를 사용해야 한다면 그 함수나 변수를 protected로 선언하거나 패키지 전체로 공개한다. 하지만 그 전에 비공개 상태를 유지할 온갖 방법을 강구한다.
• 클래스는 작아야 한다. 클래스가 맡은 책임으로 크기를 측정한다.
• 클래스 이름은 해당 클래스 책임을 기술해야 한다. (p.175)
• 단일 책임 원칙은 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다.
• 책임, 즉 변경할 이유를 파악하려 애쓰다 보면 코드를 추상화하기도 쉬워진다. (p.176)
• 소프트웨어를 돌아가게 만드는 활동과 소프트웨어를 꺠끗하게 만드는 활동은 완전히 별개다. ‘돌아가는 소프트웨어’도 올바른 태도이지만, 문제는 우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다. ‘깨끗하고 체계적인 소프트웨어’라는 다음 관심사로 전환하지 않는다.
• 규모가 어느 수준에 이르는 시스템은 논리가 많고도 복잡하다. 이런 복잡성을 다루려면 체계적인 정리가 필수다. (p.177)
• 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다. 작은 클래스는 각자 맡은 책임이 하나며, 변경한 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.
• 일반적으로 응집도가 가장 높은 클래스는 가능하지도 바람직하지도 않다. 그렇지만 우리는 응집도가 높은 클래스를 선호한다. 응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미기 때문이다.
• 응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개준다. (p.178)
• 클래스가 응집력을 잃는다면 쪼개라! (p.179)
• 리팩터링한 코드가 긴 세 가지 이유 (p.185)

  1. 리팩터링한 프로그램은 좀 더 길고 서술적인 변수 이름을 사용한다.
  2. 리팩터링한 프로그램은 코드에 주석을 추가하는 수단으로 함수 선언과 클래스 선언을 활용한다.
  3. 가독성을 높이고자 공백을 추가하고 형식을 맞추었다.

• 대다수 시스템은 지속적인 변경이 가해진다. 꺠끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.
• 테스트가 가능할 정도로 시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다. (p.190)

📝 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

• ‘돌아가는 소프트웨어’ 이후에 ‘깨끗하고 체계적인 소프트웨어’로 넘어가 코드를 돌아가는 것 뿐 아니라 누구나 이해하기 쉽도록 클래스 하나에 모든 기능을 넣지 않고 작은 클래스, 즉 각 책임마다 한 개씩 만들어 수정이 쉬운 깨끗한 시스템을 만들도록 노력해야 한다.
• 또한, 깨끗한 시스템으로 넘어갈 때, 테스트 코드를 작성하여 수정한 코드가 잘 작동하는지도 꼼꼼하게 체크해야 한다.

#코딩 #개발자 #노마드북클럽 #노개북 #clean_code