🔖 오늘 읽은 범위 : 10장 클래스
🙂 책에서 기억하고 싶은 내용을 써보세요.
클래스는 작아야 한다.
클래스 이름은 해당 클래스 책임을 기술해야 한다. 간결한 이름이 떠오르지 않는다면 클래스 크기가 너무 커서 그렇다. 클래스 이름이 모호하다면 책임이 너무 많아서이다.
→ 단일 책임 원칙 (Single Responsibility Principle)
단일 책임 원칙은 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다.
클래스는 변경하기 쉬워야 한다.
요구사항은 변하기 마련이다. 따라서 코드도 변하기 마련이다.
새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다.
🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.
소프트웨어를 돌아가게 만드는 활동과 소프트웨어를 깨끗하게 만드는 활동은 완전히 별개다. 문제는 우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다. ‘깨끗하고 체계적인 소프트웨어'라는 다음 관심사로 전환하지 않는다.
회사에서 요구사항이 변하는 일은 흔하고, 그 요구사항에 맞춰서 열심히 짠 코드를 다시 수정하는 일도 흔하다. 프로젝트가 완성이 돼도 QA나 실제 서비스가 되었을 때 이슈 발생으로 코드를 수정하게 된다. 그동안 내가 변경하기 쉬운 코드를 짰는지 스스로를 돌아본다면, 일단 돌아가게 만드는 코드를 짜기에 급급했던 내 모습만이 떠오른다.
책에서는 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다고 말한다. 코드는 반드시 변경해야 할 때가 온다. 내일부터는 그때를 고려한, 변경하기 쉬운 코드를 짜기 위해 고민해보자.