출처 : Readable Code: 읽기 좋은 코드를 작성하는 사고법 - 박우빈

1. 학습 내용 요약

• 이름 짓기

  • 추상적 사고를 기반으로 함

  • 단수와 복수를 구분

  • 이름 줄이지 않기

  • 은어/방언 사용하지 않기

  • 좋은 코드를 보고 습득하기

     

• 메서드 이름

  • 메서드 구현에 대한 부분을 추상화해서 중요한 내용을 가지고 있어야 함

  • 파라미터와 연결지어 더 풍부한 의미를 전달 할 수 있음

     

• 파라미터

  • 타입, 개수, 순서를 통해 의미 전달

     

• 반환타입

  • 메서드 시그니처에 납득이 가는, 적절한 타입의 반환 값

  • void 대신 충분히 반환할 만한 값이 있는지

    • 반환 값이 있다면 테스트에 용이

       

• 추상화 레벨

  • 하나의 세계 안에서는 추상화 레벨이 동등해야 함

  • 읽는 사람으로 하여금 자연스럽게 읽히도록 함

   

• Early return

  • 일찍 리턴 할 수 있는 경우에는 빠르게 리턴하자!

     

• Depth 줄이기

  • 무조건 1 depth로 만들어라 → X

  • 추상화를 통한 사고 과정의 depth를 줄이는 것이 중요

     

• 사용한 변수는 가깝게 선언하기

   

• 공백라인

  • 복잡한 로직의 의미 단위를 나누어 보여줌으로써 읽는 사람에게 추가적인 정보 전달

     

• 부정어

  • ! 를 통하여 조건을 뒤집을 경우 사고 과정이 두 번 일어나게 됨

  • 한 번에 이해할 수 있게 메서드명 자체에 부정어구를 녹이는 방법을 사용

  • 부정어구를 쓰지 않아도 되는 상황인지도 체크

     

• 예외 처리

  • 예외가 발생할 가능성 낮추기

  • 사용자에게 보여줄 예외 vs 개발자가 보고 처리해야 할 예외

     

   

• 새로운 객체를 만들 때 주의할 점

  • 1개의 관심사로 명확하게 책임이 정의되었는지

  • 생성자, 정적 팩토리 메서드에서 유효성 검증이 가능

  • setter 사용 자제

    • 데이터는 불변이 최고

    • 만약 변경해야하는 경우 set~ 보다는 update~와 같이 의도를 드러내는 네이밍 이용

  • getter 사용도 자제

    • 반드시 필요한 순간에만 생성

    • 객체에게 공손하게 물어보자!

  • 필드의 수는 적을수록 좋음

    • 불필요한 데이터가 많을 수록 복잡도와 대응할 변화가 증가

• 상속보다는 조합을 사용하자

  • 상속은 수정이 어렵다 → 부모와 자식의 결합도가 높음

  • 조합과 인터페이스를 활용하는 것이 유연한 구조

    • 상속을 통한 코드의 중복 제거가 주는 이점보다, 중복이 생기더라도 유연한 구조 설계가 주는 이점이 더 큼

     

• Value Object

  • 도메인의 어떤 개념을 추상화하여 표현한 값 객체

  • 값으로 취급 받기 위해선 불변성, 동등성, 유효성 검증 등을 보장해야 함

     

• VO vs Entity

  • Entity는 식별자가 존재, 식별자가 아닌 필드의 값이 달라도, 식별자가 같으면 동등한 객체로 취급

  • VO는 식별자 없이, 내부이 모든 값이 다 같아야 동등한 객체로 취급

     

     

• 일급 컬렉션

  • 필드가 반드시 하나!

  • 컬렉션을 추상화하며 의미를 담을 수 있고, 가공 로직의 보금자리가 생김

  • getter로 컬렉션을 반환할 일이 생긴다면, 외부 조작을 피하기 위해 꼭 새로운 컬렉션으로 만들어서 반환

     

     

• Enum

  • 상수의 집합, 상수와 관련된 로직을 담을 수 있는 공간

  • 특정 도메인 개념에 대해 종류와 개념을 명시적으로 표현 가능

     

     

2. 미션 회고

미션 1. 추상과 구체의 예시를 적어보는 과제였다. 나는 '호흡'이라는 추상 개념을 구체화 해보기로 했다. 우리 몸이 구체적으로 어떻게 호흡이라는 과정이 일어나는 지 서술해보았다. 미션을 통해 추상화 레벨에 대해 생각해보고, 추상화가 얼마나 중요한지 느끼게 되는 계기가 되었다.

미션2. 섹션 3에서 배운 내용을 기반으로 읽기 좋은 코드로 리팩토링하는 과제였다. 강의 이전에 문제 코드를 미리 봤었는데, 강의를 보고 문제 코드를 다시 보니 처음에 캐치하지 못했던 개선점들이 보이는 게 신기했다. 문제는 문제점을 우선 파악하고, 개선 방안을 생각해본 뒤, 코드로 직접 수정하며 해결하였다.

미션 풀이 과정은 노션에 따로 정리하였다 https://www.notion.so/Day-4-1145cf1d569e80139747c0781f448f43

3. KPT

• Keep

  • 코드를 보고 이번에는 어떤 방식으로 리팩토링을 해야 할지 고민하면서 강의를 들었다

• Problem

  • 강의가 조금 밀리니 미션을 해결하는 과정에서 고민할 시간을 많이 가지지 못했다.

• Try

  • 강의를 마감일자에 맞추어서 급하게 듣는 것이 아닌 조금 여유를 가지고 듣는 것이 좋겠다.

  • 다른 분들이 제출한 코드들을 내 코드와 비교하는 시간을 가져야겠다.
    

    ---

4. 느낀점

이번 주는 잘못 들이고 있던 습관들을 고칠 수 있었다. 부정어, 줄임말 등 정말 많은 곳에서 실수를 하고 있었다. 예를 들어, 무언가 객체를 만들면 거의 조건 반사적으로 @Getter, @Setter를 적곤 했다. 이전에 Setter는 조심해서 사용해야 한다는 글을 본 적이 있어서 이제는 잘 사용하지 않지만 Getter는 거리낌 없이 사용했다. 강의를 보고 나니 Getter도 정말 최후에 생성해야하고, 객체에서 Getter로 변수를 꺼내다 쓰는 것이 아닌 요청하는 습관이 바람직 하다는 것을 알게 되었다.
돌아보면 당장 눈앞에 보이는 코드 짜기에 급급했지, 후대에 다른 개발자가 내 코드를 볼 것이라고 생각하고 코드를 짰던 기억은 정말 손에 꼽았던 것 같다. 이번 워밍업 클럽을 통해 Readable한 코드에 대해 항상 고민하는 개발자가 되었으면 좋겠다.