공통프로젝트 회고 (200713 ~ 200821)

길다면 길고 짧다면 짧은 6주간의 프로젝트 여정이 끝났다. 기억을 더듬어 프로젝트에서 무엇을 했고, 어떤 생각들을 했는지 정리해보려 한다.

프로젝트 소개

와플 Waple : 우리만의 플레이스

한개의 와플 빵 위에 각자의 취향에 맞는 토핑을 올려 먹듯,
하나의 지도에 모임별 기록을 담아내는 와플 서비스!!!

사용 기술

  • FrontEnd
    • Vue.js
    • Vuetify
  • BackEnd
    • Spring Boot
    • MyBatis
    • MariaDB
  • 관리
    • git
    • JIRA
    • AWS

개발기간

2020.07.13 ~ 2020.08.21

개발자

백엔드 2, 프론트 1


해본 것

프론트엔드 담당

나는 프론트 담당을 하기로 했다
프론트와 백엔드를 둘 다 해보긴 했지만, 역시 프론트가 조금 더 재미있어서 선택하게 되었다.
팀원은 5명 정원에 비전공자가 한 명 이상 있어야 했다.
그래서 우리 팀은 백엔드 2명(전공2) 프론트 3명(전공1비전공2)이었다.
하지만 비전공자 2명이 취업으로 나가는 바람에… 프론트 담당이 한 명이 되어버렸다.

컨설턴트님께서도 우리 프로젝트는 프론트 할 게 많으니 백엔드 담당자들이 빨리 개발을 마치고 프론트로 넘어와야 한다고 하셨다.
어떻게든 혼자 할 수 있는 만큼 많이 해보려 했는데 생각처럼 잘 되지 않아 아쉬웠고 내 자신에게 짜증이 났다.
그래도 후반엔 백엔드 친구들이 많이 해주어서 다행히도 기본 기능은 끝낼 수 있었다.

Vue.js & Vuetify

Vue.js와 BootStrap을 사용하는 경우도 많지만, 뷰에 최적화된 뷰티파이를 사용해보기로 했다.
확실히 태그 하나만 넣어도 요소들이 예쁘게 생겼다.
제일 많이 쓴건 모달창, <v-dialog>인 것 같다.
우리 웹 사이트가 일반 사이트랑 다르게 레이아웃이 조금 독특했다. 네이버나 카카오 지도를 생각하면 쉬울 것 같다
그래서 입력을 받거나 내용을 보여주는 부분 대다수를 다이얼로그로 처리하였다.
분명 편한 점도 있었지만 커스텀 디자인을 넣을 때 잘 안 될 때도 있었다.
크롬 개발자 도구로 레이아웃을 정말 많이 뜯어본 것 같다..
크롬 개발자 도구 만세 !

scrum

아침마다 팀별로 모여 스크럼을 진행했다.
컨설턴트님께선 회의가 아니니 의견을 나누기보단 오늘 하루 자신이 무엇을 할 것인지 이야기하는 시간이라고 매번 강조였다.
처음엔 말하다보면 회의로 빠지곤 했는데 어느 순간부턴 5분이면 끝났다.
스크럼 전에 내가 할 일을 머릿 속으로 정리해보아도 말하다 보면 까먹는 부분이 있을 것 같아 구글 시트를 만들어 간단하게 적은 뒤 스크럼을 진행하였다

scrum
해야할 일에 비해 적은 한 일 개수.. 모든 게 계획처럼 흘러가진 않는다

코딩 컨벤션

