[위코드 X 원티드] 프리온보딩 두번째 과제 후기

첫 과제 리뷰

첫 과제가 끝나고 나니 리뷰들이 올라와 있었다.

정말 작성을 잘한 팀이 많았다.

삼일동안 밤새 과제를 하면서 완전 고생했는데 더 잘한 팀이 있는 것을 보고 조금 허탈한 마음이 들긴 했다.

다른 팀이 한 과제를 보고 배운점으로는

• 모두다 깃 커밋메시지가 일관성이 있다는 것
• 리드미에 요구사항, 과제 구현사항, 그리고 팀 이름을 적었다는 것
• API문서화가 포스트맨을 통해 매우 깔끔하게 되어있다는 점
• 외부 사람이 API를 바로 테스트 해볼 수 있도록 포스트맨을 배포했다는 점

그래서 이번 두번 째 과제에 적용하여야 겠다고 생각했다.

두 번째 과제의 시작 - 마피아 컴퍼니

이번에는 5명이서 하나의 과제를 하면 된다고 한다.
두번째 과제로는

• 마피아 컴퍼니
• 프레시 코드 컴퍼니

두 기업의 과제중 하나를 고르면 된다. 즉, 첫 번째 과제보다 부담이 훨씬 적어졌다는 것이다.

마피아 컴퍼니는 그래프 디비(neo4j)를 이용하고, read 는 graphql을 사용하라는 요구사항이 있었고 프레시코드 컴퍼니는 관계형 DB에 기본적인 인증, 인가와 간단한 CRUD가 요구사항으로 있었다.

나는 처음엔 우리가 하기에 '편한 것', '쉬운 것'이 더 좋다고 생각해서 프레시코드 컴퍼니를 해야 할거라 생각했다.
그러나 우리팀은 새로운 기술을 적용해보고 싶어하였다. 즉, 그래프디비, 그래프 큐엘을 사용하는 마피아컴퍼니 회사의 과제를 하고 싶어 했다.
결국 다수결로 마피아 컴퍼니 과제를 하기로 했다.

쉬운 길로 가려고만 한 나 자신을 반성하게 되었다.

드디어 시작!

일단 그래프디비 (neo4j)와 그래프 큐엘이 뭔지도 모두 몰랐기에 팀원 모두 사전 공부를 당일 밤 12시까지 해오자 하였다. (각자)

각자 간단한 CUD를 그래프디비로, R을 그래프큐엘로 적용해서 오면 되는 것이였다.

다들 열심히 각자 공부해서 사전공부해온 내용을 발표했다.
그래프 디비에 대해 구조를 만들어온 내 코드가 선정이 되었고(시작 프로젝트로) 팀원에게 칭찬을 받았는데 기분이 너무 좋았다.

이미 과제를 한번 한 경험이 있기에 걱정이 없었다. 심지어 팀원도 많았기에!!

그렇게 간단한 규칙과, 위키를 사용해서 개발 과정을 적자는 간단한 룰과 함께 각자 역할을 분배하여 작업을 시작하였다.

위기의 봉착

마피아 컴퍼니의 기업과제 요구사항으론

• CUD는 Rest API를 이용
• Read는 GraphQL을 이용

가 있다.

우리는 모두가 일단 두 기술을 공부하기엔 부담스러웠기에 기술별로 역할을 분담했다.

즉,

1. GraphQL을 사용하여 Read API를 만드는 역할
2. neo4j를 사용하여 CUD API만드는 역할

만약 앨범을 CRUD해야한다면, R과 CUD를 분배한 것이다.

각자 작업을 모두 다하고 develop 브랜치에 머지하려는데 엄청난 충돌이 일어났다.
단순한 변수 명부터, 파일 이름도 겹치고, 디렉토리 조차도 겹쳐 충돌이 엄청 일어나서 우린 각자 하던일을 멈추고 모두 다시 모여 충돌을 없애야 했다.(이작업이 거의 1시간 ~ 2시간이 걸림)

우리는 이렇게 충돌 매꾸기 위해 삽질을 하며 처음에 디렉토리 구조라던가, 파일이름, 그리고 겹치는 변수명을 맞춰야 한다느걸 느꼈다.

