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

1. 학습 내용 요약

• 주석의 양면성

  • 주석이 많다

    • 그만큼 비즈니스 요구사항을 코드에 잘 녹이지 못함

    • 코드를 설명하는 주석을 쓰면, 주석에 의존 → 적절하지 않은 추상화 레벨을 갖게 되어 낮은 품질의 코드 생성

  • 그럼 언제써야 하나

    • 리팩토링 할 때 난관 중 하나는 히스토리를 전혀 알 수 없는 코드

    • 후대에 전해야 할 “의사 결정의 히스토리”를 코드로 표현 할 수 없을 때 주석으로 설명

    • 모든 표현 방법을 총동원해 코드에 의도를 녹여냈음에도 불구하고 전달해야 할 정보가 남았을 때 사용

  • 작성 주의점

    • 자주 변하는 정보는 최대한 지양

    • 관련 정책이 변하거나 코드가 변경되었다면, 주석도 잊지 않고 함께 업데이트

    • 주석이 없는 코드보다, 부정확한 주석이 달린 코드가 더 치명적

• 변수와 메서드 나열 순서

  • 변수는 사용하는 순서대로 나열

     

  • 객체 입장에서도 생각해보자

     

    • 외부 세계에 내가 어떤 기능을 제공할 수 있는지를 드러냄

    • 공개 메서드를 상단에 배치하는 것을 선호

      • 물론 정해진 답은 절대 아님!

    • 공개 메서드끼리도 기준을 배치, 비공개도 마찬가지

      • 상태 변경 >> 판별 ≥ 조회 메서드

      • 공통으로 사용하는 메서드인 경우 적당한 곳에 배치

• 패키지

  • 문맥으로써의 정보를 제공 가능

  • 패키지를 쪼개지 않으면 관리가 어려워짐

  • 패키지를 너무 잘게 쪼개도 관리가 어려워짐

  • 대규모 패키지 변경은 팀원과의 합의를 이룬 시점에 해야 함

• 오버엔지니어링

  • 필요한 적정 수준보다 더 높은 수준의 엔지니어링

  • Ex> 구현체가 하나인 인터페이스, 너무 이른 추상화

2. 미션 회고

Day 7 미션. 이번 미션은 스터디카페 좌석 예약 시스템 코드를 리팩토링하는 것이었다. 추상화, 일급컬렉션 등 앞선 강의에서 배웠던 개념들을 적용해 볼 수 있었다. 리팩토링 과정에서는 추상화레벨에 대해서 많이 생각하였다. 코드를 처음 보는 사람도 코드가 어떤 구조로 동작하고 있는지 메서드 이름 등으로 최대한 파악할 수 있도록 하였다. 그러나 이전에 경험이 많지 않았기에 추상화를 하는 과정은 쉽지 않았다. 레벨을 높이자니 내용이 날아가는 것 같고 그 반대는 오버엔지니어링이 아닐까하는 고민을 하게 되었다. 그래도 Order와 같은 새로운 도메인 개념 도출, 일급 컬렉션 등 여러 개념들을 십습해 볼 수 있는 기회였다.

3. KPT

• Keep

  • 미션을 해결하고 다른 사람들의 코드들을 보면서 여러 관점들을 학습하였다.

• Problem

  • 강의 후반부에서 다루는 개념들은 앞 부분에 비해서 난이도가 조금 더 있었던 것 같다.

• Try

  • 강의를 들으면서 정리해 놓은 내용들을 복습하는 시간을 가져야겠다.

  • 앞으로 코드를 짜면서 강의를 통해 배웠던 개념들을 잊지 않고 잘 적용해야겠다.

  ---

  4. 느낀점

  2주간의 클린코드 강의가 마무리되었다. 강의를 통하여 실습도 해보고, 다른 사람들의 코드도 계속해서 보다 보니 확실히 시작할 때보다 코드를 보는 눈이 생긴 게 체감이 되었다. 강의를 통해 여러 개념들을 공부하면서, 이전에 코드 짜던 사람들이 이러한 구조를 생각해 내는데 얼마나 많은 고민을 했을 까 생각해보게 되는 기회였다. 그리고 이 고민의 결과물들을 강의를 통해 한번에 정리하고 실습도 해볼 수 있어서 좋았다.

  어느 정도 프로그래밍을 해본 사람들이라면 강의에서 여러 고민의 흔적들을 느낄 수 있을 것이라 생각한다. 또한, 이제 막 코딩을 하고 있는 사람이라면 좋은 습관을 들이는데 좋을 것 같다. 개념을 배웠다고 해서 당장 내일 짜는 코드에서 바로 나타나지는 않듯, 한 번 공부해두면 클린코드를 생각해보는 시간이 모이고 모여 한층 더 성장한 개발자가 될 수 있을 것이다.