내일배움캠프 94일차

회의

아침 회의를 3분만에 끝냈다. 회의 안건을 미리 준비한 후 회의 시작 했을 때 빠르게 전파하고, 특이사항 없다는 것을 확인 후 각자 다들 일을 할 수 있도록 회의 마쳤다. 

 

개발

튜터님 피드백

피드백 사항 중 하나인 "댓글에 작성자 표기" 기능 구현에 착수했다. 

다른 팀의 코드를 참고해서 작성했다. 중간에 CascadeType.Remove와 CascadeType.All이 궁금했다. 찾아보니 이해를 하기 위해서는 시간을 더 투자해야 하는 것 같았다. fetch = FetchType.LAZY / Eager도 찾아봐야 했다.

 

다른 팀원이 튜터님께 다른 "엔티티" 불러오는 것과 관련해서 질문 후 나도 질문했다. 질문은 "CascadeType.Remove와 All 차이가 뭔가요?" 튜터님께서 자기가 설명 해주는 것보다 직접 CascadeType.Remove와 All을 코드 작성해서 차이점을 비교 해보는 것이 이해에 가장 도움이 된다고 말씀하셨다. 

 

그래서 내가 "최종 발표일까지 시간이 없어서 마음이 급해서 이런걸 찾아보기가 부담스럽다고 말씀드렸다. 이런 걸 찾아보면 파는 것이 한도 끝도 없고 마감 기한은 얼마 안 남아서." 

 

튜터님 왈 "이 기간은 지난 발표 후 부족한 부분을 여러분들이 프로젝트를 완성 해나가며 학습하는 기간이니까, 학습하는 것이 맞다. 다만, 현재 시간에 쫓겨서 모르는 것을 어디까지 파야할지 모르겠다면, 최소한의 지침은 CascadeType.Remove를 쓰는데 모른다면 그것을 알고 가는 것이 좋다."

 

구현

댓글 작성자 표기를 성공했다. 그런데 프론트에서 예쁘게 표시하려니 또 다양한 템플릿을 찾아봐야했다. 백엔드 개발자를 지향해서 프론트를 덜 신경써야지 하면서도 현 UI를 보면 "너무 성의 없어보이나?"하며 마음에 갈등이 생긴다.

 

그래서 정한 것이 최소한의 UI만 갖추고, 백엔드 기능을 다 갖추었을 때 UI를 손보자 이다. 백엔드 개발자를 지망하지만, 가장 큰 목표는 "개발자"이며, 개발자는 주어진 과제를 구현하는 사람이 아닌가? 회사에서 백엔드가 아닌 최신 기술(미래의 상상할 수 없는 기술)을 도입 하는데 나보고 하라고 하면 "저는 백엔드 개발자인데요?" 라고 말할 수 없는 없지 않은가. 

 

깃헙

팀원들과 시간을 투자해서 깃헙의 wiki를 작성하는 시간을 가졌다. 다른 항해99 wiki와 노션을 참고했다. 

나는 우리 프로젝트의 기능을 소개하는 페이지를 맡고, 다른 팀원들은 "API"과 "개발 규칙 및 문화"를 맡으셨다. 팀원들에게는 내가 맡은 주제보다 더 어려운 주제를 드렸다. 쉬운 것보다는 어려운 것을 작성하는게 팀원들 성장에 더 도움이 되지 않을까 싶어서이다.