인프런 워밍업 클럽 백엔드 2주차 후기

2주차 후기

강의를 듣고 발자국 남기는걸 까먹어서 부랴부랴 남긴다 ㅎㅎ..😅

1주차에 이어서 남은 리팩토링 강의를 들으면서 강사님께서 남겨주신 리팩토링 연습문제를 풀어보았다.

인프런의 스타강사 영한님의 명언 "백문이 불여일타"를 기억하기에 모든 강의를 열심히 따라 치다가, 이번엔 스스로 문제풀이를 해보려고 하니 생각보다 어려웠다.

정리한 강의 내용을 쥐어짜며, 어떻게든 내 나름대로 추상화와 코드정리를 해본 후 강사님과 비교해보았다.

나와 비슷하게 하신 점을 볼 때는 뿌듯했고, 내가 미처 생각치 못한 방식으로 리팩터링을 하실 때는 감탄을 금치 못했다.

강의 너머 우빈님께 정말 많은 것을 배워볼 수 있는 기회였다.

그리고 정말 코드에선 추상이라는 개념은 중요한 것 같다. 동등한 추상 레벨을 맞추거나, 메시지 이름을 통해서 "아 이거는 이런 역할을 하겠구나" 의미를 파악할 수 있는 점들이 중요함을 느꼈다. 하지만 또 모든 것을 추상해버리려는 오버 엔지니어링도 주의해야겠다. 이런 경각심을 배우며 실전에서도 조심하며 해볼 수 있도록 해야겠다.

이제 남은 테스트 코드 강의를 들으며 더 정진해야겠다!

아래는 강의를 정리한 내용

섹션6 - 리팩토링 연습

문제: 스터디 카페 이용권 선택 시스템

• 사용자는 시간권, 주단위 이용권, 1인 고정석 중 선택할 수 있음

  • 시간권: 2, 4, 6, 8, 10, 12시간

  • 주권: 1, 2, 3, 4, 12주

  • 고정석: 4주, 12주

• 추가금액을 내면 사물함도 사용할 수 있는데, 고정석인 경우만 선택 가능함

• 선택한 이용권, 사물함 여부에 따른 최종 금액을 계산해준다.

• 오픈 이벤트로 2주권 이상 10%, 12주권 15% 할인을 진행중임

리팩토링 포인트

• 추상화 레벨

• 객체로 묶어볼만한 것은 없는지

• 객체지향 패러다임에 맞게 객체들이 상호 협력하고 있는지

• SRP: 책임에 따라 응집도 있게 객체가 잘 나뉘어져 있는지

• DIP: 의존관계 역전을 적용할만한 곳은 없는지

• 일급 컬렉션

리팩토링(2) - 객체의 책임과 응집도

• IO 통합

• 일급 컬렉션

• display()의 책임

• Order 객체

리팩토링(3) - 관점의 차이로 달라지는 추상화

• FileHandler를 바라보는 관점

• 헥사고날 아키텍처 - 포트와 어댑터

  • 포트: 인터페이스: 규격만 맞으면 꽂을 수 있는 플러그 같은 스펙

  • 어댑터: 포트에 맞는 구현체

섹션7 - 기억하면 좋은 조언들

1. 능동적 읽기

• 복잡하거나 엉망인 코드를 읽고 이해하려 할 때, 리팩토링하면서 읽기

  • 공백으로 단락 구분하기

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

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

• 우리에게는 언제든 돌아갈 수 있는 git reset —hard가 있다.

• 핵심 목표는 우리의 도메인 지식을 늘리는 것. 그리고 이전 작성자의 의도를 파악하는 것

2. 오버 엔지니어링

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

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

    • 인터페이스 형태가 아키텍처 이해에 도움을 주거나, 근시일 내에 구현체가 추가될 가능성이 높다면 OK

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

    • 코드 탐색에 영향을 줌. 애플리케이션이 비대해 짐

  • EX) 너무 이른 추상화

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

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

3. 은탄환은 없다

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

   

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

• 실무: 2가지 사이의 줄다리기

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

  • 대부분의 회사는 돈을 벌고 성장해야 하고, 시장에서 빠르게 살아남는 것이 목표임

  • 이런 경우에도, 클린 코드를 추구하지 말라는 것이 아니라, 미래 시점에 잘 고치도록 할 수 있는 코드 센스가 필요함

  • 결국은, 클린 코드의 사고법을 기반으로 결정하는 것

     

기술부채: 당장 직면한 문제를 적정한 기술을 도입하지 못하고 단순하게 해결하고 미래에 미뤄두는 것

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

  • EX) 당장 급하게 배포 나가야 하는데, 동료에게 style 관련된 리뷰를 주고 고치도록 강요하는 사람

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

  • 적정 수준을 알기 위해, 때로는 극단적으로 시도해보자 (오버엔지니어링도 해보면서 적정 수준이 무엇일지 겪어보기)