회고

이번 2주차는 클린 코드를 대하는 마음 가짐에 대한 강의가 주를 이루었다. 클린 코드를 접한 후의 나는, 마치 연금술사들이 금을 갈망하는 것과 같은, 절대적인 방향을 찾은 것과 같은 기분에 고취해 있었다. 이번 강의들은 그런 나의 확신이 그릇된 것임을 바로잡아 주는 느낌을 받았다.

특히 무엇이든 극단적으로 시도해보라는 말씀은 의미가 큰 것 같다. 나는 그동안 어떤 작업을 하면서 고민을 과도하게 한 나머지 코딩에 걸리는 시간이 과도하게 늘어나는 경향이 있었다. 이를 고칠 수 있는 방법을 찾은 것 같다.

강의 내용 요약

주석의 양면성

• 주석에는 두가지 의견이 있다

  • 주석은 죄악이다!

    • 주석이란 코드로 표현할 수 있는 내용을 대체하는 것

    • 코드를 설명하는 주석을 쓸 경우, 코드가 아닌 주석에 의존할 수 있다

    • 주석에 의존한 코드를 작성할 경우 적절하지 않은 추상화 레벨을 가진, 낮은 품질의 코드가 발생할 수 있다

  • 주석은 필수이다!

    • 리팩토링할 때의 가장 큰 난관은

      • 히스토리를 전혀 알 수 없는 코드

      • 작성 의도를 전혀 파악할 수 없는 코드

    • "의사 결정의 히스토리"를 도저히 코드로 표현할 수 없을 때, 주석으로 상세히 설명

  • 주석 작성 팁

    • 자주 변하는 정보는 가급적 주석을 작성하지 않는다

      • 주석을 남기는 순간 주석에도 버전이 생긴다

      • 코드 변경에 따라 주석도 자주 관리하게 된다

        • 유지보수성이 낮아진다

  • 좋은 주석이란?

    • 코드를 통해 최대한 표현했음에도 전달하지 못한 정보가 남았을 때 사용하는 주석

변수와 메서드의 나열 순서

• 변수

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

  • 인지적 경제성을 고려한다

• 메서드

  • 공개 메서드끼리도 기준을 가지고 배치하는 것이 좋다

  • 중요도 순, 종류별로 그룹화하여 배치한다

• 중요한 것은, 나열 순서로도 의도와 정보를 전달할 수 있다는 것이다

패키지 나누기

• 패키지는 문맥으로써의 정보를 제공한다

  • 패키지명으로 명시함으로써 클래스명에서 중복되는 내용을 제거할 수 있다.

• 패키지 분리 시 유의점

  • 패키지를 충분히 쪼개지 않을 경우 유지보수성이 하락할 수 있다

  • 반대로 패키지를 과도하게 쪼갤 경우 유지보수성이 하락할 수 있다

  • 공통으로 사용하는 클래스들의 패키지 분리 혹은 패키지명 변경은 충돌을 야기한다

    • 본인만 변경하고 있는 부분이라면 상관 없지만 보통 실무에서는 하나의 프로젝트를 여러 사람이 관리한다.

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

  • 패키지 구조는 초기 프로젝트 설정 때 최대한 나눠놓는다

    • 초기 프로젝트 설정 이후에는 패키지 변경이 어려워진다

능동적 읽기

• 복잡하고 엉망인 코드를 읽고 이해해야 할 때, 리팩토링을 하며 읽는 것도 좋은 방법이다

  • 공백으로 단락 구분하기

  • 메서드와 객체로 추상화 해보기

  • 이해한 내용을 주석으로 표기하며 읽기

• 리팩토링하다 뭔가 돌이키기 힘들 정도로 잘못 됐다면?

  • git reset --hard 를 통해 원복이 가능하다

• 리팩토링의 핵심 목표

  • 도메인 이해도 늘리기

  • 작성자의 의도 파악하기

오버 엔지니어링

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

• 오지 않을 미래를 대비한 필요 이상의 리소스 투자

  • ex.

    • 구현체가 하나인 인터페이스

      • 구현체를 수정할 때마다 인터페이스도 수정해야 한다

      • 코드 탐색에 영향을 준다

      • 애플리케이션이 비대해진다

      • 필요한 경우

        • 인터페이스 형태가 아키텍처 이해에 도움을 줄 경우

        • 근시일 내에 구현체가 추가될 가능성이 높을 경우

    • 너무 이른 추상화

      • 정보가 숨겨지기 때문에 복잡도가 높아진다

      • 후대 개발자들이 선대의 의도를 파악하기 어렵다

은탄환은 없다!

• 만능 해결사 같은 기술은 없다

• 체스 게임을 구현하려 할 경우 하드 코딩과 객체 지향 코딩 중 어느 쪽이 적절할까?

  • 체스는 500년 동안 변하지 않았다

    • 유지보수성이 필요하지 않은 상황에서 객체 지향 코딩을 할 이유가 있는가?

• 클린 코드도 은탄환이 아니다

• 실무에서는 두 가지 사이의 줄다리기를 하게 된다

  • 지속 가능한 소프트웨어의 품질 vs 기술 부채를 안고 가는 빠른 결과물

  • 회사의 사정에 의해 소프트웨어의 품질을 챙기지 못할 수도 있다

    • 다만 때로는 기술 부채를 안고 가더라도 확장 가능한 형태로 결과물을 만들기 위해 노력해야 한다

• 모든 기술과 방법론은 적정 기술의 범위 내에서 사용되어야 한다

  • 지금 우리에게 필요한, 적절한 기술이 무엇인지 파악해야 한다

  • 오래된, 구식의 기술이라도 때로는 우리 팀에게 적절할 수 있다.

• 도구라는 것은, 일단 그것을 한계까지 사용할 줄 아는 사람이 그것을 사용하지 말아야 할 때도 아는 법

  • 적정 수준을 알기 위해, 때로는 극단적으로 시도해보자

    • 극단적으로 추상화도 해보고

    • 극단적으로 오버 엔지니어링도 해보자

• 항상 모든 상황에서 클린 코드를 추구하는 것이 좋은 자세는 아니다

미션

Day 7

미션 내용

[섹션 7. 리팩토링 연습]의 "연습 프로젝트 소개" 강의를 보고, "스터디 카페 이용권 선택 시스템" 프로젝트에서 지금까지 배운 내용을 기반으로 리팩토링을 진행해 봅시다.

나의 답

https://github.com/hagd0520/readable-code/tree/c6a2e747055c1ab00a9a90a87143c1c19bb72602

후기

지금까지 들어온 강사님의 수업은 쉽지 않았습니다. 거의 처음 접하는 클린 코드의 구체적인 예시를 따라하다보면 정신이 쏙 빠지는 느낌을 받았습니다. 그래도 애써 진도를 따라잡으면서 그래도 나름 클린 코드에 익숙해져있다고 뿌듯함을 느껴왔지만 이번 미션을 통해 완전히 무너졌습니다.

중복 몇개를 제거하고 나서, 인터페이스 몇개 분리하고 나니 막상 어떤 식으로 리팩토링을 해야 할지 감이 안 잡히네요. 우선 제출은 했지만 못내 아쉬운 마음입니다. 강의를 다시 들으면서 복습해야겠습니다.