일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
- IP
- TCP
- CS
- awscloudclubs
- AWS
- 네트워크
- 대용량트래픽
- ACC
- TCP/IP
- 프로토콜
- github
- 스프링부트
- express
- 프로젝트
- 보안
- 클라우드
- 환경변수
- 정보처리기사
- Amazon
- 위코드
- 가상스레드
- 백엔드프로젝트
- javascript
- ERD
- 피드시스템
- wecode
- mysql
- node
- cloudclubs
- 알고리즘
- Today
- Total
아무튼!
[Wecode] 위클리 프로젝트 회고 본문
2023.03.03 - 2023.03.17
"Weekly"
고객들의 식탁 위에서 기억될 영양제 사이트
FE: JavaScript, React.js, Sass, React Router
BE: JavaScript, Node.js, Express, Typeorm, Mysql, RestfulAPI
약 2주 간의 프로젝트가 끝났다.
한 사이트를 벤치마킹 하면서도 원하는 기능들을 추가하거나 변경하여 구현하는 식으로 프로젝트를 진행했다.
맨 처음으로 어떤 사이트를 참고로 하여 구현할지 팀원들과 의논했고, 사이트 선정 후에는 어떤 방향과 단계로 구현할지 모의했다.
사이트 구현 방향을 정하는 데에만 몇 시간이 걸렸었다.
일단 정하고 난 후, 다시 기획안을 보았을 때에 부족한 부분들이 많이 보여서 수정도 많이 했다.
대략적으로 계획을 정한 후에는 Trello를 작성했다.
다들 처음 써보는 툴이다보니 세세하게 티켓을 생성하고 관리하지는 못했지만 1차 스프린트 때에 비해 2차 스프린트에 티켓들을 더 잘 관리할 수 있었다. 무분별하게 많거나 너무 두리뭉실하게 생성되던 티켓들이, 스프린트가 진행될수록 적절한 내용을 지니고 생성되게 되었다.
티켓이란게 아무래도 수행도가 보이는 척도들 중 하나이다 보니 개수를 채우는 데에 신경이 쓰였었다. 게다가 Trello는 티켓의 중요도가 보이지 않아서 정말 티켓의 개수만으로 나의 수행도가 느껴지도록 했었다. 다음에는 Jira나 asana 같은 다른 협업툴들도 더 알아보고 나와 팀원들에게 맞는 협업툴을 잘 선택해서 진행해야겠다.
아 그리고 첫 미팅에서 Product Manager을 맡게 되었다. 평소에 팀에서 팀장을 맡거나 단체를 이끄는 역할은 많이 해보지 않았어서 이번 기회를 통해 사람들을 이끈다는 것에는 어떤 능력이 필요한지 체감해보고 싶었다. 또한 나는 고객의 입장에서나 제작자의 입장에서 피드백을 잘 생각해 내고, 전달하는 편이라 생각해서 Project Manager 보다는 Product Manager를 하고 싶었다.
그렇게 첫 회의가 끝나고 난 후에 백엔드 팀으로서 제대로 하게 된 첫 활동인 ERD 설계!
저번에 1달 전 Instagram ERD 설계를 처음 해본 후에 오랜만에 하는 ERD 설계였다. 하지만 그 간에 실력이 많이 성장했는지 훨씬 복잡한 ERD 설계를 해낼 수 있었다. 기간은 하루 정도 꼬박 걸렸지만 꽤나 맘에 드는 설계가 나왔다. 프로젝트를 진행하면서 products 테이블에 description 칼럼이 들어가거나 유효성 검사를 위해 unique 조건을 부여하거나, 변경하는 일이 있었다. 다음부터는 협업의 초반 단계부터 프론트와 원활히 소통하며 수정하는 일이 적어지도록 해야겠다. 한 번 dbmate를 up 해버리면 테이블 수정을 위해서는 새로운 dbmate 파일을 작성해야 한다. 수정이 많아질수록 파일이 많아져서 정리가 힘들어졌었다. 다음부터는 최대한 처음부터 테이블을 완성형으로 작성해야겠다.
테이블을 작성하고 몇몇 임시 값들을 넣어둔 뒤에 API 설계를 시작했는데 처음에는 불필요한 API까지 작성했었다. 상품 생성이나 삭제같은 API는 따로 생성하기보다는 직접 테이블에 접속하여 관리하는 것이 보안상 더 나을 것 같다. 그래서 프로젝트 파일에는 상품 생성 API까지 존재한다. 불필요한 API이긴 하지만 덕분에 임시 데이터를 100개 이상 만들 때 감사하게도, 프론트 분들이 데이터 생성을 도와주실 수 있었다.
코드 작성은 어떻게든 뚝딱뚝딱 이뤄내긴 했었는데 아무래도 내가 혼자서 만들어낸 코드는 컨벤션이 엉망인 부분이 많았었다. 엔드포인트 규칙이라던가(동사형은 지양하기), 주석은 지워서 PR 올리기, 올리지 말아야할 파일들 관리하기, 샘플 파일 작성하기, PR 양식에 맞춰 작성하기, 커밋 메시지 컨벤션 등 협업을 진행하거나 멘토분들께 피드백을 받으면서 점점 코드가 사회화(?)되었다. 덕분에 나의 코드를 다른 사람에게 보여주었을 때, 이 변수명은 뭔지 설명해야 할 일이 예전보다 확실히 줄었다..! 혼코딩도 좋지만 이렇게 사람들과 소통하면서 함께 나아가는 과정이 너무 즐겁다.
해야한다는 것을 알고 있었지만 지금까지 미뤄왔던 일들도 이번 기회에 하게 되었다. 바로, 공식문서 보면서 정보 얻기. 구글링을 하다 보면 잘 정제된 글들이 너무 많아서 한국어로 된 자료들 만으로 궁금증을 해결하고 기술들을 익혀오곤 했었다. 공식문서로 최신화된 정확한 정보들로 정보를 얻고, 활용하는 것이 중요하다는 것은 알고는 있었지만 영어라는 장벽이 너무 크게 느껴서 막상 실천하지는 못했었다. 하지만 이번에 결제 프로세스를 구현하면서 안정성을 위해 트랜잭션을 추가해야 하는 일이 있었다.
<장바구니 내 물품을 주문 물품 테이블로 이동, 주문서 작성(유저 정보 불러오기, 주소록 불러오기, 주문 상태 저장, 주문번호 부여), 포인트 차감, 장바구니 비우기>
이 활동들 중 하나라도 제대로 이루어지지 않는다면 변경사항이 전부 적용되지 않도록 해야했다.
그런데 이 기능을 나에게 주어지는 별도의 자료 없이 정말 구글링 만으로만 정보를 얻어서 구현해 내야 했었다. 평소처럼 구글링 해서 나오는 자료들이 대부분 nestJS여서 공식문서에 나와있는 가이드로 코드를 만들었었다. 수많은 영단어들에 처음에는 읽는 것이 너무 힘들고 거부감이 들었었지만 막상 천천히 읽으면서 진행해 보니 생각보다 그렇게 어렵진 않았었다. 잘못된 정보로 구현된 코드는 치명적인 결과를 가져올 수 있다. 따라서 최대한 공식문서에 나와있는 정보들로 코드를 구성하는 것이 안정성을 확보할 수 있다. 이번에 영문서를 극복해 냈던 경험을 토대로 다음에 코드를 구현할 때에는 공식문서를 더 많이 활용하도록 해야겠다.
애초에 처음에 가지고 있는 경험이나 지식이 많이 없었던 만큼 얻어가는 것이 매우 많았던 프로젝트였다. sql 작성이 적성에 잘 맞다는 것도 알 수 있었고, 기술적인 지식을 많이 얻게 되었다. 하지만 팀 커뮤니케이션 능력에는 아직 부족함을 많이 느꼈다. 좀 더 다독이고 격려하며, 잘 들어주는 친절한 팀원이 되도록 하자! 2주라는 시간 상 아쉽게도 구현해내지 못했던 장바구니 선택 삭제와 선택 구매 기능을 다음에 꼭 구현하기로 기약하면서 이번 프로젝트 회고를 마친다.
Team Repo: https://github.com/wecode-bootcamp-korea/43-1st-MG-backend
GitHub - wecode-bootcamp-korea/43-1st-MG-backend: 장지원, 윤수빈
장지원, 윤수빈. Contribute to wecode-bootcamp-korea/43-1st-MG-backend development by creating an account on GitHub.
github.com
'Re:' 카테고리의 다른 글
[주저리] 한국이 자바 공화국이 된 이유(w/ 닷넷, 노드) (3) | 2024.10.01 |
---|---|
[주저리] IT 개발 취준생으로서 자격증에 대한 생각 (0) | 2024.09.13 |
[ACC] 2주차 회고 (9) | 2024.07.28 |
2023 상반기 활동 결산 - 그럼에도 나아가야지 (2) | 2023.07.06 |
[Wecode] 2차 프로젝트 회고 (0) | 2023.04.10 |