0. 일상
오랜만에 글을 쓴다. 글을 써야지 써야지 생각만하고 귀찮아서 미루게 되는데 쓰게 하는 습관을 들이던가 쓰게 만드는 나만의 규칙을 정해야겠다. 글을 쓰면서 나만의 회고도 되고 생각을 정리할 시간을 스스로에게 주는 것 같아서 도움이 된다.
와인이야기
- 와인수업이 끝난지 꽤 되었다. 수업이 끝나고 와인을 마시거나 공부하는 시간을 따로 잡지 못했는데 시간이 지나면 잊혀질 것들이라 자주 와인을 접해보려는 노력을 하려한다. emart 가는 길에 한 병씩 사던가 일정이 없는데 코딩을 하고 싶지 않을 때 예전에 공부했던 책을 꺼내서 읽어보려 한다.
사이드 프로젝트
- 와인 앱 만드는 사이드는 계속해서 하고 있다. 처음에 와인 데이터들을 firebase에 모두 업로드하고 조회했었는데 (firebase 하루 upload limit가 있어서 몇일에 걸쳐서 업로드 했다 ㅠ) firebase가 부분 문자열 검색이 되지 않아 결국 elasticsearch로 갈아탔다.
- elasticsearch를 docker로 띄우고 앞에 node server 띄우는 방식으로 해결했는데 내가 생각한 대로 잘 작동했다. flutter 코드랑 elasticsearch에 bulk로 데이터 넣을때 formatting하는 것까지 모두 chatGPT를 활용해서 진행했고 정말 빠르게 구현했다.
- 하지만 서버를 띄워야 한다는 부담이 존재하여 server를 사용하지 않고 앱안에 데이터를 저정하고 검색시 앱에 저장된 데이터에서 조회하는 식으로 변경해보려고 한다.
1. 폴더구조 세 번째(마지막) 논의
회사에서 흩어진 프로젝트를 통합하면서 폴더구조를 정하고 있다. 두 번째 논의에서 대부분 다 정했으나 common에 대해 애매한 부분이 있어 내가 세 번째 논의를 발의했고 이 세번째 논의를 마지막으로 폴더구조에 대한 모든 팀원들의 생각을 맞추게 되었다. 앞으로 개발하다 보면 애매한 부분들이 생기고 다시 논의가 필요하겠지만 지금 상황에서 애매한 부분은 대부분 다 정리했다고 생각한다. 적어도 큰틀과 기준을 정했기에 추후에 생길 수 있는 애매한 부분도 많이 없어지지 않을까 생각한다.
이전 논의
아젠다
아젠다: 두 번째 논의 후에도 찝찝함이 생기는데, 왜 찝찝함이 생길까? 찝찝함을 찾아서 없애보자!
1. common 에 들어갈 수 있는 것
코드를 액션과 계산으로 나누고 common에 들어가는건 계산만 넣어보자.
- 순수함수
- 외부 IO
- 변하지 않는 것
2. common 내 폴더 별 예시
- util: 순수함수 (계산), web api
- service: bridge 한 번 wrapping 한 것
- style: animation
- hook: 비즈니스 로직이 포함되어 있지 않은 useBoolean, useIsTopEffect
- component: 당근 디자인시스템 공통 컴포넌트 (sprout), sprout에 아직 구현되어 있지 않은 컴포넌트
- svg, icon, css animation, calculate util, brand logo, image, etc…
- 기타 질문
- production, beta, alpha, userid 같은 것 들도 비즈니스 로직이 아닌가?
- 회사의 정책이고 자주 변하는게 아니기 때문에 common에 개념이 들어가도 되지 않을까?
common과 shared의 구분기준을 비즈니스 로직이냐 아니다도 좋지만 자주 변하는거 변하지 않는거로 생각했어요.
비즈니스 로직이 있으면 자주 변하기 때문에 shared에 들어가게 되고 common에 들어가는 것들은 자주 변하지 않는 것들이 들어가게 되는데 그런 관점에서 바라보면 production, beta, alpha는 거의 변하지 않는 것들이기 때문에 common에 들어가도 괜찮지 않을까 생각했어요.
결론
- common에 들어가는건 side-effect가 없는 로직, 자주 변하지 않는 것들 (비즈니스 로직)
- shared에 들어가는건 액션, 자주 변하는 것들(비즈니스 로직)