[일정] 241004

[JengYoung]

모임 예정 일자

24.10.03

이슈 주제

📖 켄트 벡의 Tidy First? - 더 나은 소프트웨어 설계를 위한 32가지 코드 정리법 (2024)

체크리스트

• [x] 각자 이야기하고 싶은 것들을 갖고와서, 각 챕터마다 서로 논하기. (PR에서 써주기)
• [x] 기존의 발표: PR에서 해결?

구체적 일정

• 21시 30분
• 15장까지

발제문

8장 ~ 9장

• 상수와 변수의 명명법에 대한 기준
• 설명력이 있는 코드란 무엇일까?
• 코드정리, 동작변경, 리팩토링에 대한 커밋 메시지 type은 어떤게 적절할까요 ?
  • 코드정리 → ?
  • 동작변경 → feat
  • 리팩토링 → refactor

10장

• 명시적인 매개변수로 비구조화하는 방식이 좋은 걸까?

11장

관련 있는 코드를 뭉쳐두면 다양한 길로 나아갈 수 있습니다.

• 여기서 다양한 길이 무엇일까요?

12장

코드 정리와 리팩터링을 실행할 때 자동화 도구가 없으면 힘듭니다. 그렇기 때문에 되도록 자동 리팩터링을 제공하는 개발 도구를 추천합니다.

• 어떤 도구가 있을까요?

13장

• 하나의 더미로 묶는 기준과, 그 배경이 되는 경험을 이야기해보고 싶어요.
• 하나의 더미라는 부분은 사실 코드 정리보다는 리팩터링에 가까운 큰 작업이 아닐까요?

[JengYoung]

상수와 변수의 명명법에 대한 기준

정답은 없고,가치있다고 판단되는 기준들을 서로 열거함

• 응집도 있게 잘 묶어야 한다. (폴더 구조, 자료 구조)
  • 최대한 모듈 별로 나누는 것을 지향하되, 서로의 관계가 강하게 묶여 있다면 자료 구조를 객체로 해도 괜찮다.
  • 폴더별 분리에서 발생할 수 있는 휴먼 에러는, 최대한 자동화 툴이나 린트 등으로 강제할 수 있도록 팀간의 노력이 필요
• 코드를 더 깔끔하고 직관적으로 짜는 것
• 모든 것을 다 변수로 만들 필요는 없고, 항상 읽었을 때 자연스럽게 변수 / 상수화하기

TODO: 차후 상수 값을 더 잘 관리할 수 있는 방법을 고안해오기.

[JengYoung]

설명력이 있는 코드란 무엇일까?

배경

pages/posts/tidy-first/part1/chapter8/jengyoung.mdx

의견

• 표현식이 가장 중요하다.

표현식이 어떤 의미를 내포하는지부터 시작하여, 상수, 변수 등으로 하나하나씩 부족한 설명력을 덧댄다.

• 알고리즘으로 최적화한 경우 vs 팀원들끼리 잘 이해가 되는 경우

  • 성능상으로 필요한 경우: 알고리즘 최적화가 우선되어야 함.
  • 알고리즘이 짜여졌지만 공감대를 얻지 못할 정도로 짜여져있다면: 내부 구현을 몰라도 사용할 수 있게끔 추상화하기.

• 좋은 맥락을 형성하는 코드 짜임새

• 그 외(변수, 상수, 주석)

[JengYoung]

코드정리, 동작변경, 리팩토링에 대한 커밋 메시지 type은 어떤게 적절할까요 ?

• 코드정리 → ?
• 동작변경 → feat
• 리팩토링 → refactor

각 팀에 맞게 공감대가 형성되면 좋겠다!

• 재영: 그냥 다 refactor로 하고 싶어요. 왜냐하면, 쉽게 나눌 수 있는 범주가 없는 것 같아요...!
• 보성: 범주가 없어서 tidy를 추가해요! 왜냐하면, tidy를 통해서 리팩터링으로 이어지거나, 동작 변경으로 이어지기 때문이에요.
• 도현: 저도 refactor로 하고 싶어요. 특정 커밋이 하나 더 생기면 고민을 한 번 더 하게 될 것 같아요!

[JengYoung]

명시적인 매개변수로 비구조화하는 방식이 좋은 걸까?

• 객체 내부에서 다르게 관리해야 하는 경우에는 비구조화가 필요할 수 있음.
  • 필수값 / 옵셔너한 값을 나누는 등
• 다만 현실적인 사용법에서는 괴리감이 느껴지기는 함.
• 언어의 차이도 있지 않을까 싶음.

실용성에 있어 아쉬움이 다소 많았던 파트.

[JengYoung]

11장

관련 있는 코드를 뭉쳐두면 다양한 길로 나아갈 수 있습니다.

여기서 다양한 길이 무엇일까요?

• 관련있는 코드끼리 미리 묶어놓는다면, 그 다음에는 어떻게 정리해야할지 더 잘 보이게 된다.
• 이로 인해 컴포넌트, 훅, 헬퍼함수 등 다양한 방법으로 재사용성 높게, 응집도 있게 코드를 리팩터링할 수 있다.
• 뭉쳐 놓으면 헬퍼함수라던지, 주석이라던지, 다양한 방식으로 추후에 정리할 수 있다.

[JengYoung]

12장

코드 정리와 리팩터링을 실행할 때 자동화 도구가 없으면 힘듭니다. 그렇기 때문에 되도록 자동 리팩터링을 제공하는 개발 도구를 추천합니다.

• 자동화 도구에 대한 범주는 어느정도로 생각하시는지?
• 그렇다면 자동화 도구는 어떤 것들이 있는지?

자동화 도구에 대한 범주

• 린터
• 포맷터
• IDE에서 제공하는 기능들 (스니펫, Refactor, 익스텐션)
• Copilor
• Codemod
• CLI 라이브러리
• AI (chatGPT Canvas, ...)

번외 - 헬퍼함수를 만드는 것은 어느정도까지?

헬퍼 함수 추출 기준

• 상위 함수에서 추출하는 것(어떤 크기인지에 따라 다름)
  • 상위 함수에 대한 가독성을 줄 수 있다면 추출해도 좋다. (일단 같은 파일 내에서!)
  • 함수는 순수성을 지키는 것이 좋을까?
  • 지키는 것이 좋을 경우: 파일 구조를 분리했을 때, 더욱 읽히기가 좋은 코드. 즉 현재의 관심사에서 벗어난 코드는 순수함수로 별도로 분리해서 쓰는 것이 더욱 가독성 면에서 좋은 것 같다. (getServersideProps라던지)
  • 지키는 것이 좋지 않은 경우: 애초에 로직이 현재 코드에서 매우 강한 결합도를 가져야만 할 때에는 오히려 관심사가 분리되기 때문에 좋지 않을 수 있다.

[JengYoung]

13장

하나의 더미로 묶는 기준과, 그 배경이 되는 경험을 이야기해보고 싶어요.

하나의 더미라는 부분은 사실 코드 정리보다는 리팩터링에 가까운 큰 작업이 아닐까요?

TODO: 당장 논하기에는 생각보다 어려운 주제라, 추후에 이야기하는 것이 좋겠다.