[원티드 프리온보딩 코스 5차 - 프론트엔드 ] week1-1. 2일차

<week 1-1.사전 과제 리팩토링 기간 2일차, 본격 코드 리팩토링 시작>

1. 리팩토링 방식
   discord 와 vscode live-share 기능을 사용하여 팀원이 모두 함께 리팩토링이 적용된 코드를 처음부터 작성.

2. 코드 작성 진행 순서
   1) 디렉토리 분류
   - 컴포넌트 : src/components
   - 각종 함수와 hooks : src/utils
   - 컴포넌트들을 렌더링할 페이지 : src/pages
   - 각종 스타일 관련 src/styles

   2) 스타일링은 styled-components를 활용, 디테일한 스타일은 우선 생략하고 기본 홈페이지인 LoginPage.jsx에 렌더링 할 컴포넌트들을 만들어서 레이아웃 구성.

   3) 로그인 페이지 관련 디테일한 스타일링 진행. 팀원들이 각자 작성하였던 스타일링을 가져와 적용하고 다른 팀원들의 의견 취합해가면서 수정.

   4) styled-components의 전역 스타일링 GlobalStyle에 프로젝트에 사용할 메인 컬러를 전역 변수로 선언하여 따로 import 하지 않고도 자유롭게 사용함.

   5) 위와 같은 순서로 MainPage.jsx 및 하위 컴포넌트들 작성+스타일링.

   6) json형식의 mock data를 가져오는 함수 getFeeds는 axios를 사용, 모듈 파일로 따로 분리.

   7) getFeeds()로 가져온 mock data를 렌더링할 Feed 컴포넌트에 뿌리고 image.onLoad() 사용하여 이미지 로딩시 컴포넌트 렌더링 성공한 것 까지 확인 후 금일 일정 마무리.

3. 협업 과정에서 발생한 이슈
   1) 디렉토리와 컴포넌트 분리- 팀원들이 디렉토리를 분류한 방법은 공통되게 1차적으로는 기능별로 분리하고 -> '같은 페이지에 렌더링되는 컴포넌트끼리 2차 분리', '컴포넌트 별로 전부 쪼갬', '더이상 쪼개지 않음' 등 다양했다. 서로의 스타일이 많이 달라 1차적으로 기능별 디렉토리 분류까지는 좋았지만 다음 단계에서 컴포넌트 분리를 어떻게 할지에 대해 의견 충돌이 생겨 결론에 도달하기까지가 가장 오래 걸린 부분이다. 서로 컴포넌트 분리에 대해 토론 하다가 크게 두가지 옵션으로 좁혀졌고, 각자 점심시간 겸 휴식시간에 생각을 정리하여 돌아가며 각자의 의견을 피력 -> 다수결로 정했다.
   2) 스타일링 방식 선택 -> styled-components 사용이 익숙하지 않은 팀원도 있었지만 프로젝트의 확장성을 생각하여 재사용 가능한 컴포넌트 제작을 위해 styled-components 라이브러리가 가장 적합하다는 의견 동조, 모르던 팀원분들도 코드 작성을 통해 해당 라이브러리를 접하고 싶다고 해서 사용하게 됨.
   3) 메인컬러 사용 방법 -> 이 부분도 팀원마다의 취향차이가 두드러지게 나타났으나 여러 팀원의 메인 컬러 사용 방식을 각각 비교하여 import 부분이 방대해지는 것도 막고, 변수로 편하게 가져다 쓸수 있는 전역 변수를 사용하기로 결정.
   4) image.onload 이벤트 핸들링 관련 -> FeedList라는 컴포넌트의 하위 컴포넌트인 Feed에 mock data를 뿌려 렌더링하는데, 이과정에서 Feed 컴포넌트에서 image.onload 속성을 사용하여 이미지가 로딩되면 Feed 컴포넌트가 렌더링되게 구현하였으나, 실제 웹사이트 실행시 이미지 로딩이 순차적으로 이루어지지 않아 첫번째 feed는 건너뛰고 두번째 feed가 먼저 렌더링 되는 현상이 보기에 좋지 않다고 판단 -> 상위 컴포넌트인 FeedList에 image.onload 속성을 적용해 FeedList 통째로 렌더링되게 변경 예정-?

4. 아직 진행 못한 부분

• 로그인 기능 구현, ref 사용한 리렌더링 최적화
• Localstorage 사용한 로그인 로그아웃
• 라우팅 페이지 이동 방식
• CommentForm 컴포넌트 댓글 등록 구현 방법 결정
• 커스텀 useInput hooks 라이브러리 사용 여부 결정 및 validation 함수 분리
• 스타일링 코드 전체적인 분위기 통일 + 미디어 쿼리 breakpoint 통일
• 변수명 통일
• readme 작성
• CommentForm 컴포넌트 Json-server 적용 여부 결정

