Portfolio

💡

09.05까지 각자가 생각한 컨벤션 리스트업 및 방향성 공유 정리 후 동영, 나영 멘토님들께 여쭤보고 정리해서 09.06에 공유

현재 코드 상태 컨벤션 리팩터링 방향 방향성 컴포넌트 구조 폴더 별 리팩터링 해야 되는 것 원칙 참고할 만한 리팩터링 링크 멘토님 코멘트

현재 코드 상태

GitHub - prgrms-web-devcourse/Team_04_SFam_FE

Contribute to prgrms-web-devcourse/Team_04_SFam_FE development by creating an account on GitHub.

https://github.com/prgrms-web-devcourse/Team_04_SFam_FE

컨벤션

📊

코딩 컨벤션

리팩터링 방향

방향성

코드 리팩터링과 리스트럭처링을 구분하자

지금은 리스트럭처링이 먼저 필요하다고 생각한다

⇒ 컨벤션 적용, 컴포넌트 구조 설계 등

책에서는 TDD 기반의 리팩터링을 소개하고 있고 가장 대표적인 방식이기도 하다

이에 대해 생각만해보는 것도 좋을 것 같다

TDD에 대한 생각

적용을 해본 결과 의미있는 테스트케이스를 작성하지는 못했다

깊게 공부 못하고 하면 document 존재 여부, ToBe 찬반 여부 등 굉장히 얕게 짜게 됐다

공식문서를 보고 적용을 하기가 굉장히 어려웠다

4주동안 공부하고 적용을 할 수 있을까에 대해 의문이 살짝 든다

한숨만 나오는 테스트 코드(보여드리기 창피한 수준의 테스트 코드 링크)

마틴 파울러의 리팩터링 2판 책을 기반으로 우리 프로젝트에 적용할 수 있는 것을 적용해보자

컴포넌트 구조

관심사 분리를 최대한으로 해보자

분리 방법은 Hook 을 최대한 활용해보자

컴포넌트 자체 분리도 가능하다 ⇒ 너무 무의미한 분리는 오히려 좋지 않을 것 같다

폴더 별 리팩터링 해야 되는 것

리팩토링 이슈들

components

Template 폴더를 하나 만들자.
사실 상 파일 분리와 코드 수정 전부 있어야 함
컴포넌트의 의미가 있도록 추상화
마틴 파울러 리팩토링을 적용해 볼 것

constants

상수 정의할 수 있는 것은 따로 뺄 것

hooks

useAxios hook 개발할 수 있다면 개발

interface

API 타입 재사용되는 게 많고 타입 겹치는 것 수정
타입 겹치는 것 통일

pages

코딩 컨벤션 통일
파일 안에서 함수 형식 통일
[User, Team]form 형식으로 컴포넌트로 사용하는 것(템플릿으로 컴포넌트에 만들어 둔 것)과 파일 자체(pages 폴더)에 놓는 것 통일
states 초기값
조건부 렌더링 코드 손볼 것
태그 명칭 변경, 동일하게 사용하는 코드 통일
validation check하는 것 코드를 분리

recoil

styles

common 스타일 코드 수정
Text 사용 방식(common.ts)

types

원칙

리팩터링도 기능 구현과 마찬가지로 PR 단위를 작게 가져가야 한다

리팩터링 2판 책의 핵심인 기능과 UI에는 전혀 변화가 없어야 한다

참고할 만한 리팩터링 링크

리팩터링 1 - Refactoring 1

리팩터링할 코드 영역을 꼼꼼하게 검사해줄 테스트 코드들부터 마련해야 한다. 테스트를 작성하는 데 시간이 좀 걸리지만, 신경 써서 만들어두면 디버깅 시간이 줄어서 전체 작업 시간은 오히려 단축된다. 한 가지를 수정할 때마다 테스트하면, 오류가 생기더라도 변경 폭이 작기 때문에 살펴볼 범위도 좁아서 문제를 찾고 해결하기가 훨씬 쉽다. 조금씩 변경하고 매번 테스트하는 것은 리팩터링 절차의 핵심이다.

https://sungjk.github.io/2021/03/20/refactoring-01.html

리팩터링 2 - Refactoring 2

함수 구성과 이름 짓기는 가장 기본적인 저수준 리팩터링이다. 그런데 일단 함수를 만들고 나면 다시 고수준 모듈로 묶어야 한다. 변수가 주변 코드를 리팩터링하는 데 방해가 되면 인라인하는 것이 좋다. 이름이 좋으면 함수의 구현 코드를 살펴볼 필요 없이 호출문만 보고도 무슨 일을 하는지 파악할 수 있다. 먼저 변경 사항을 살펴보고 함수 선언과 호출문들을 단번에 고칠 수 있을지 가늠해본다.

https://sungjk.github.io/2021/03/31/refactoring-02.html

[영상 후기] 리팩토링의 작업 흐름 - 마틴 파울러

TDD 리팩토링: 가장 일반적인 리팩토링이다. (1) 테스트를 만들고 (2) 성공시키고 (3) 리팩토링한다. 테스트가 먼저 필요하다. 리팩토링을 할 때 실수하지 않기 위해서다. 기능 개발과 리팩토링은 분리해서 작업한다. 기능 개발과 리팩토링 작업을 빠르게 오갈 수 있지만, 자신이 어떤 작업을 하고 있는지 알고 있어야 한다. 쓰레기 줍기 리팩토링(Litter-Pickup Refactoring): 이상하거나 더러운(yuck) 코드를 발견했을 때 고친다.

https://mytory.net/2020/12/29/workflows-of-refactoring.html

개발자의 애질리티

