멘토링하면서 깨달은 점
객체에게 책임을 부여시켜서 분리를 한다면 TDD 도 가능합니다.
우리는 그동안 코딩을하면서 API를 설계하고 개발했다. 코딩으로 설계를 할 수 있다 하지만 견고하거나 명확하지 않을 수 있습니다.
명확한 설계가 뒷받침된다면 코딩은 단순히 명확한 설계를 구체화하는 수단이 될 수 있습니다.
과제 발제시간에 발제 코치인 허재님이 말씀하신 부분이 기억이 남습니다.
설계가 명확하면, “코드를 치는 행위” 는 목표를 달성하는 “수단” 이 된다.
설계가 명확하지 않으면, “코드를 치는 행위” 는 불필요한 “노동” 이 된다.
문제 - 이번주차를 지나며 겪었던 문제가 무엇이었나요?
3일이라는 기간에 설계와 API명세서까지 작업하다보니 시간이 부족했습니다.
시퀀스다이어그램을 그리는법을 어려워했고, 대기열 토큰과 스케줄러 처리에 대한 설계를 어떻게 나타내야될지 막막했습니다.
포인트충전, 조회 API 외 다른 API들은 어떻게 설계 해야될지 막막했습니다.
ERD다이어그램에서 많은개수로 테이블로 서비스를 나타내면 복잡해질 수 있다는 말에 혼란을 가졌습니다.
어려웠고 금방 지쳤다…
사실 너무 설계가 어렵고 방향이 맞는지 알수없어서 금방 지치기도하고 포기하고 싶었던적이 있었습니다.
(젭의 네임에 (멘붕) 이라고 적었습니다…. ㅠㅠ)
시도 - 문제를 해결하기 위해 어떤 시도를 하셨나요?
최대한 코치님이 지도해주신 방향으로 했습니다.
- 시퀀스다이어그램의 경우, API 단위에 맞춰서 컨트롤러/서비스/래포지토리 로 나타냈고, 기존에 했던 방식을 모두 수정했습니다.
혼자 고민하기에는 너무 난이도가 높아서 선배기수들은 어떻게 해결했는지 서칭을 해봤습니다.
팀원들에게도 ERD 다이어그램 피드백을 요청했습니다.
해결 - 문제를 어떻게 해결하셨나요?
- 시간부족 / 멘붕상태로 포기하고 싶었던 마음에 대한 문제 해결
시간부족의 문제는 어쩔수없이 악으로 깡으로 시간을 떼워서라도 버텼습니다.
최대한 잠을 줄여서라도 제출상태여도 필수구현위주는 해결했습니다.
실제 과제전형이라면… fail각이지만, 그래도 최대한 미션을 수행해보고싶다는 욕심이 컸습니다.
멘붕상태인데… 학습메이트 지수님과 재형님 준상매니저님이 걱정해주시고 응원을 해주셨습니다.
무엇보다도 힘든와중에도 새벽까지 젭에 접속해서 묵묵히 과제를 수행하고 있는 팀원들(준규님, 형재님, 유진님, 민수님, 찬희님, 도희님)의 모습에 포기하지말고 끝까지 해보기로 힘을 내서 어찌저찌 해결했습니다…ㅎㅎ
- 스웨거 문제 해결
부랴부랴 기본과제를 마친뒤 기한이 얼마남지 않은 상태라서, API명세서(swagger)는 어떻게 작성해야될지 막막했습니다.
운이 좋게도 늦은시각에 학습메이트 예진님이 계셨습니다! 예진님께 스웨거 작성하는 방법을 여쭤봤습니다.
예진님이 링크로 접속해서 swagger를 올리는방법 설명을 해주셨고 예진님의 덕에 스웨거만드는 방법을 터득했습니다.
혼자서는 힘들었는데 주변에 같이 함께할 사람이 있어서 혼자했을 때보다 원만히 해결이 됐던거 같습니다! 고마워요 예진님 :) !!
알게된 것 - 문제를 해결하기 위해 시도하며 새롭게 알게된 것은 무엇인가요?
개발자는 코드를 잘작성하는것보다는 명확한 설계가 중요하다는걸 몸으로 직접 경험했습니다. 명확한 설계의 바탕으로
느낀점
개발에는 정답이 없다고하지만 난이도가 너무 어려운 경우에는 사람을 잘활용하는 것도 좋은거같습니다. 변경이 있다면 설계문서도 같이 업데이트를 해야될거같습니다.
이러한 설계문서가 있어야 개발의 방향성이 생기고, 타인에게 시스템을 설득할 수 있는 강력한 효과가 있습니다.
설계를 잘해보려면 많이 설계하는 경험이 축적되야함을 깨달았습니다. 주니어레벨이더라도 직접 서버를 구축해보는 경험이 필요하단걸 느꼈습니다.
멘토링에서는 시퀀스다이어그램, ERD 다이어그램이 중요하다고 했으나, 상태다이어그램/플로우차트/클래스다이어그램 등 다양한 다이어그램들도
같이 했다면 서비스가 더 명확해질것 같습니다.
개발자로서 지내본 결과, 그리고 항해에서 코치진을 비롯한 선배개발자들의 말씀을 들어보면
개발은 단순히 코드로 만들다기보다는 설계와 문서화로 그리고 말로 타인을 설득하는 능력이 더욱더 중요하다는 걸 알게됐습니다.