5. 느낀점

• 온라인 팀 프로젝트를 위한 다양한 좋은 기능과 플랫폼들이 많이 존재한다.
• 리팩토링시 좀 더 효율적인 방법은 한 사람의 코드 혹은 하나의 완성된 코드를 기준으로 수정하는 방식이라고 느꼈다.(결과물에 비해 모두의 시간적, 체력적 소모가 심했다)
• 협업시 디렉토리 구조와 코드 규율정도만 정하여 분업 후, 완성된 코드를 리뷰하며 수정하고 의견을 교환하는 방식도 좋을 것 같다고 생각했다.

6. 협업하면서 새로 얻은 tip + 궁금한 부분 따로 찾아본 내용 정리

   html 목록 태그인 ul,ol tag 사용시 직계 자식은 li만 사용한다. li는 3개이상일때 사용하는 것이 베스트 _ https://velog.io/@samkong/HTML-Tags 글 인용
   (그 외 참고 사이트 : , https://okky.kr/article/1171779, https://library.gabia.com/contents/domain/4359/,
   https://ui.toast.com/fe-guide/ko_HTMLCSS)

   리액트 컴포넌트에서 props 전달시 props가 추후 추가될 것을 고려해 props.속성명으로 사용

   커스텀 hooks 만드는 방법 - 나중에 읽어보기 https://leego.tistory.com/entry/React-Custom-hook%EC%9D%84-%EB%A7%8C%EB%93%A4%EA%B8%B0-%EC%A0%84%EC%97%90-%EA%B3%A0%EB%A0%A4%ED%95%B4%EC%95%BC-%ED%95%A0-%EA%B2%83%EB%93%A4, https://react.vlpt.us/basic/21-custom-hook.html

   옵셔널 체이닝 - 작성 예정

7. 수요일 세션 예습 - 특히 중요하다고 생각하는 부분

• 주석은 남기지 마라 : 모두가 극혐하는 듯..? 아예 주석으로 설명이 필요하지 않게 깔끔하고 보기 쉽게 작성하자.
• 조건문 대신 함수나 클래스를 사용해라 -> 아래 조건문 캡슐화 부분 참조
• 부정조건문을 사용하지 마라 -> 코드 작성중에서도 느꼈지만 부정조건문을 사용하면 그 의미가 명확하게 와닿지 않는다. 사용안하는 방향으로 다시 고민해보기.
• 조건문 캡슐화? (참고 사이트 : https://velog.io/@beomsun/%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%EC%9E%85%EB%AC%B8-%EC%BA%A1%EC%8A%90%ED%99%94, https://seungtaek-overflow.tistory.com/16) 캡슐화란 기능의 구현을 외부로부터 감추는 것이라고 한다. 처음 조건문을 작성했을 때 해당 조건이 이후 더이상 변하지 않는다면 상관없겠지만 추후 걸러야하는 조건이 추가될 경우 계속해서 &&나 || 연산자를 사용하여 조건을 추가해야하는 상황이 발생 -> 가독성이 떨어지고 클린하지 못한 코드가 된다. 그래서 클래스 안에 조건문들을 감추고 클래스 내부에서 조건문 추가 작업 => 조건문이 실행된 값만 return 하게끔 캡슐화하는 것이다. (추후 수정 가능성 있음 first written in 06/July/22)_
• 함수는 하나의 행동만 해야한다 -> 당연한 상식같지만 지키기 어려운 중요한 부분.
• 문맥상 필요없는 것을 생략하라 - validation() 함수에서 if-else 문 작성시 else 생략해도 오류가 발생할 가능성이 전혀 없는가? (참고 사이트: https://developer-talk.tistory.com/316)

  if : 어떤 조건이 참일때 실행될 코드 블럭{}을 가짐
  else : 위와 같은 조건에서 거짓일때 실행될 코드 블럭{}을 가짐
  ★else if : 첫번째 조건이 거짓일때 새로운 조건을 걸고, 그 조건이 참일 때 실행될 코드 블럭을 가짐. => 이때의 else는 첫번째와 두번째 조건이 모두 거짓일 때 실행되게 됨.

스스로 작성한 메모를 보면 되는 것을.. else 코드는 if 조건이 만족하지 않으면 실행되는 부분이니 if 문에서 조건이 만족하지 않았을때 return값을 정의했다면 else 부분은 생략해도 무방하다고 한다.(원래도 else는 생략가능)

validation 코드 캡슐화 + 수정한 부분 작성 예정

+) 구글링 하면서 쭉 보니 클린 코드 작성시 if-else문을 최소한으로 사용하는 것을 지향하는듯(가독성 떨어지니까)

8. 추가 공부할 부분

• 클린 코드 예시 꼼꼼히 분석하기
• 내 코드 리뷰 : 변수명, 조건문, 주석 체크해보기