Day 6. 리팩토링: 코드 다듬기

주석의 양면성

좋은 주석

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

변수와 메서드의 나열 순서

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

패키지 나누기

• 패키지는, 문맥으로써의 정보를 제공할 수 있다.

• 처음 만들 때부터 잘 고민해서 패키지를 나눠놓는 것이 제일 좋다.

   

  IDE의 도움 받기

• 코드 포맷 정렬 : Option + Cmd + L | Ctrl + Alt + L

• 코드 품질 : Sonarlint (https://www.sonarsource.com/products/sonarlint)

• 포맷 규칙 : .editorconfig (https://editorconfig.org/)

Day 7. 클린코드 리팩토링 실습

미션 - 스터디 카페 이용권 선택 시스템 리팩토링

 https://github.com/japygo/readable-code/tree/mission6-1

회고

• 강의를 통해 배운 것을 생각하며 리팩토링하려 했지만 생각보다 쉽지 않다.

• 변수명, 메서드명이 잘 떠오르지 않았다.

   

Day 8. 리팩토링 연습 | 기억하면 좋은 조언들

리팩토링 연습

추상화 레벨

• 중복 제거, 메서드 추출

• 객체에 메세지 보내기

   

  객체의 책임과 응집도

• IO 통합

• 일급 컬렉션

• display()의 책임

• Order 객체

관점의 차이로 달라지는 추상화

• FileHandler를 바라보는 관점

   

  • 어떤 데이터를 필요로 하는가

  • 데이터를 어디로부터 어떻게 가져올 것인가

기억하면 좋은 조언들

능동적 읽기

• 능동적으로 리팩토링하면서 물고 뜯고 맛보면서 읽기

오버 엔지니어링

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

• 오버 엔지니어링을 경계하고 꼭 필요한 곳에 알맞게 사용

은탄환은 없다

한번은 개발자와 체스를 구현하는 방법에 대해 논의한 적이 있습니다.
나는 그가 어떻게 할 것인지 물었습니다.
객체 지향 프로그래밍에 정통한 그는 “인터페이스와 클래스를 사용한다”고 답했습니다.
나는 “하드코딩하는 편이 더 쉽지 않을까요?” 라고 운을 띄웠습니다.
그는 “물론이죠. 하지만 잘 유지보수 하시기 바랍니다.” 라고 말하면서 내가 농담을 한 것처럼 씩 웃었습니다.
“체스는 지난 500년 동안 변하지 않았습니다.”
내 말에 그의 눈이 커졌습니다.

- 크리스찬 클라우젠, 「파이브 라인스 오브 코드」, 위키북스, 2023, 302p

• 항상 정답인 기술은 없다.

마무리하며

전문가는 언제나 탑다운(top-down)으로 깔끔하게 생각할 것이다.
라는 미신.

- 김창준, 「함께 자라기」, 인사이트, 2018, 153p

• 추상과 구체를 넘나드는 것

Day 9. 중간 점검

• 헥사고날 아키텍쳐 - 만들면서 배우는 클린 아키텍처(https://www.yes24.com/Product/Goods/105138479)

• 클린 코드, 테스트 코드, 더 나아가서 소프트웨어 개발은 팀 게임, 혼자는 한계가 있다.

• 아주 작은 단위, 메서드 분리부터 시작 -> 책임을 정의하고 객체로도 분리

• 잘 만들어진 라이브러리, 프레임워크에서 배우는 것도 좋은 방법 - https://github.com/spring-projects

• 파라미터 수가 많을 경우 의도에 따라 줄일 수 있으면 좋다.

• 도메인따라 다르지만 NPE 방지를 위해 empty 객체 반환

회고

• 1주차도 그렇고 2주차때도 꼭 강의를 들으려 하면 일이 생긴다.

• 일을 다니며 하는건 쉽지 않다.

• 그동안 궁금하고 답답한 부분을 시원하게 긁을 수 있는 강의라서 매우 좋았다.

출처

• https://inf.run/zgJk5

   

• https://inf.run/kHiWM