이 글은 토스페이먼츠에 입사하신, 혹은 입사를 고려 중인 개발자분들을 위해 작성된 글입니다. 애자일하게 일한다는 것은 어떠한 의미일까요? 한 시간을 일하면 한 시간 만큼의 가치를 만들어 내는 방식이 아닐까 합니다. 예를 들어, 동작하는 함수를 구현하거나 난해한 개념을 이해하는 식으로요. 과거에는 프로젝트 진행 초기부터 분석과 설계에 많은 시간을 투자했습니다.

https://toss.tech/article/dev-agility

멘토님 코멘트

동영 멘토님

개발에는 정해진 답이 있는 게 아니기 때문에 이렇게 해도 될까?가 고민이라면 한번 시도해보고 나서 회고를 해보는 것도 좋다고 생각합니다.

우선 리팩터링을 진행한다고 하면 먼저 처음부터 다시 세팅을 하는 게 나을지, 기존 프로젝트를 베이스로 수정해나가는 게 나을지 고민해봐야 할 것 같습니다.

처음부터 세팅한다는 말이 기존 프로젝트를 다 버린다는 뜻은 아니고, 기존 프로젝트는 남겨두고 설계와 세팅을 다시 잡은 뒤 기존 프로젝트에서 활용할 수 있는 컴포넌트 등을 마이그레이션하는 식으로 진행한다는 뜻입니다.

e.g. Yarn Classic(v1) => Yarn Berry(v2+), AngularJS => Angular

위에서 말한 방식을 급진적 리팩터링이라고 한다면, 기존의 프로젝트를 바탕으로 고쳐나가는 방식은 점진적 리팩터링이라고 말할 수 있을 것 같습니다. (실제로 통용되는 용어는 아니고 제가 붙인 말입니다.)

e.g. React v16.8+ Class Component => Function Component

어떤 방식으로 진행할지는 투입하는 노력 대비 얻을 수 있는 효과에 대해서 전적으로 메인테이너들이 종합적으로 검토를 해봐야 하는 부분입니다.

우선 큰 방향이 정해졌다면 여러 케이스를 고려해서 구체적인 플랜을 세워볼 수 있습니다.

리팩터링 방식

급진적

개발/빌드 도구 세팅
아키텍처 재설계
마이그레이션 시점
...

점진적

구조 변경
모듈(api, 컴포넌트, 전역 상태) 우선 순위
모듈 내 우선 순위
...

기존에 작성된 테스트가 있는지

테스트를 만들지 않고 작업을 개시할 건지
테스트가 없는 상태에서 정상 작동을 어떻게 보장할 건지
테스트를 추가하고 리팩터링을 시작할 건지
테스트 범위(컴포넌트, API 등)는 어디까지 감당할 건지
테스트 방법(유닛, 통합, E2E)은 어떻게 진행할 건지
테스트 수준(커버리지)은 어느 정도로 잡을 건지

제 의견으로는 테스트가 유의미한 영향(긍정적인 도움)을 주지 않을 것 같다면 아예 빼버리는 게 낫다고 생각하지만, 점진적인 리팩터링을 진행할 예정이라면 Cypress 등의 E2E 테스팅 도구를 활용해 사용자 관점에서 유저 시나리오를 정의하는 방식은 적용해볼 수 있을 것 같습니다.

나영 멘토님

말씀하신 리팩토링을 다 하시려면 시간이 많이 투입되어야할거같습니다.

목표 세우기 ⭐

아무래도 장기목표는 면접시 해당 프로젝트를 제출할 용도 이게지요?
장기목표를 위한 단기목표들을 세우셔서 우선순위 높은 것 + 점진적으로 리팩토링 하시는 것을 추천드립니다. 위의 내용들을 전부 하시기에는 시간상 부담스러우실수도 있어요
레포 확인해보니, 아래와 같이 잡으면 좋을거같네요!

1차 목표: 코드를 읽기 쉽게 만든다.
2차 목표: 테스트를 추가하여 엣지케이스를 잡는다.
3차 목표: DX를 챙긴다.

코드를 읽기 쉽게 만든다.

디렉토리 구조 정리!: 협업할 때 모두가 이해하기 쉬운 리즈너블한 구조였냐

/컴포넌트: 위에서 댓글드린대로 도메인과 관련없는 컴포넌트는 공용 컴포넌트 구분하기
/리코일: 도메인별로 구분하기 (atoms.ts가 아닌 user.ts, …)
…

함수 리팩토링: 복잡도를 낮추고, 리더블하게 구현하였냐 (feat 테스터블한 환경 만들기)

복잡도가 높은 곳 (함수 하나에 역할이 너무 많은 부분) 리팩토링

중첩 if문이 많은 곳

순수 함수로 분리하여 재사용가능성 있는 함수 만들기

변수명, 함수명 지금보다 더 명시적으로

테스트를 추가하여 엣지케이스를 잡는다.

테스터블한 환경을 만든다.

최대한 테스트가 가능하도록 순수함수화

재사용도 높은 컴포넌트 형태로 리팩토링하여야 합니다.

테스트를 추가하여 엣지케이스를 잡는다.

테스트는 util테스트 부터 하시고, ui 테스트를 하시는것을 추천합니다!

테스트는 작은 함수 테스트

테스트 케이스 작성하는 연습도 하실 수 있습니다.

위 테스트가 마무리되면, UI 테스트를 하시는 것을 추천드립니다.

이 다음에! TDD로 할만한 것을 하시는것을 추천드립니다.!

DX를 챙긴다.

2번까지 했는데도 더 하고싶다! 할때 하시는 것을 추천드립니다

문서화) storybook을 만들어서 비개발자가 확인가능하도록 따로 배포해 둔다.

문서화) 도메인 복잡도가 높은 곳에 주석을 추가한다.

컨벤션 리스트업 및 리팩터링 방향