주니어개발자 앱개발기1 - ChoLog 초록(草錄)

드디어 오늘부터 코드스테이츠에서 파이널 프로젝트를 하게 됐다.

나포함 4명이 한 팀이며, 두 명씩 나눠서 프론트엔드 백엔드를 맡았다. 나는 백엔드!

 

능력자이신 우리 팀장님께서 팀명으로 로고도 만들어주셨다. 히히

팀명은 009900. 색상표에서 #009900이 초록색이라서 009900으로 하기로 했다.

거꾸로 써도 009900이라는 점이 포인트. 줄여쓰면 090이다.

 

시간이 된다면 오늘과 같이 글이 많은 Devlog를 쓰고싶긴 한데 아무래도 다음 Devlog는 오늘만큼 글이 많지 않을 것 같다. 코드나 공식문서 글, 다이어그램 비중이 높아질 듯. (지난 2주 프로젝트에서의 Devlog처럼).

글이 많든 적든 꾸준히 쓰는 것이 목표이다.

시간이 지나서 이 카테고리의 글을 읽었을 때 '나 많이 컸구나'를 느낄 수 있게 되기를!!!

 

풀草 기록錄 앱.

키우는 식물에 대한 성장/관리 정보 기록 및 관련 알람을 받을 수 있는 앱.

나아가서는 동종 식물을 키우는 커뮤니티에서 정보를 나눌 수 있음

위 컨셉의 앱을 만들것이다.

 

오늘은 팀 룰과 어떤 스택을 사용할 것 인지를 정했다.

 

 

 

---

1. Team Rule

1-1. 스탠드업 미팅

매일 오전 10시 30분에 간단하게 어제 진행했던 것, 오늘 할 것을 얘기하는 가벼운 미팅을 진행한다.(30분 정도)

1-2. 하루 두 번의 코드리뷰

1. 첫 번째 코드리뷰: 스탠드업 미팅 직후인 오전 11시 - 정기 코드리뷰(필수)
2. 두 번째 코드리뷰: 오후 5시 - 임시 코드리뷰(필수는 아님)

임시 코드리뷰는 풀리퀘스트가 올라와있어서 머지를 해야할 때만 진행하며, 첫 번째 코드리뷰는 풀리퀘스트가 없더라도 지금껏 진행한 코드에 대해 리뷰한다.

1-3. 머지는 반드시 코드리뷰 통과 후에

지난 2주 프로젝트에서는 너무 바쁜 나머지 풀리퀘스트를 올리고 컨플릭이 없으면 바로 머지하는 방식으로 진행했었다.

그러다보니 프로젝트 후 코드를 봤을 때 아쉬운 점이 좀 보였었다.

원래 자기 코드의 아쉬운점을 자기가 찾는 건 어려운 일이니까.

1-4. 커밋룰

1. 깃모지: https://gitmoji.carloscuesta.me/
2. 다음 글 참고하여 커밋메세지 쓰기: https://blog.ull.im/engineering/2019/03/10/logs-on-git.html

깃모지야 워낙 유명해서 설명하기 뭣하지만, 2주 프로젝트때에도 깃모지를 사용해서 커밋메세지를 작성했었는데 커밋메세지가 한 눈에 들어와서 너무 편했다. 귀엽기도 하고.

그 아래의 블로그글(좋은 git commit 메시지를 위한 영어 사전)은 우연히 찾은 글인데 너무 좋은 글이라서 커밋메세지 작성할 때 마다 매번 참고한다.

1-5. git-flow의 방법으로 브랜치 관리

2주 프로젝트때에는 하나의 메인 깃헙레포에 dev, master 이 두 branch가 있어서

1. 메인레포의 dev브랜치에서 로컬로 브랜치를 따와서 작업
2. 메인레포에서 포크받은 내 레포에 push
3. dev브랜치에 PR(Pull Request) 후 메인레포의 dev에 머지

하는 방식의 간단한 브랜치관리를 통해 프로젝트를 진행했었다.

하지만 이번에는 진짜 진지하게 배포까지 할 것이기 때문에 여기저기서 많이 사용하는 git-flow를 도입할 것 이다.

git-flow 한글번역: https://blog.ull.im/engineering/2019/03/10/logs-on-git.html

git-flow익스텐션을 사용할 수 있으면 좋겠지만 그게 힘들다면 수동으로 git-flow의 브랜치 관리방식을 따라가고자 한다.