js 코딩 컨벤션 중 에어비엔비 것이 유명하다 하여 사용해보았다.
문서를 읽어볼 때는 당연히 이렇게 써야 하는 거 아냐? 하는 것들이 많았는데
막상 사용해보니 어렵고 귀찮은 것들이 너무 많았다..
기억에 남는 것들을 적어보겠다

  • 단항 연산자 사용하지 않기
    • i++ 대신에 i += 1을 사용해야 했다.
    • 처음 for 문을 사용했을 때 오류가 나서 많이 당황스러웠다.
  • 라인, 띄어쓰기 관련
    • indent는 2의 배수로 (코드 복붙해올 때 제일 많이 났던 에러였다)
    • 한줄에 최대 100글자
    • 빈 라인에는 띄어쓰기도 쓰면 안 됨
    • 두 줄 이상 빈 라인 안 됨
    • 끝난 문장 뒤에 띄어쓰기 쓰면 안 됨
    • 파일 맨 마지막에 빈 줄 하나 꼭 필요함
  • 모든 문장이 끝날 때 세미콜론 써주기
    • <script> 부분에 export default 끝에도 세미콜론을 써주어야 했다..
  • if문, for문 등은 조건식 괄호와 한 칸 띄어쓰기를 해주어야한다
    • if(조건식) X
    • if (조건식) O
  • 중괄호 안에 넣어진 데이터들은 띄어쓰기를 해주어야 한다
    • {data} X
    • { data } O
  • arrow function 관련
    • 오류가 나면 나는대로 검색하고 수정했다..
    • javascript를 더 많이 공부해야겠단 생각이 들게 한 부분

하나라도 안 지키면 빨간 색으로 에러 메세지가 뜨는데 그게 너무 짜증날 때가 종종 있었다.
고민하여 코드를 적고 저장을 누른 순간 에러가 떠서 내 코드가 뭐가 잘못됐나..? 걱정되는 마음으로 메시지를 보면 indent 에러라던가.. 맨 뒤에 띄어쓰기가 있습니다 라던가…..(눈물…)
하지만 확실히 모든 팀원이 코딩 컨벤션을 지키니 코드 읽기도 수월하였다.
(팀원들이 동의해준다면) 다음 프로젝트에서도 또 사용할 것이다.

git flow

git flow를 검색하면 우아한 형제들에서 작성한 글을 제일 먼저 발견할 수 있을 것이다
우리도 이 글을 참고하여 각자의 레포지토리에 포크 뜬 뒤 원본 레포 브랜치에 풀리퀘를 보내려 했다.
하지만 깃랩에서는 한 레포 안에서 멤버 초대가 가능했기 때문에 각자 작업하는 브랜치를 두고 머지리퀘스트를 보내는 것으로 수정하였다.
master - develop - feature 순으로 브랜치를 생성하였다
feature_기능명으로 브랜치를 생성했는데 프론트 쪽은 기능별로 브랜치 나누기가 되게 애매하다고 느꼈다.
왜냐면 한 페이지를 만든다고 했을 때, 그 페이지 안에 여러 기능이 들어가있을 수 있기 때문이다.
그래서 브랜치를 JIRA 스토리별로 브랜치를 만들기로 했지만 백엔드는 잘 되었지만 프론트는 잘 지키지 못하였다.
다른 데에선 어떻게 하는지 궁금해지는 부분이다.

git-flow
팀원들과 열심히 가꾼 git graph

JIRA

이번 프로젝트를 하며 JIRA를 처음 사용해보았다.
UI/UX가 조금 불편했지만 확실히 사용하니 좋은 점들이 있었다.

  • 커밋 메시지에 이슈 번호를 남길 수 있다
    • 어떤 이슈에 대한 커밋인지 쉽게 알 수 있었다
  • 다른 팀원이 어떤 일을 할 것이고, 했는지 알 수 있다
  • 사이트에 오류가 있을 때 담당자에게 버그 수정에 대한 것을 쉽게 전달할 수 있다


느낀 것

