노마드코더 북클럽 클린코드 TIL 아홉번째

2022년 5월 11일 TIL

오늘 TIL 3줄 요약

• 클래스는 한가지에 대해서만 책임을 져야 한다.
• 클래스 응집력을 높히고, 응집력이 낮아지는 경우에는 클래스를 쪼개라.
• 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다.

오늘 읽은 범위

• 10장. 클래스

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

• 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다. (p.207)
• 클래스 이름은 해당 클래스 책임을 기술해야 한다. 실제로 작명은 클래스 크기를 줄이는 첫 번째 관문이다. 간결한 이름이 떠오르지 않는다면 필경 클래스 크기가 너무 커서 그렇다. 클래스 이름이 모호하다면 필경 클래스 책임이 너무 많아서다. (p.210)
• 단일 책임 원칙^{Single Responsibility Principle, SRP}은 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다. SRP는 '책임'이라는 개념을 정의하며 적절한 클래스 크기를 제시한다. 클래스는 책임, 즉 변경할 이유가 하나여야 한다는 의미다. (p.210)
• 소프트웨어를 돌아가게 만드는 활동과 소프트웨어를 깨끗하게 만드는 활동은 완전히 별개다. 우리들 대다수는 두뇌 용량에 한계가 있어 '깨끗하고 체계적인 소프트웨어'보다 '돌아가는 소프트웨어'에 초점을 맞춘다. 전적으로 올바른 태도다. 관심사를 분리하는 작업은 프로그램만이 아니라 프로그래밍 활동에서도 마찬가지로 중요하다. 문제는 우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다. '깨끗하고 체계적인 소프트웨어'라는 다음 관심사로 전환하지 않는다. (p.211)
• 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다. 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다. (p.212)
• 클래스가 응집력을 잃는다면 쪼개라! (p.214)
• OCP^{Open-Closed Principle}란 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다는 원칙이다. (p.223)

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

• 늘 알고 있는 내용이지만 실제 코드를 작업하다보면 놓치게 되는 내용인것 같다. 책 본문에도 나오는 내용과 일치하는 내용인데 '돌아가는 소프트웨어'가 완성된 시점에 작업이 마무리된다는 점이다. 이후에 다른 작업을 시작하고 다른 사람이 해당 작업에 손을 대면서 '깨끗하고 체계적인 소프트웨어'가 될 기회를 잃어간다.
• 계속 작업을 하다보면 내가 처음부터 구성한 클래스가 아닌 클래스를 수정하는 경우가 종종 생기는데, 이럴 때 많이 '깨끗하고 체계적인 소프트웨어'로 만들지 않는 것 같다. 버그 픽스나 간단한 추가 기능, 혹은 수정이라서 '돌아가는 소프트웨어'가 된 시점에서 정리를 하기위해 구조를 바꾸면 다른 버그들이 생기지 않을까 하는 걱정때문이다. 역시 테스트 코드를 만들어두고 동작을 헤치지 않으면서 구조를 바꿀 수 있도록 하는게 최우선인것 같다.