ASSIGNMENT_1
프리온보딩 코스는 매주 2개의 과제, 총 7개의 과제가 주어집니다.
첫번째 assignment는 랜덤으로 주어진 팀(7명)에서 BestPractice(모범사례)를 만드는것이였습니다.
시작과정
정해진 과제물의 정답은 없었고. 이것을 어떻게 해석하고 만들것인지 또한 팀의 자율적인 해석을 통해 도출해내는 과제였습니다.
기본적으로 토론을 통해서 어떠한것이 모범사례인지 찾아야 하는 과정이 선행되어야 했습니다.
저희 팀은 그걸 위해 우선적으로 각자의 코드를 발표하는 시간을 가졌습니다.
그러한 과정을 통해서 각자의 코드에서 Good Point와 BadPoint를 발견하여 적어주기로 하였습니다.
과정을 마무리 한 후, 저희들이 BestPractice를 찾기 위해 제시한 제안은 두가지였습니다.
첫번째는 제가 제시했었던 찾아낸 포인트를 가지고 각자 리팩토링을 해보자, 그리고 점진적으로 개선해가면서 BestPractice를 선정하는게 어떻겠냐는 것이였습니다.
또 하나의 안은, Good Point들을 모아서 하나의 프로젝트를 새롭게 만들어보자는 것이였습니다.
이것에 대한 의견은 나뉘었고, 잠깐의 휴식시간을 거친후
다른 팀원분의 의견으로 기존 과제물의 요구사항을 들여다보고, 그것에 맞는 Good Point를 찾아 개선하는것이 중요한것 같다는 의견을 받았고, 첫번째 안과 결합하여 최종안으로 다른 팀원분들의 동의를 얻었습니다.
최종적으로 선정된 진행과정은 요구사항을 지켜내기 위한 GoodPoint라 생각하는 부분들을 모아, 다 같이 기존의 과제물을 리팩토링을 진행하고, 이후에 한분의 과제물을 선정하여 그것을 제출하자는 것이였습니다.
시작전 규칙
선정된 요구사항
1. 폴더구조
이부분은 각자의 코드 스타일이 너무 강하게 작용하는 부분이였기 때문에, 강제하기엔 어렵다 생각해서 자율적인 선택에 맡기기로 하였습니다.
2. 로그인/회원가입 경로 구분
이부분 또한, 각자 구현된 CSS가 가지각색이여서 자율적인 선택으로 하였습니다.
3. 이메일, 비밀번호 유효성 검사 기능
이 기능은 어느분은 파일로 빼서 함수를 구현하였고, 어느분은 컴포넌트 내부에서 구현하였는데, 함수의 단일책임 원칙과 의존성 최소화, 유지보수 면에서 함수를 따로 빼서 보관하는것이 좋다 생각하여 다같이 utils함수에서 정규식 함수를 만들기로 하였습니다.
3-2. 위 조건 만족할때만 버튼 활성화
이 기능은 모두 조건 만족하였지만, 추가적으로 버튼자체는 disabled라도, html상에서 지울수도 있고 또한 함수의 유지보수 측면에서 만약이라도 에러가 날 가능성도 있을수 있기때문에 버튼 클릭시 한번 더 조건을 체크하는 함수를 실행시키자고 하였습니다.
4. 로그인 API 호출 성공시 /todo 이동
모든 분들이 promise의 status값이 200일시 이동하는걸로 하였습니다. 하지만 추가적으로 200이 아닌 값, ErrorStatus 또한 관리하는것을 권장하였습니다.
5. JWT 토큰값 로컬 스토리지에 저장
3번과 동일한 이유로 utils함수에서 토큰값을 관리하는 함수를 만들기로 하였습니다.
6. 로그인 여부에 따른 리다이렉트 처리
몇몇 분의 라우터에서 함수를 사용하여 로그인 여부에따라서, pages를 분기처리하는 함수를 사용하는 방법이 인상적이여서, 이러한 부분을 따르기로 하였습니다.
7. 투두 리스트 목록 (/todo 접속시)
useEffect에서 바로 값을 불러오는것보단, 명시적으로 값을 받아오는 함수, getTodos와 같은 함수를 생성한후 useEffect내부에서 사용하는것으로 하였습니다.
8. 투두 내용 및 완료 여부 표시
조건자체는 모든 분이 만족하였습니다.
9. 입력/추가 버튼, 추가 버튼 클릭시 입력창 내용 투두 리스트에 추가
공백에서는 투두를 입력,수정할 수 없도록 하기로 하였고, 에러가 있을시 에러 표시 나타내도록 하였습니다.
10. 투두리스트 수정 버튼 클릭시 수정모드 활성화 및 투두 리스트 내용 수정 가능
이부분은 많은 분들이 기본적인 조건은 만족하셨지만, 추가적으로 각자의 생각에 맞게 기능을 구현한 부분이 있기 때문에 내용과 완료여부를 수정하는 조건을 수정모드에서 다 같이 관리하는것이 좋다는 의견이 권장되었습니다.
11. 수정모드시 우측에 제출/취소 버튼 표시
모든 분이 조건을 만족하였습니다.
12. 개별아이템 우측에 삭제 버튼
모든 분이 조건을 만족하였습니다.
13. 그외 기능(옵션)
팀원분들 각자가 독특한 추가 기능들을 구현해주셨습니다.
괜찮은 추가 기능들이 있었고, 이부분을 구현하는것은 각자의 선택으로 하였습니다.
- modal로 메시지 관리
- errMsg를 status에 따라 관리하기
- 로그아웃 기능
- 페이지네이션
- 카운터 기능 or 완료 / 미완료 필터 기능
14. 기타 규약
추가적으로 팀 전체의 코드에서 지키고자 하는 규약을 정하였습니다.
- 컴포넌트나,컨텍스트 등 내부에서 크게 상관없는 관심사 밖의 함수는 utils등의 파일에 보관할것
- 변수명 data는 지양하고,가능한 명확한 변수명을 사용할것
- resetCSS가 적용이 안되어있다면 크로스 브라우징을 위하여 사용할것
- CRA에서 필요없는 파일은 삭제할것
- 프로젝트는 불필요한 CRA가 삭제되었고, ESLint,prettier 설정을 한 husky가 설치된 프로젝트를 클론하여 각자의 과제물을 리팩토링할것
- 아래와 같은 커밋 규칙을 추가하여 진행하였습니다.
⭐ feat : 새로운 기능에 대한 커밋
🛠 fix : 버그 수정에 대한 커밋
🧱 build : 빌드 관련 파일 수정에 대한 커밋
👏 chore : 그 외 자잘한 수정에 대한 커밋
⚒ refactor : 코드 리팩토링에 대한 커밋
🎨 style : 코드 스타일 혹은 포맷 등에 관한 커밋
✏ docs : 문서 수정에 대한 커밋
💡 ci : CI관련 설정 수정에 대한 커밋결과
이러한 리팩토링 과정을 거치고, 이후 투표를 거쳐서 한분의 프로젝트를 선정하였습니다.
최종적으로 선정된 분의 코드는 토의에서 대부분의 요구사항을 만족하였고, 코드 퀼리티, 컴포넌트 관심사 분리등 모든 부분에서 가장 깔끔하다 생각되신분의 과제물로 제출하게 되었습니다.
개인적 소감
정말 반성이 많이 되는 첫번째 과제물이였습니다.
개인적으로 제 코드 실력에 대한 반성이 가장 컸던것 같습니다.
과제물 자체도 정말 딱 최저라인에 맞게 작성하였고, 추가 기능이나 코드의 퀼리티를 생각하면 정말 처참하다 생각이 들었습니다.
정말 아쉬웠던 부분은, CSS부분에서 tailwind를 사용했는데, 이것을 사용하다보니 className이 너무 길어졌고, 그러다보니 component화를 하는것에 부담을 느꼈습니다. 때문에 관심사를 분리한 컴포넌트는 거의 최소한으로 하였고, 이부분은 정말 잘하신분 과는 많은 차이를 느꼈습니다.
두번째로 axios에서의 err처리를 저는 하지 않았습니다. 요구사항에 없었기 때문이기도 하지만, 이후에 구현해보려 했는데도 생각만큼 효율적이게 구현되지 않는 실력을 체감하며 반성을 하였습니다.
세번째로 요구사항에 있던 라우터에서 함수를 생성하여 처리하는 부분에서 저는 결국 구현에 막혀서 하지 못한 부분입니다. context를 사용하여 login을 구분하였고, tempLogin으로 새로고침시 다시금 login 상태를 입력하였는데 이부분에서 충돌이 일어났고, 좋은 방법이 생각나지 않아 구현하지 못하였습니다.
네번째로 readME부분에서, 많은 분들이 정말 보기 좋게 요약을 해주셨는데 저는 정말 무성의하게 작성하거나, 그마저도 하지 않았었다는걸 깨달았습니다.
마지막으로, 본의 아니게 팀의 팀장을 맡게 되었습니다.
사실 원친않은 직이였습니다. 성격상 맡는 역할도 아니였습니다.
하지만 어쩌다보니 맡게되었고, 어쨌거나 팀의 진행을 이끌어야 하는 역할과 책임을 맡게된것 같았습니다.
그러다 보니 괜히 호응을 얻기 위한 쓸데없는 말도 많이 하였던것 같고, 제 코딩 실력자체도 좋지 않은편인데, 앞장서서 의견을 말하려다 보니 잘못된 의견이나 제 일방적인 의견을 제안하기도 하였던것 같습니다.
다행히 팀원분들의 많은 도움으로 좋은 의견을 내주셔서 과제가 좋은 방향으로 진행되기도 하였고, 어느 한분이 노션과 과제 제출물의 리드미등을 잘 꾸며주시기도 하셨습니다.
개선점
우선, 팀장의 역을 맡은 것에 대한 앞으로의 개선점을 말하자면
혼자서 너무 많은것을 하려 할 필요가 없다는것을 느꼈습니다. 그렇기 때문에 저는 필요한 방향으로의 말만 하면서 진행해나가면 되겠다는 생각을 하게되었습니다.
코드 부분에서의 개선은 우선 tailwind를 사용하고 있지만, twin.macro라는 테일윈드용 라이브러리와 tailwind-styled-component라는 라이브러리의 사용을 고민하다, 후자를 선택하여 앞으로는 가능하면 많은 부분을 관심사를 분리한 컴포넌트화를 진행하기로 하였습니다.
나머지 부분은 시간이 촉박하기때문에 단기간에 고쳐지진 않을것입니다. 하지만 남은 기간동안 적어도 민폐는 되지 않도록, 최선을 다하자는 생각으로 코드 실력을 발전시키고자 하였습니다.
