IWEA Project
1. Project를 진행하며
2023년부터 1월 2일부터 2023년 1월 13일까지, 약 2주간 코딩 공부를 시작한 후 처음으로 프로젝트를 하게 되었습니다. IKEA 홈페이지를 기반으로 디벨롭하여 PET 분석, 기획, DB 모델링, API 구현과 프론트엔드와의 통신까지, 처음부터 끝까지 팀과 함께 하나씩 구현하였습니다. 클론 코딩이 아닌, 우리만의 페이지를 만들어내는 게 가장 큰 목표였습니다.
좋은 기회로 Project manger를 맡게 되었는데, 효율적으로 이번 프로젝트가 진행되기 위하여 Agile 방식을 채택하였고, 팀원 모두가 서로의 진행 상황을 알 수 있도록 Trello를 활용하였습니다. 이외에도 매일 진행되는 Daily standup meeting, 매주 월요일에 진행되는 Sprint meeting 등을 통해 팀원들간의 소통이 원할하게 이루어질 수 있도록 노력하였습니다.
또한 제가 맡은 티켓들은 아래와 같습니다. 구현 사항에 대한 설명은 깃허브 readme에 작성되어 있습니다.
DB 모델링, signup, signin, products, carts, orders, pagination, error handling
2. 이번 프로젝트를 통해 내가 얻은 것
2-1. 소통의 중요성
무엇보다 가장 크게 얻은 것은 소통의 중요성이었습니다. 예를 들어, 프론트엔드 팀원에게 아래와 같이 "productId랑 해당 숫자 카멜케이스로 서버에 보내주시면 돼요!" 라고 말하였을 때, 자꾸 통신이 실패하여 req를 콘솔에 찍어보니 프론트엔드에서는 카멜케이스가 아니라 스네이크 케이스로 보내고 있었거나, 모두 소문자로 보내고 있었거나 하는 경우가 있었습니다.
서로 무엇이 잘못된지도 모른채 낭비한 시간이 너무나도 많았고, 이후 이렇게 소모되는 시간을 줄이기 위해 API Documentation을 더욱 정확하게 작성하였고, 슬랙을 통해, 혹은 포스트맨을 통해 정확히 어떤 식으로 보내면 될지, 받으면 될지 글로 남기는 작업을 추가 수행하였습니다.
2-2. 콘솔의 중요성
2-1의 내용과 이어지는 것인데, 내 코드는 잘 돌아가는 것 같은데 통신할 때마다 에러가 발생할 때, 처음엔 무엇이 잘못된 건지도 모른 채 무작정 "왜 안 되지?"라는 말만 반복하였습니다. 하지만 이후 콘솔을 하나씩 찍어보는 습관을 들이면서, 내가 클라이언트로부터 받는 요청이 무엇인지, 내가 보내는 응답이 무엇인지, 왜 이게 구현되지 않는 건지 스스로 알아가는 방법을 터득하였습니다.
2-3. 깔끔해진 코드
멘토님들의 피드백과 위코드 동기들의 피드백을 통해 코드를 더욱 깔끔하게 작성하는 습관을 들일 수 있었습니다. 나 자신이 읽기 어려운 코드는 다른 사람들도 읽기 어려울 것이고, 이는 피드백을 받을 때 기술에 대한 피드백보다 코드 가독성에 대한 피드백이 더 많을 것이며, 이는 내 기술적인 성장의 속도를 늦출 것이라고 생각하여 코드를 작성할 때 가독성을 최우선으로 생각하며 작성하였습니다.
가독성을 생각했을 뿐인데, 덕분에 더 좋은 코드(좋은 코드, 안 좋은 코드가 어디 있나 싶기도 하지만,) 를 작성하기 위해선 어떻게 해야하나라는 고민으로 이어졌습니다. 코드 작성 전에 고민하는 시간을 들였고, 여러 기술들을 시도해보려고 하였습니다. 예를 들어, 에러 핸들링을 한 미들웨어에서 관리할 수 있도록 하였고, orders API에서 트랜잭션을 사용하여 CRUD의 안정성을 보장할 수 있었습니다. 이외에도 Insert와 Update의 두 개의 쿼리를 사용하는 것이 아니라 UPSERT 구문을 사용해볼 수 있었고, Bulk Data Loading을 알게 되어 여러 쿼리에서 활용할 수 있었습니다. 또한, 가독성을 높이기 위해 (이 블로그 가장 첫 gif에 있는) 페이지네이션과 정렬을 한 메서드 내에서 수행할 수 있도록 구현하기도 하였습니다.
3. 아쉬웠던 점
- Raw query만을 사용하여 쿼리문을 작성한 것이 아쉬웠습니다. 쿼리 빌더를 직접 만들어보거나 TypeORM을 조금 더 활용하였다면 완성도가 더욱 높지 않았을까라는 후회가 남기도 합니다.
배운 것 활용하기 8 : 새로운 기술 활용하기 2의 비율이 아쉬웠습니다. 물론 배운 것을 활용할 수 있었다는 것은 정말 좋았지만, 시간이 조금 더 있었다면 구글링을 통해 다른 더 좋은 방법을 찾고 시도해보았을텐데라는 아쉬움이 남습니다.- 사소하게 조금씩 수정하는 것. 물론 프로젝트를 진행하면서 한 번에 API가 완성되는 일은 거의 없을 것이라고도 생각합니다. 하지만 코드 작성을 시작하기 전 조금만 더 깊게 생각하였다면 사소하게, 정말 사소하게 수정하는 빈도가 줄지 않았을까 싶습니다.
다음 2차 프로젝트에는 아쉬웠던 부분들을 보완하고 더 나은 결과물을 낼 수 있도록 해야겠습니다.
4개의 댓글
- 가은님이 잘한 점 1 : PM 으로서 보여준 배려와 포용력
팀 내에 가은님처럼 잘하는 사람도 있고 상대적으로 잘하지 못하는 사람도 있는데 가은님은 그런 팀원을 독려하고 때로는 적절한 자극을 주어 팀원이 적극적으로 팀 프로젝트에 참여하도록 유도하였습니다. 또한 본인이 앞서 나갔을지라도 열의가 있어서 따라오려고 노력하는 팀원을 위해서는 차분히 기다려주고 때로는 자신의 몫을 어필할 수 있도록 자신의 몫까지 양보하는 대인배의 모습까지 보여 주셨습니다 🥰 저는 다른 팀 PM이었는데 가은님의 리더십을 보고 좋은 자극과 감명을 받았습니다. 가은님이 저보다 어리지만 존경스러웠답니다 😍
- 가은님이 잘한 점 2 : 도움을 주는 것도 받는 것도 잘한다 && 문제를 끝까지 물고 늘어져서 결국 해결한다
보통 타인을 도울 수 있는 것만이 능력이라고 생각하기 쉬운데, 필요한 도움을 타인으로부터 받아 내는 것도 능력이랍니다 😉
가은님은 자신의 시간을 쪼개어 팀원은 물론 다른 팀인 저까지 적극적으로 먼저 나서서 도와 주셨고 (제 질문에 함께 고민하는 것은 물론 슥 지나가면서 팁을 던져주신 적도 많아요), 본인의 문제에 있어서는 다른 분들에게 적극적으로 도움을 요청하여 막히는 부분을 끝까지 물고 늘어져서 해결하셨습니다. 문제가 생겼을 때 저처럼 적당히 타협하느냐 / 가은님처럼 끝까지 해결하느냐의 차이가 결국에는 실력 차이로 나타나는 것 같습니다 ☺️
2-2. 콘솔의 중요성
2-3. 깔끔해진 코드
피드백을 받을 때 기술에 대한 피드백보다 코드 가독성에 대한 피드백이 더 많을 것이며 <- 제가 딱 이랬어요 😂
가독성을 생각했을 뿐인데, 덕분에 더 좋은 코드(좋은 코드, 안 좋은 코드가 어디 있나 싶기도 하지만,) 를 작성하기 위해선 어떻게 해야하나라는 고민으로 이어졌습니다. <- 저도 같은 고민중이에요
짬 좀 찬 시니어 개발자들이 이 고민에 대한 해답을 얻기 위해 '클린 코드' 책을 많이들 보더라고요?
(약간 시니어 개발자들의 바이블 같더라고요 ㅎㅎ)
http://www.yes24.com/Product/Goods/11681152
저는 아직 주니어 && 분량이 방대하고 && 저희가 배운 JS 에도 적용되는 책인지 몰라서 아직 안 샀습니다만... 😂
혹시 가은님도 관심있으시면 제가 사서 강의장에 비치해둘게요 자투리 시간에 슬슬 읽어보아요 우리 🤗