내가 파악한 바로 git-flow의 브랜치 관리 방식은 다음과 같다.

1. 메인레포는 최종적으로 develop과 master브랜치만 남게 관리.
2. 기능개발 시 develop에서 feature/로 branch따오기.
   1. 브랜치명은 기능별로(예. 로그인기능: feature/login, 로그아웃기능: feature/logout ...)
3. 릴리스는 메인레포에서
4. 릴리스 끝나면 그 릴리스브랜치를 develop브랜치와 master브랜치로 머지 후 릴리스브랜치 삭제

1-6. 구조는 다 같이 짜기

이거 생각보다 정말 중요하다.

백엔드를 맡든 프론트엔드를 맡든 그 둘은 동떨어져있는 것이 아니고 서로 데이터를 주고받아야 한다.

그렇기에 내가 맡은 부분이 아닐지라도 서로의 구조를 아는 것은 매우 중요하다는 것을 지난 2주 프로젝트 때 뼈저리게 느꼈다.

그리고 정말 재미있었던 게 서로의 구조를 이해하고 짜니까 프로젝트의 진행속도가 더 빨라졌다.

1-7. 클린코드 지향, 코드를 적고 라이브러리를 사용할 때 '사용하는 목적과 이유' 항상 생각하기

개발자라면 이 항목의 중요성을 모르는 사람이 없겠지만 그런 만큼 나도 모르게 쉽게 어기게 돼서 적어뒀다.

항상 명심 또 명심하기.

 

 

 

---

2. 사용 스택

1. TypeScript
   • JavaScript의 특징인 '타입이 없다'는 점이 JS의 에러핸들링을 어렵게 한다는 것을 느꼈다. JS는 함수에 내가 원하는 데이터타입이 들어오지 않을 경우의 에러핸들링이 까다롭다! 물론 처음부터 그것을 고려해서 코드를 짜면 되는 일이지만 그러면 코드가 지저분해지는 슬픈 일이 생긴다.
   • 어쨌든 위의 문제 때문에 TS의 '타입이 있다'는 점이 매력으로 다가와서 이번에 사용해보기로 했다.

2-1. Front End

난 Back End지향이지만 최종적으로는 Full Stack개발자가 되고 싶기도 하고

Back쪽에 여유가 생긴다면 Front로 지원도 가야 하기 때문에 Front의 스택을 알고 있어야 한다!

1. React Native
   • immersive코스를 진행하면서 React를 배웠고 앱스토어에 올리기 위해 React Native를 사용하기로 결정했다. 아마도 도전적인 과제가 될 것 같다.
2. MobX
   • 2주 프로젝트 때 react의 state관리에 애를 먹었기 때문에 그를 도와주는 라이브러리를 도입하기로 했다.

2-2. Back End

1. Node.js
2. express: https://expressjs.com/ko/
   • express와 graphQL사이에서 여러 고민을 했었다. graphQL을 사용하면 front와 back의 경계가 모호해질 수 있을 것 같다는 의견이 있어서 좀 익숙한 express를 사용하기로 했다.
3. TypeORM: https://typeorm.io/#/
   • TypeScript를 사용할 것이라면 ORM도 TypeORM을 사용하는 것이 좋다는 추천을 받고 TypeORM사용을 결정하게 됐다.
   • 이제 좀 Sequalize에 익숙해졌다 싶은데 다른 ORM을 사용해야 한다니 아쉽지만 재미있을 것 같다. 기대됨
4. MySQL과 MongoDB: https://www.mongodb.com/
   • DB를 SQL을 사용할지 NoSQL을 사용할지는 아직 고민중에 있다.
   • 현재 앱의 기능에 대한 설문조사를 진행중인데 '원하는 카테고리를 유저들이 직접 만들어서 식물을 관리하는 기능'을 추가하면 좋을 것 같다는 의견이 많다. 그 기능을 구현하기 위해서는 컬럼이 따로 필요 없는 NoSQL이 DB관리에 좋을 것 같은데 둘이서(백엔드는 두명이서 진행함) 4주만에 완전 새로운 개념을 익혀서 사용하기에는 시간이 촉박해서 NoSQL의 특장점을 살리지 못할수도 있다는 CS두현님의 의견을 들었기 때문에 고민중이다.
   • 지금 생각으로는 MySql과 MongoDB를 둘 다 사용하면 어떨까 싶다. 너무 복잡하려나?? DB의 스택은 내일 아침의 스탠드업 미팅 후 수정해야겠다.