학습 내용 요약

읽기 좋은 코드가 되기 위해서 고려하여야 할 많은 사항들을 알 수 있었다.

공부한 내용들 중 가장 인상 깊었던 내용들을 나만의 방식으로 정리해보려고 하니 두 가지의 카테고리를 만들어 정리할 수 있었다.

1. 맥락(도메인 지식, 클래스)에 맞도록 하고, 필요하다면 의미를 부여한다

• 클래스에 속하는 것 자체로 의미를 내포하게 된다.

• 메서드의 모든 구성요소 (이름 뿐만 아니라 파라미터, 리턴타입도)를 고려해야 한다. 사용되는 관점을 특히 주의

• 매직 넘버, 매직 스트링 사용

• value object, 일급 컬렉션, enum의 공통점 → 의미 부여를 하고, 해당 의미를 잘 수행하도록(검증 등) 하는 공간(클래스)를 만드는 것

• 조건/행위의 분기가 반복 될 때는 이 또한 다형성을 활용할 수 있다.

   

  
  2. 읽는 이로 하여금 여러 번 생각하지 않아도 이해하기 쉽도록 한다.

• 누구나 바로 이해할 수 있는 네이밍하기, 팀의 약속 준수

• 추상화 레벨 맞추기

• 부정어 쓰지 않기

• 조건문은 early return을 통해 중첩된 사고를 하지 않도록 유도

• 중첩 그 자체로 표현이 되는 경우에는 그대로 두는 것이 유리할 때도 있다.

다음주엔..

솔직히 배웠던 내용들을 개념적으로는 이해를 한 것 같다. 특정 개념들은 감탄하며 재미있게 공부도 했었다. 이걸 코드 레벨에서 강의를 듣지 않고 다시 적용한다 생각하면 할 수 있을까 자신이 없다. 공부한 여러 고려 사항들을 적용해야 하는 부분을 발견하는 과정부터 연습을 다시 해봐야 실력이 늘 것으로 생각된다.

미션 수행 시 고려했던 사항

• early return

• 메서드 파라미터로 표현되는 내용 네이밍에 포함 시키지 않기

• order클래스가 내부적으로 로직을 수행하고 메세지를 전달한다고 가정

• 부정연산자 쓰지 않도록 고려한 네이밍

   

• 주어진 리턴 타입 준수하기

학습을 더 진행한 후

• 다시 보니 조건/행위의 분기가 반복되는 형태인 것 같다. 어쩌면 다형성을 활용할 수 있겠지만, 리턴 타입이 true/false

  단순 두개 여서 과할 수도 있겠다는 생각이 들었다.

• 리팩토링 하다보니 나도 모르게 검증 순서가 바뀌었는데, 이걸 함부로 고치면 기존 로직을 수정하지 못한다 가정 시 문제가 생길 수도 있다고 생각된다

  • 기존 : 주문 항목 검증 -> 사용자 정보 검증 -> 가격 검증

  • 수정 : 주문 항목 검증 -> 가격 검증 -> 사용자 정보 검증

• 로그를 하는 것을 추출하고 싶다는 생각이 들었음
  
  

  출처강의 : Readable Code: 읽기 좋은 코드를 작성하는 사고법
  https://www.inflearn.com/course/readable-code-%EC%9D%BD%EA%B8%B0%EC%A2%8B%EC%9D%80%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%EC%82%AC%EA%B3%A0%EB%B2%95/dashboard