찰쓰 코치님, 병현님, 효선님, 나 4명 참여

주제 1: 코드를 수정할 때 자신에게 던지는 질문

책 17챕터(냄새와 휴리스틱) 전체

발제자 제안

각자 코드를 수정할 때 속으로 던지게 되는 질문이 궁금합니다

예: 이 코드 라인이 꼭 필요할까?

굳이 이렇게 긴 코드를 작성할 필요가 있을까? (ex. for문 → 고차함수로 바꾸고 싶은 충동)

함수명이 함수 안에서 일어나는 모든 일을 포함하고 있나? (일부 지엽적인 내용만 포함하는 함수명은 아닌가?)

나눈 의견

의견 1:

• 주로 위에서부터 아래로 고민
  • 페이지 단위 → 컴포넌트 단위
• 컴포넌트(모듈) 단위 고민
  • 어떻게 나눌지
  • 어디까지 쪼갤지
• 모듈 단위 고민이 끝나면 함수, 변수(상태값) 고민
  • 함수의 위치
  • 이 함수가 이 컴포넌트에 있는 게 맞는지, 안 맞는다면 어디로 뺄지
• 이렇게 설계적 고민이 끝나고 나면
  • 함수명이 맞는지
  • 코드가 길다면 어떻게 분리시킬지
• 다 끝나면 마지막으로 테스트 친화적으로 어떻게 바꿀지
  • 함수가 너무 뭉쳐있으면 테스트가 힘들기 때문에

의견 2:

• 처음에 개발할 때 최적화, 컴포넌트 분리보다
  편하게 쓸 수 있고 + 기능과 화면이 구현되는 쪽으로 코드 작성 후
• 기존의 기능에 문제가 없게 어떻게 잘 쪼갤 수 있을까,
  재사용이 될 만한 로직이나 컴포넌트를 고려하여 리팩토링 진행

의견 3:

• 첫 번째는 중복된 부분이 있는지 살펴보고
  • 중복된 부분은 계속 써야 된다는 얘기이므로
  • 의존성 역전 또는 주입 가능한 구조로 바꿔봄
• 두 번째는 이를 통해 유지 보수를 잘 할 수 있는 것
  • 나중에 조금만 고쳐도 유지 보수가 되게끔
• 세 번째는 가독성이 좋을 수 있게
  • 다른 사람이 봐도 코드가 잘 이해가 되는지
  • 컨벤션을 준수하는지
  • 변수명이 잘 작성됐는지

의견 4:

• 가장 먼저 신경 쓰는 것은 가독성
  • 코드를 보고 바로 뭐 하는 건지 모르겠으면
  • 그 코드를 바로 고침
• 두 번째는 컴포넌트, 함수, 클래스가 너무 많은 걸 하고 있다면
  • 코드를 어떻게 분리시킬지 고민

의견 5:

• 가독성 관련하여 추상화 레벨 맞추기
  • 컴포넌트 레벨이 뒤죽박죽이면 추상화 레벨이 무너져 있을 수 있음
  • 추상화를 맞추면서 빼야 되는 컴포넌트인지 아닌지가 판별이 됨

의견 6:

• 백엔드에선 주로 객체지향 사용
• 클래스 간에 추상화가 있다면?
  • 프론트의 경우 클래스를 잘 쓰지 않음 (데이터 가공 외)
• 프론트에서 추상화 레벨이 있다면?
• JSX 작성 시 들여쓰기 사용
  • 들여쓰기가 3-4단계까지 간다면?
  • 추상화 레벨을 따로 분리시켜야 한다고 판단
• 토스에서 관련된 영상 있었음
  • 들여쓰기로 추상화 레벨 유사 여부를 판단

라이브러리 도입 질문

RxJS 도입을 제안
근데 다른 팀원들이 새로 공부를 해야 하는 상황
코드를 쓰면 분명 달라지는 것이 있는데 도입하는 게 좋을 지?

의견 1 (실제 시도):
예시 코드를 많이 넣은 PR을 업로드
그걸 보고 팀원들이 판단 (기존 것보다 변화가 많은지 아닌지)
⇒ 이렇게 해서 의견 수렴을 해야

