강의 : Readable Code: 읽기 좋은 코드를 작성하는 사고법

섹션 6 코드 다듬기

주석의 양면성

• 코드는 유지보수 되나 주석은 유지보수 되지 않는다

• 코드의 설명을 위한 주석은 좋지 않다

• 주석을 사용한다면 코드로 파악이 힘든 내용들을 담도록 하자

  • 히스토리 파악이 힘든 코드에 대한 히스토리 설명

패키지 나누기

• 의미있는 단위로 패키지를 나누자

   

섹션 7 리팩토링 연습

• 코드 레벨에서의 추상화가 아닌 도메인을 잘 이해하여 높은 레벨로 추상화하여 가독성을 높이자

   

• ex) 고정석이 아니면 return

   

  • 관점을 고정석이 아닌 경우라 생각하면 doesNotFixed라 메소드 이름을 짓게 된다

  • 고정석이 아니라는 건 락커를 사용할 수 없다는 의미로 더 높은 추상화 레벨로 메소드 이름을 지으면 canNotUserLocker로 메소드 이름을 지을 수 있다

• 클래스명에 대한 추상화

   

  • ex) 파일을 읽어 어떠한 정보를 가져오는 클래스

  • 클라이언트 입장에선 어떤 정보를 가져오는지에 대한 관심만 있음

  • 정보를 가져오는 수단에 대한 관심을 지우고 어떠한 정보를 가져올지에 포커스를 맞추다

  • ~Provider, ~Generator 등의 이름을 활용하도록 하자

  • 더 좋은 네이밍은 스프링에서 찾아보도록 하자

섹션 8 기억하면 좋은 조언들

• 객체지향이 무조건 좋은 건 아니다

• 과한 객체 지향은 오버엔지니어링이 될 수 있고 가독성을 해친다

• 요구사항에 따라 절차적 프로그래밍이 어울릴 수 있고 객체지향 프로그래밍이 어울릴 수 있다

• 내가 짠 코드에 근거를 가지고 상황에 맞게 리팩토링 기법이나 객체 지향을 잘 적용하도록 하자