개발중...

생각보다 간단할 줄 알았는데 개발이 오래걸렸다. 나는 CUD와, 앨범 - 곡, 곡 - 뮤지션의 연결 및 연결 해제 API를 맡아 개발했는데 이게 토요일 새벽 3시에 끝났다. (토요일 오전 10시까지가 데드라인 이였음)

'내가 빨리 작업을 끝내야 Read 개발 맡은 팀이 개발을 완료할텐데'라는 불안감과 조급함을 느끼며 개발하다보니 더욱더 집중이 안되었다.

결국 완료하긴 했지만 팀원에게 너무 미안했다.

포스트맨을 통한 api 문서화 & api 테스트 배포

항상 스웨거를 통해 api문서화를 했는데, 이번엔 포스트맨을 써보았다.
포스트맨은 예시의 api를 모두 만들고 api문서 generator 버튼을 '띡'하고 누르면 API문서가 만들어진다 ㅋㅋ

완전 편했다. !@!@!@

팀원의 탈주,,

우리의 팀원은 총 5명이다. 그런데 한명이 개발도중 개발자가 자신의 길이 아닌 것 같다고 탈주를 하였다.(QA쪽을 하겠다고 하셨는데, 힘들어서 나가신건지 뭔지는 그분만이 아실것... ㅠㅠ)
나는 우리 팀이 모두 끝까지 완주하길 바랐는데, 막상 나가신다고 하니 너무 아쉬웠다..

그래도 우리는 네명의 팀원이 남아있고 정말 마음이 잘맞는 팀원이 남아있어 과제를 완료하는데 있어 지장이 없었다.

그래도 마지막 제출날 10시까지 잠을 안자고 과제를 하였다.(나는 토요일 아침 6시 반부터 8시까지 잠깐 잠들었다... ㅠ,.ㅠ 30분만 자려했는데 한시간 반이나 자버림!!!)

열심히 노력하는 팀원들, 열정있는 팀원과 함께하니 힘들지만 너무 보랍차고 값진 시간이였다.

아쉬웠던 점

• 깃 커밋 메시지

우리는 깃 커밋 메시지 컨벤션을 처음에 맞추고 개발에 들어갔다. 그러나, 그래도 커밋메시지가 따로 노는것 같은 느낌이 들었다.(마지막엔..)

(일관성이 없다고 느꼈다..)

• 리팩토링의 부족

그리고 시간이 부족했기에 리팩토링을 하지 못했다

이슈에 올려놨는데 결국 시간 부족으로 작업하지 못했다.
예를들면 문자열로 하드코딩된 라벨들을 상수로 꺼냈어야 할텐데, 라는 생각을 가지고 있었지만 하지 못했다.

• 단위테스트

나는 db커넥션을 받아와서 단위테스틀 하였다. 그러나 다른 팀원은 모킹을 이용해서 DB에 접근을 하지않고 테스트를 하셨다.
물론 커넥션을 받아오냐 안오냐는 중요한게 아니지만 '내가 만든 기능을 테스트하는 것이 단위테스트'라는 것을 중심으로 생각해보면 굳이 DB커넥션을 받아와서 테스트를 해야하나? 라는 고민을 하게 되었다.

나도 굳이 DB에 해당 데이터가 들어가나 안들어가나를 테스트하고싶은것이 아니면 그냥 모킹 데이터를 이용하는 것이 적절하겠다는 생각을 하였다.

결론

• 팀이 너무좋다. 팀 끼리 너무 잘맞으니 아무리 힘들어도 내겐 재밌는 개발과정 이었다.
• 개발전, 좀더 소통을 하며 개발하자. 그래야 머지할때 심각한 충돌을 막을 수 있다.
• 리드미 업데이트 할 때도 커밋 컨벤션을 맞춰서 커밋하자.
• 아무리 힘들어도 끝까지 최선을 다하자! 중간에 포기하면 이도저도 되지 않는다. 아직 젊은 나이 불태우자!
• 처음 보는 기술이여도 쫄지말자. 일단 직접 손으로 코딩해가며 느끼면 금방 익힌다! 처음보는 cypher 쿼리 문법도 금방 익혔다.