의견 2:
팀원들의 거부감이 커도
내가 정말 필요하다 싶으면 밀어붙일 수도(?)

질문: 왜 이런 고민을 하게 되었나요?

좋은 코드란 것은 비용
어디까지 받아들여야 할지가 고민이었다

의견 1:
리팩토링 시 예를 들어
부동산 목록 페이지 생성

첨에 막 만들면서 별로로 짜다가
내가 코드를 수정하고 다른 사람에게 코드 리뷰를 받음

리팩토링이란 패턴 적용이 큰 작업임..
좋은 구조를 써도 그 구조를 모르는 사람이 보면
오히려 수용이 어렵지 않을까

대신에 많이 쓰는 범용적인 패턴이라면 그 패턴을 모르는 쪽이 공부를 해야 하지 않을까

의견 조율이 가장 중요
밀어붙일 땐 붙이되 싸움이 되면 안 됨

의견 2:
리액트 쿼리가 지금은 범용적인데
예전에 처음 도입 시 다른 팀원분이 회의적이었음
설득하기 위해 반 년 이상 걸림

해결한 방법- 예시 코드를 자주 올려드림
자주 이야기도 나누고 장점을 계속 설득
앞으로 프로젝트가 진행되면서 리액트 쿼리가 필요해질 거다..

이 분이 코드 관련해서 뭘 좋아하는지도 파악 (가독성, 퍼포먼스, 의존성 중에서..?)

리액트 쿼리가 안정화되어서 더 이상 타입 변경이 없어질 때가 올 거다 얘기해서 설득

의견 3:
RxJS ⇒ 함수형이 익숙하면 좋은데 아니면..?

(도입을 반대하는) 그 사람이 뭘 좋아하는지, 뭘 걱정하는지를 알고 그 방향으로 많이 설득해야 함

이걸 도입해서 뭐가 좋아지는지를 계속 설득

주제 2: 안 놀라운 코드

발제자 제안

각자 코드를 보고 놀라는 포인트와 놀라지 않는 포인트가 있다면 공유하면 좋겠다.

---

놀라운 코드보다는 당연해서 놀랍지 않은 코드가 더 좋은 코드라고 느낄 때가 많았다. 당연한 기능에 당연한 코드가 있는 것이 이상적이다.

우리가 코드를 보고 놀라는 경우는 좋은 경우보다 안좋은 경우가 많다.

내가 주로 놀라는 포인트는 "아니 왜 이걸 이렇게 해?", "이 코드가 왜 여깄지?", "대체 뭘 하려는 걸까?" 등이 있다.

놀라지 않는 코드는 "어디서 본 코드네", "이게 맞지", "읽기 쉽네" 같은 경우다.

개발 일을 시작할 때 쯤에는 내가 놀라운 코드를 만드는 걸 주력으로 했다면 점차 놀랍지 않은 코드를 만드는 개발자가 되어가려 노력하고 있어서 이러한 내용이 공감이 되었다.

결론은 당연히 해야 하는 것을 안 할 때(?) 놀라운 코드인 것 같다.

어떤 코드가 ‘당연한’ 건지 공유해보자.

나눈 의견

의견 1:
예를 들어
라이브러리는 보통 자기들만의 Best Practice 제공

근데 만약 이러한 Practice에 없는데도 코드적 동작은 똑같이 하는 경우
잘 안 쓰는 패턴인데..?! (놀라움)

의견 2:
예전에 협업할 때 한 사람이 다른 팀원들과 달리 JSX 안에서 함수를 호출해서 들어갈 JSX를 반환

프로젝트 내 코드 스타일 통일과 렌더링 시 반복되는 함수 호출을 이유로 들어 수정을 요청했으나 받아들여지지 않음

잘 안 쓰는 안티 패턴인 코드를 발견했을 때 놀라는 것 같다.

=> 내 의견이었는데 이야기 중 'JSX 안에서 함수 호출'이 과거에 쓰던 패턴이라는 것을 알게 됨

