해당 글은 인프런 박우빈 강사님의 「Readable Code: 읽기 좋은 코드를 작성하는 사고법」을 바탕으로 작성하였습니다.

2주차 요약

해당 블로그 글에는 강의에 등장하는 예시 코드는 작성하지 않고, 이론적인 부분만 요약해 작성합니다. 예시 코드는 우빈 님의 git repository에서 다운 받을 수 있습니다.

주석의 양면성 - 주석은 죄악이다 vs 어느 정도는 남겨라!

• 주석이 많다는 것은 비즈니스 요구사항을 코드에 잘 녹이지 못했다는 이야기

• 코드를 설명하는 주석 → 주석에 의존하는 코드!

• 이는 적절치 못한 추상화 레벨이라는 뜻!

좋은 주석이란?

• 리팩토링 시 히스토리를 전혀 알 수 없는 코드가 난관...

• 후대에 전할 의사 결정의 히스토리를 코드로 표현할 수 없을 때 주석으로 상세히 설명한다.

• 자주 변하는 정보는 지양해서 작성해야 한다.

• 만약 관련 정책이 변하거나 코드가 변경되면 주석도 업데이트해야 한다.

• 주석이 없는 것보다, 부정확한 주석이 더 치명적!!

• 우리가 가진 모든 표현 방법을 총동원해 코드에 의도를 녹이고, 전달해야 할 정보가 남았을 때 주석을 사용하는 것이다.

변수와 메서드 나열 순서

• 변수는 사용하는 순서대로 나열한다. ⇒ 인지적 경제성을 고려한 방식

• 메서드의 순서는 사용하는 객체 입장에서 생각하기

  • public 메서드에서 사용되는 private 메서드를 바로 하단에 배치 하기 vs public 메서드를 모아 상단에 배치하고 private 메서드는 모두 하단에 배치하기

     

  • 정답은 없지만, 코치님의 경우세는 공개 메서드를 상단에 배치하시는 것을 선호

  • 공개 메서드끼리도 기준을 갖고 배치한다!

    • 상태 변경(update 등) >> 판별(valid 등) >> 조회 순으로 배치

  • 비공개 메서드는 공개 메서드에서 언급된 순으로 배치

  • 공통 사용 메서드라면 가장 하단에 배치

패키지 정리

• 패키지는 문맥으로써 정보 제공이 가능

• 패키지를 쪼개지 않아도 너무 쪼개도 관리가 어렵다!

• 대규모 패키지 변경은 팀원과의 합의를 이룬 후에 해야 한다.

   

  ⇒충돌 방지!

• 처음 패키지 생성 시부터 잘 나눠놓자!

IDE에 도움 받기

• 포맷 정렬: ctrl + alt + l

• 코드 품질 향상: sonarlint 플러그인 사용하기

• 포맷 규칙: .editorconfig

  • 단, 포맷은 IDE에서 규정한 기본 포맷팅에 익숙해지는 것이 좋다!

  • 절대적인 것이 아닌, 지속적으로 개선/반영하기

미션 3과 중간 점검.

코치님께서 제공해준 프로젝트 폴더 중, 스터디 카페 시스템의 리팩토링이 과제였다.

git 링크

미션 3은 7장을 보지 않고 '순수 자기 힘으로 리팩토링 하기'가 목표였지만 강의를 보고 따라치는 것과 직접 이론을 적용하는 것은 큰 차이가 있었다. 5장까지가 제일 중요한 내용이라고 생각해 해당 파트까지는 최대한 적용해보고 싶었지만, 현실은 적절한 메서드 추출과 객체 분리부터가 고난이었다. 무엇보다도 아직도 일급 컬렉션을 어디서 어떻게 적용해야 할지 감이 안 와 갈 길이 정말 멀구나...! 라고 느껴졌다.

강의 마지막에 은탄환은 없다, 정답은 없다. 라고 말씀해주셨지만, 아무리 생각해도 복수 정답에도 가깝게 다가가지 못한 것 같다. 사고 방식을 전환하는 강의니, 간을 갖고 꾸준히 마주해야 할 문제인 것 같다.

중간 점검 라이브에서 다른 분들의 과제와 피드백해주신 걸 보고 많은 걸 또 얻어갔다.

• IDE에서 메서드 추출 시 자동으로 static 이 붙어버리니, 주의해야 한다.

• NPE 방지를 위해 null 대신 별도의 상수 값을 넣어 처리하는 방법

  
  등등...

   

1시간 30분에 못 미치는 시간이었음에도, 너무나 유익한 라이브였다. 깜짝 라이브를 꼭 진행해주셨으면 하는 작은(?) 바람이 생겨버렸다.🤣🤣