프로젝트(멘토) 회고록

프로젝트 멤버를 잘 만난 탓에^^ 멘토님께 좋은 첫인상을 준 것 같다.
일단 우리는 우리의 프로젝트에 대해 소개하고, 피그마 링크를 함께 첨부했다.
그리고 논의사항(질문)을 남겼는데,
1. 정확히 어떤 부분에서 문제가 발생했고 왜 이런 고민을 하게 되었는지
2. 고민을 해결하기 위해 고려해본 방법들
이렇게 정리를 해서 보내드렸다.

백엔드가 두명뿐이라 백에 짐을 최대한 덜고 싶어서 나온 질문도 있고
현직자의 입장에서 구현하고 싶은 부분에 대한 조언
그리고 지금 시점에서는 최대의 고민이자 어려움인 eslint....

[프로젝트 소개]

취지

• SNS가 주는 피로에서 벗어나서 나에게 집중할 수 있는 색깔 감정 일기 제공
  주요 기능
• 크롬 익스텐션으로 시작페이지 적용 예정
• 매일매일 색상으로 감정 기록
• 하루 뒤 도착하는 편지 전송
  • 느린 SNS라는 기조를 바탕으로 바로 전송되는 채팅이 아닌 편지 기능을 채택
    부가 기능
• 과거 기록 확인
• 친구의 오늘 감정 확인
• 투두리스트
• 색 테마 구입

[피그마 사진 및 피그마 링크]

[논의 사항]

1. 한달 통계의 시각화

• 한달 통계라는 메뉴를 누를시, 그 달에 저장된 감정 색상들을 혼합해 전체 페이지에 CSS 그라데이션으로 표현해보려고 합니다.
• 그라데이션이나 마블링 등 시각적인 부분을 표현할 때 현업에서는 어떤 방식과 요소를 쓰시는지 궁금합니다.

2. 색테마 정보를 프론트 측에서 처리할지 백엔드 측에서 처리할지에 대한 논의

• 유저는 획득한 포인트로 기분에 적용할 수 있는 색 테마 구매 및 적용이 가능합니다. 적용할 수 있는 색 테마는 기본 테마 포함 총 5가지 입니다
• 유저가 적용한 색 테마로 친구의 색상 또한 적용되어 나타납니다.
• 현재 아래 두 안 중에 고민 중입니다. 어떤 방안이 더 나을지 조언을 구하고 싶습니다.
  1안)
  • 색 테마와 색 테마의 컬러코드까지 전부 서버에 저장해놓고 이를 받아와서 구현
  • 이를 통해 추후 색 테마가 추가되었을 때 유지보수 측면에서 나을 것이라고 생각했습니다.
    2안)
  • 색 테마 이름만 서버에 저장해놓고 받아와서 프론트에서 상태관리(ex. redux-persist)를 통해 색상 테마의 컬러코드 정보를 가지고 있다가 테마에 따라 컬러 코드를 적용시켜서 구현
  • 프론트가 상태 관리를 통해 가지고 있을 정보 예시
    테마: [테마 이름: { 기쁨: CE7E5D, 분노: A2543D, 설렘: D39A89, 걱정: D6DCD8, 평온: D6DCD8, 예민: 1D354F, 슬픔: CDD6DD, 희망: 557570}]
  • 이를 통해 백엔드 설계 및 업무가 줄어들 것으로 생각했습니다.

3. 프로젝트 초기 세팅시 eslint 적용에 대한 건
   • 초기 세팅시 eslint를 적용해보고자 했는데 각자의 개발환경에서 서로 다른 에러가 너무 많이 나서 처음부터 다시 세팅을 해야 하는 상황입니다.
   • 에러로 인해 예상했던 것보다 시간이 더 소요되는데 그럼에도 불구하고 eslint를 적용해서 사용하는게 나을지, 현업에서는 eslint를 어떻게 적용해서 사용하는지 궁금합니다.

[답변]

일단 1번에 대한 답변으로 d3를 말씀해주셨다. 현업에서 엄청 많이 쓴다고.
근데 현업에서는 이부분만 담당하시는 분이 따로 있을정도로 어렵기도 하고 배우는데 오래 걸린다고 함..
그치만 어쩌겠어 필요하다면 해야지!

2번. 아키텍쳐 설계에서는 항상 트레이드오프 기준으로 선택해야함. 백엔드 업무 축소가 가능하지만 단점이 너무 크다. 프론트에서 상태로 테마를 관리하게 된다면 테마가 변경(추가) 될때마다 프론트도 재배포를 해야함!! 백에서 하면 db만 건들면 됨.
추가적으로 연산처리는 프론트에서 하는 것을 지양함. 왜냐면 사용자는 브라우저를 사용하기 때문. 사용자의 기기에서 쓸 수 있는 자원은 한정적이다.