개발 측면

  • 자바스크립트 기초가 부족한 것 같다.
    • 부족한 상태에서 자꾸 뭘 쌓아올리니 실력이 늘 수가 없는 것 같다.
  • 프론트 담당이지만 백엔드도 알아야 한다.
    • 당연한 이야긴데 조금 벅찼다..
    • 다음엔 벅차도 더 노력해봐야지..
  • 기능 구현도 어렵지만 화면을 어떻게 구성할지도 어려웠다.
    • 디자이너의 중요성을 새삼 또 한 번 깨달았다..
    • 확실히 뷰티파이를 사용해서 별다른 css를 주지 않아도 예쁘긴 했지만 그래도 아쉬운 부분들이 있다
  • 세상엔 다양한 라이브러리가 존재한다
    • npm install의 세계란 무궁무진하단 걸 느꼈다.
    • 이런 라이브러리를 한 번 만들어보고 싶단 생각을 했다.
    • 그런데 하나 쓸 때마다 조금 고민을 했다.
      • 너무 따다 쓰는건 아닌지? 내가 안 만들어도 되는지?
      • 실제로 v-snackbar를 사용했었는데, 인터넷을 돌아다니다 다른 누군가가 만들어둔 더 예쁜 알림창을 발견했고 그것으로 변경하였다.
      • 내가 짠 코드가 다 날아가서 슬펐지만.. 너무 예뻤다..
      • 하지만 이렇게 다 따다 쓰면 내 코드는 뭘까? 하는 고민도 하게 됐다
    • 하지만 가져다 쓴다고 해서 항상 쉽게 사용이 되는 건 아니었다..
      • 개발자분들이 써둔 문서를 잘 읽자…

협업 측면

  • 의사소통은 역시 중요하다
    • 이번 프로젝트는 의사소통이 잘 되어서 좋았다.
    • 온라인이라 아쉽긴 하지만 이정도면 훌륭했다.
  • 역할 분담
    • 위에도 적었듯이 백엔드 친구들이 프론트를 많이 도와주었는데, 고마우면서 미안했다.
    • 내가 해야 할 부분인데 못 끝내고 일을 주어야 한다는 게..
    • 하지만 믿을만한 친구들이고, 잘 구현해주어서 좋은 사이트를 만들 수 있었다고 생각한다.
    • 그치만 내가 더 잘했으면 좋았을 텐데 하는 생각은 어쩔 수 없다.

기타

  • 잘 하는 사람이 너무 많다.
    • 남들과 비교하는 게 좋은 건 아니란 건 알지만, 자꾸 비교하게 된다.
    • 나 스스로를 위해서 더 노력해서 좋은 개발자가 되어야지 자극이 된다.


다짐

꾸준히 기록하기

이번 프로젝트를 시작하며 기록을 열심히 하려고 했다.
실제로 노션에 열심히 작성하려 했다.

record
예쁘게 잘 꾸민 것 같다. 하지만 제목만 있고 내용은 없는 것들도 꽤 된다

근데 중후반쯤 되니까 기록하는 것에 소홀해지게 되었다.
머리속으론 ‘아.. 이거 기록해두면 좋을 것 같은데..’ 생각만 하고 실행에 옮기지 않은 것이다.
그리고 쓸 때 당시엔 ‘와 이거 기록 대박인데’ 했던 것도 다시 보면 별 거 아닌 것들도 있었다.
하지만 어쨌든 다 내가 궁금해했던 것들을 찾아본 것들이고, 내가 해본 것들이니까 기록하고 공유하면 좋을 것 같다.
새 프로젝트에선 좀 더 행동으로 옮겨봐야겠다.

코드 리뷰하기

머지 리퀘할 때 한 번씩 코드를 보긴 했지만 정말 보는 것에 그쳤다.
그래도 종종 지워서 안 될 코드라던가 (폰트 적용이었지만..ㅎㅎ) 등등을 발견하고 새로운 코드들도 볼 수 있었다.
그리고 어마어마한 쿼리문들까지….
머지리퀘스트 전에 좀 더 주의깊게 다른 팀원의 코드를 보고 머지할 수 있도록 이야기 나누어봐야겠다.


회고를 마치며

처음 해보는 프로젝트 회고라 이게 맞는진 모르겠지만, 맞고 틀리고가 어디있나. 일단 해보는 거지 뭐
다음 프로젝트에서도 일단 해보자 라는 마인드로 열심히 해봐야지..
수상을 못 한 게 아쉽긴 하지만.. 수상작들을 보면 또 납득이 간다.
대략 3일 정도 이 회고를 썼지만 또 생각나는게 있으면 중간중간 수정하러 와야지 ㅎㅎ
우리 팀원들이 이걸 볼 지 모르겠지만 다들 수고 많았어~~~ 빨리 만나서 쫑파티 할 수 있는 날이 왔으면 좋겠다