오늘 TIL 3줄 요약

• 클래스는 작아야 한다.

• 단일 책임을 가지는 클래스를 만들기가 어렵다 ㅠㅠ

• 프로그램이 돌아가면 끝났다고 생각하지 말고 ' 깨끗하고 체계적인 소프트 웨어'라는 관삼사로 전환하자.

TIL (Today I Learned) 날짜

2022. 03. 08

오늘 읽은 범위

10장. 클래스

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

• 프로그램은 신문 기사처럼 읽힌다 (p. 172)

• 클래스를 만들 때 첫번째 규칙은 크기다. 클래스는 작아야 한다. (p. 172)

• 클래스 이름은 해당 클래스 책임을 기술해야 한다. 실제로 작명은 클래스 크기를 줄이는 첫 번째 관문이다. 간결한 이름이 떠오르지 않는다면 필경 클래스 크기가 너무 커서 그렇다. 클래스 이름이 모호하다면 필경 클래스 책임이 너무 많아서다. (p. 175)

• 책임, 즉 변경할 이유를 파악하려 애쓰다 보면 코드를 추상화하기도 쉬워진다. (p. 176)

• 우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다. ‘깨끗하고 체계적인 소프트웨어' 라는 다음 관심사로 전환하지 않는다. 프로그램으로 되돌아가 만능 클래스를 단일 책임 클래스 여럿으로 분리하는 대신 다음 문제로 넘어가버린다. (p. 176)

• 클래스는 인스턴스 변수 수가 작아야 한다. (p. 177)

• 응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개준다. (p. 178)

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

1. 책을 읽으면서 제일 변화하고 싶은 것이 바로 클래스이다. 지금도 하나의 클래스가 여러 책임을 가지고 있고 책임이 많은 만큼 크기도 크다.
   하지만 변경하기 쉽지 않은 것 또한 클래스다.
   기존에 이미 많은 의존성이 존재하고 책임을 나누기 위해 분리를 하면 다시 해당 클래스를 참조해야 해서 순환 참조 에러가 발생하기도 한다.
   목표가 있다면 해당 챕터를 잘 읽고 클래스를 SRP에 따라 분리하는 것이 목표이다.

2. 이번 챕터에서 공감되는 부분은 프로그램이 잘 돌아가면 일이 끝났다고 생각하는 부분이다.
   실제로 프로젝트가 잘 끝나게 되면 그 코드는 잊혀지기 마련이다.. 프로젝트를 하면서 ‘나중에 해야지’ ‘우선 프로젝트를 끝내야지' 라는 생각으로 마냥 돌아가는 코드, 일단 동작하는 코드를 짜왔고, 프로젝트가 끝나는 순간 미뤄왔던 일들은 나중으로 생각했던 자신이 부끄러워진다.
   이런 코드가 쌓이다 보니 결국 책임이 많아지는 클래스가 생기는 걸 보면서 리팩토링을 해야 한다는 생각이 든다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 이미 레거시에 존재하는 비대해진 클래스를 어떻게 잘 쪼개고 운영에 문제없이 반영할 수 있을까?

오늘 읽은 다른사람의 TIL

https://nomadcoders.co/community/thread/3436

• 큰서랍 보다 작은서랍 여러곳에 넣는것이 효율적이라.... (👍 )