3번. eslint는 99% 하는것을 추천. 꼭 할것.

이 외에도 추가적으로 각자 질문을 했는데,

1. 나는 디자인시스템에 대한 질문을 했다.
   코드리뷰를 받은 적도 없고 항상 혼자서 하다보니 내가 편한 방식으로 작업을 하게 되는데,
   스타일드 컴포넌트를 쓰면서 내가 하는 방식이 문제가 되지 않을까 하는 생각을 하게 되었기 때문...
   나는 Wrapper를 만들어 컴포넌트를 감싸고, 그 안에서 새로운 클래스나 스타일드컴포넌트를 만드는 것을 피하고 선택자를 이용해서 스타일을 줘왔다.
   이렇게 되면 가시성이 좋지 않다고 하셨음.
   여러번 사용하는 것은 디자인을 잡고 재사용성을 높이는 방향으로 가라고 조언해주셨다.
   common 폴더에서 공통 컴포넌트를 만들어 쓰라고.
   사실 이부분은 전에 프리프로젝트를 하면서 절실하게 느꼈던 부분이라 이미 하고 있었음!!

2. 그리고 스타일드 컴포넌트를 쓰면서 불편했던 게, 스타일이 문서 위에 위치하고 아래에 기능이 위치하기 때문에 스크롤을 내려야한다는 것.
   그래서 팀원들과 함께 여러 방안에 대해 이야기해봤는데,
   나는 스타일드 컴포넌트를 분리해서 스타일.js와 기능.js 이렇게 누군가가 하는 것을 본적이 있어서 너무 좋은 방법이라고 생각했기때문에 공유를 드렸다.
   다른분은 각각의 컴포넌트 폴더를 만들어서 컴포넌트.js와 컴포넌트.css 이런식으로 하는 건 어떠냐고 하심!
   스타일드 컴포넌트는 스타일을 주기위해 각각의 요소에 이름을 주어야 한다는 불편함을 항상 느꼈기 때문에 너무 좋다고 느껴서 그렇게 해보자고 했는데,
   또 어떤분은 사실 그 방식이 딱히 와닫지 않으셨던 것 같다. css가 오히려 어려우셨던 듯.
   그래서 멘토님께 질문을 하셨는데, 아토믹 디자인 시스템이라는 것을 추천해주셨다.
   컴포넌트를 최대한 쪼개서 사용하는 방식인 것 같았는데 자세한건... 이따 블로그 다 쓰고 찾아봐야겠다.
   담주에 폴더 스트럭처에 대해서도 함께 조언해주시겠다고 하셨음!

3. todo에 대한 정보를 어떻게 관리하느냐에 대해서도 여쭤보았다.
   사실 메인기능은 아니고 부가기능이기 때문에 로컬스토리지에 저장하기로 프론트끼리 이야기를 했었는데, 백엔드 멘토님께서 그럴거면 그 기능을 할 필요가 없을 것 같다고 하셔서 db에서 관리하는걸로 정했음.
   이제 프론트에서는 그럼 이 기능을 가지고 또 무엇을 어떻게 활용을 할 것인가에 대해 토론을 했는데...
   알고보니 세명 모두 투두리스트를 만들어는 봤는데 써본적은 없음ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
   투두 안써본 사람들이 만드는 투두라....^^
   고민1 오늘할일을 적는건데 오늘이 지나면 투두가 리셋되는게 맞지 않나?
   고민2 할일을 수행하면 그 할일은 삭제해야하는가?
   고민3 그렇다면 할일을 수행하지 못한다면 그것을 리셋해야 하는가? 불러오기 버튼을 또 만들어야하는걸까?
   고민4 수행한일을 따로 볼 수 있는 페이지도 있어야하지 않을까?
   오.....^^ 부가기능인데 너무나도 머리아픔...
   일단은 오전 네시쯤 라이프사이클이 마감되었다고 가정을 하고 그때 데이터를 db에 보낸 후, 리셋을 하는 방식을 선택했다.
   멘토님께서는 로그아웃상태에서 투두를 가져올 수 있는 방법이 없다(어렵다)고 하셨다.
   그래서 본인이라면 로그아웃 시점에 서버에 post를 하겠다 하셨음!
   그리고 새벽 네시로 리셋타임을 정한것을 디벨롭해서 사용자가 하루마감시간을 입력하게 하는 것은 어떻겠냐고도 말씀해주셨다. 근데 사실 이방법은 우리가 하기 어려울거같음...ㅠ

코드리뷰는 끝날때쯤 해주겠다고 하셨다.
코드리뷰라 넘 떨리는군...^^ 정신차리고 해야지