• 기술이 변화하면서 예전에 쓰던 패턴이 안티 패턴으로 바뀌는 경우가 있다
• 하지만 실제로 좋은 방법은 아니었음

의견 3:
오타가 있어서 다른 사람들이 이해를 못했는데
또 그 오타로 작성된 경우

또는 자료 구조를 잘못 썼을 때
자바스크립트를 쓰면서
배열을 쓰면 간단한 것을 굳이 객체로 처리한 경우

하나의 프로젝트 컨벤션과 동떨어진 코드도 있었는데
그거 보고 놀란 적도 있다

의견 4:
자료 구조를 구현한다 했을 때
마냥 스택을 구현한다 하면
pop, push 등의 당연한 기능들이 있는데
자료를 넣는 것만 있고 빼는 게 없는 경우
예를 들어 add 함수가 있으니 delete 함수도 있겠지?
하면서 밑에 내려갔는데 없는 경우

또는 팀의 암묵적인 규칙을 안 지킨 경우

공통점: 놀라운 코드는 일관성이 안 지켜진 코드인 것 같다.

의견 5:

• 예를 들어 forwardRef처럼 함수명 컴포넌트에 참조 값 만들어주는 기능 등이 유용한 경우가 있고 안 유용한 경우가 있는데
• 어떤 팀원이 함수형 컴포넌트를 모두 forwordRef로 감싸버림
  • 이 때문에 모든 자식 컴포넌트의 상태 값을 부모 컴포넌트에서 참조해버려서 모두 수정한 적이 있었음
  • 놀라운 코드였다

의견 6:

• 즉, 동작은 하는데 묘하게 다른 경우 (안티 패턴)
  • 시간이 지나서 예전 방식인데 지금은 아닌데..
• 코드를 읽을 때 별 거 아닌데도 뭔가 걸리는 느낌
• 사람마다 코딩 스타일이 다 다르기 때문에 가독성을 위해 팀 일관성(컨벤션)을 지키는 게 정말 중요
  • 그렇지 않으면 코드 리뷰나 기능 변경 시 피곤해짐

주제 3: 패턴이 어떻게 사용이 되었는지 분석

책 352페이지 코드 참고

발제자 제안

책에서 3가지 패턴이 사용되었다고 했는데 각 패턴이 코드의 어느 부분에 쓰였는지 같이 생각해보자.

쓰인 3가지 패턴: 싱글톤 패턴, 데코레이터 패턴, 추상 팩토리 패턴

나눈 의견

• 데코레이터 패턴 (커피머신)
  • 기본 객체 안에서 기본적으로 구현된 것들
  • 위에 선언하고 밑에서 점점 구체화함
• 싱글톤 패턴 → 프론트에서 쓰이기도 함

(배경 지식이 없어서 많이 못 적음)

주제 4: 조건을 캡슐화하면 좋을까?

발제자 제안

if(shouldBeDeleted(timer))는 if(timer.hasExpired() && !timer.isRecurrent())보다 좋다고 한다.

조건의 의도를 밝히는 함수명으로 표현된 (=캡슐화된) 조건이 더 가독성이 좋은가?

의견 1:
전자가 더 좋은 것 같다.
코드 ‘목적’이 나타나있고 구체적인 내용은 추상화로 숨김 (궁금하면 안에 들어가서 보는 것)

의견 2:
상황에 따라 다를 수 있다
추상화해서 간단하게 표현하면 모르면 들어가서 찾아봐야 함

함수로 감싸는 것도 좋지만
이렇게 감쌌을 때 의미를 더 찾기 힘든 경우가 있을 수 있고
제대로 된 함수명을 짓기 힘들 수도 있다.

의견 3:
상황에 따라 다르다는 것에 동감
단 위의 예시의 경우 조건의 구체적 내용이 어떻든 간에
전자의 경우 코드를 읽을 때 ‘timer가 삭제될 조건이야’ 이것만 보면 됨
상황에 따라 다르지만 위 예시의 경우는 전자가 더 나은 것 같다.