버그 리포팅 🐞 월요일은 버그 리포팅을 진행했습니다. 다른 팀들의 서비스를 사용해보고 어떤 버그가 있는지를 확인하는 방식이었습니다. 저희 팀도 다른 팀들로부터 버그 리포팅을 받았는데, 생각보다 버그가 많아서 놀랐습니다...ㅋㅋ 버그 리포팅이 1시간정도 진행되었던 걸로 기억하는데, 짧은 기간에 짧은 인원이 진행했음에도 불구하고 버그 관련 이슈가 10개 정도 생겼던 것 같습니다. 실제 사용자가 사용하면 더욱 버그가 많을텐데, 테스트 서버 및 QA의 중요성을 느끼는 계기가 되었습니다. 인증 플로우 구현(feat. Oauth2, JWT) 이번주는 기능 개발에만 집중했었습니다. 원래 하루스터디 백엔드 팀원들은 몹 프로그래밍을 자주 했었는데, 이번에는 시간이 부족할 것 같아서 페어 프로그래밍을 진행하게 되었습니다...
6주차는 리팩토링에 집중했던 한 주였습니다 🥲 마찬가지로 회고해보고자 합니다! 슈퍼타입 - 서브타입 제거 한 주가 시작되자마자 가장 먼저 했던 일은 테이블 상속구조를 제거하는 일이었습니다. ERD 설계를 할 때, 확장성을 고려해 슈퍼타입 - 서브타입 관계를 자주 사용했으나, 이에 따른 문제가 많이 발생했기 때문입니다. 우선 테이블 구조를 한 눈에 파악하기가 어려웠습니다. 어떤 정보가 어디에 들어가는지 알기 위해서는 자주 ERD를 확인해야 했던 것 같습니다. 또한, 코드 레벨에서도 상속 구조를 사용하니 캡슐화, 다형성 등 이것저것 신경쓸게 많았습니다. 확장에 유연하게 대응하기 위해서 추상화를 했지만, 추상화를 관리하는 비용이 생각보다 컸던 것 같습니다. 따라서 테이블 상속구조, 코드 상속구조를 모두 제거하..
5주차는 리팩토링 + 버그 수정에만 전념한 한 주였는데요, 마찬가지로 무엇을 느꼈는지 무엇을 경험했는지 회고하고자 합니다. 패키지 구조 변경이번주 들어 가장 큰 변화가 있다면 패키지 구조를 변경했다는 것입니다. 사실 이전까지는 패키지 구조에 대해 신경쓰지 않고 개발을 진행했던 터라, 한번 즈음은 패키지 구조에 대한 고민을 진행해야만 했습니다.// 이전 구조 └── backend ├── config ├── controller │ └── exception ├── dto │ ├── request │ └── response ├── entity ├── exception ├── repository │ └── dto └── service └── dto패키지 구조 변경에 있어 하루스터디 팀의 선택지는 크게 두 가지로 ..
4주차는 처음으로 기획에서 벗어나 개발과 발표 준비에만 몰두했던 시간이었는데요, 여느 때와 마찬가지로 한 주 동안 배웠던 것들, 느꼈던 점들을 작성해보고자 합니다 🥸 페어 프로그래밍 기능 개발을 본격적으로 시작하기에 앞서, 팀원들과 어떻게 개발을 할 지에 대해서 논의하는 시간을 가졌었습니다. 이 과정에서 처음에는 동기화 작업이 우선이니 몹 프로그래밍, 그리고 그 뒤부터는 페어 프로그래밍을 하자! 라고 결론이 났습니다. 그래서 엔티티 설계 등, 동기화 작업이 중요한 경우에는 몹 프로그래밍을 진행했고, 그 뒤 개별적인 기능은 페어 프로그래밍으로 구현했습니다. 분업 방식을 고려하지 않았던 것은 아니지만, 프로젝트의 경우에는 결과물만큼 동기화 과정도 중요하다고 판단했기 때문에 페어 & 몹 프로그래밍으로 진행했습..
벌써 하루스터디 협업을 시작한지 3주가 지났습니다. 시간이 참 빠르다고 느껴지는데 이번에도 어김없이 회고를 하면서 무엇을 했는지, 앞으로는 무엇을 해야하는지를 작성해보겠습니다. 🥸 서비스에서 도구로 사실 이번주에는 대대적인 변경 작업이 있었습니다. 결론부터 말씀드리면, 1차 데모데이때 설명드렸던 기능들을 거의 90% 이상 갈아엎었습니다. 서비스 정체성은 유지하면서 기능은 전부 대체했는데요, 왜 그렇게 되었는지를 아래에 작성하고자 합니다. 하루스터디의 모토는 '짧은 주제의 스터디를 짧고 빠르게, 부담없이' 입니다. 그렇기에 제가 초기에 기획했던 모델은 스터디 모집 서비스였습니다. 짧은 주제의 스터디(쿠키와 세션 스터디 등)는 기존 스터디 패러다임과는 전혀 다르니 용기있게 짧은 주제의 스터디를 개설할 '장'..
2차 스프린트 및 MVP 기획이 드디어 끝이 났고, 이에 따라 저희 팀은 데이터베이스 및 엔티티 설계를 시작하게 되었습니다. 이번 글을 통해 하루스터디의 데이터베이스 설계 과정을 기록하고자 합니다. 데이터베이스 설계는 처음이었지만, 유의미한 경험들을 많이 했다는 생각이 들었기 때문입니다! 😀 요구사항에서 데이터 추출사실 저는 이렇게 규모가 있는 프로젝트에서 데이터베이스 설계를 해본 적이 없습니다. 이전 레벨 1, 레벨 2 미션들에서는 테이블을 먼저 설계하지 않고 도메인 객체를 먼저 설계했는데, 큰 규모의 프로젝트에서는 이러한 시도를 하기보다는 전통적인 Layered Architecture를 따르는 편이 나을 것 같았습니다. 그래서 이런저런 레퍼런스를 찾아보게 되었고, 해당 과정에서 '요구사항에서 키워드를..
하루스터디의 2주 차가 종료되었습니다. 정말 눈 깜짝할 세 없이 하루가 지나가고 있는 것 같아요. 오늘이 무슨 요일인지 까먹을 때도 많고, 엄청 바쁠 때도 많아서 레벨 1, 레벨 2가 그리워질 때도 있습니다.. (그때는 한가했던 거였군요 🙄) 2주 차에도 역시 1주 차와 마찬가지로 기획 과정을 고도화했습니다. 그리고 드디어 개발 문서를 작성하기 시작했는데요, 컨벤션을 만들었고, 기술 스택을 결정했습니다. 이 과정을 하나하나 기록해보고자 합니다!! IA 만들어보기 1주차에 브레인스토밍을 거치면서 여러 기능들이 종합되었는데, 어떤 기능을 구현해야 할지 혹은 어떤 기능은 어떤 기능과 연관이 있는지를 알지는 못했습니다. 즉, 정말 나열만 했던 셈이라 각자가 생각하고 있는 서비스의 모습이 조금씩 다르기도 했고 이..
긴 것 같으면서도 짧았던 레벨 3 첫주차가 종료되었습니다. 그래서 이번 주에 느꼈던 것들, 학습했던 것들 위주로 회고를 작성하고자 합니다. 사실 여태까지는 일일 회고나 주간 회고를 작성하지 않았는데, 협업을 진행하게 되면서 주간 회고도 되게 유의미할 것 같다는 생각이 들어 시작하게 되었습니다..! 우리 모두가 기획자 레벨2 회고에서 언급했던 것처럼, 저는 이번 레벨3 프로젝트의 기획자 역할을 맡게 되었습니다. 그래서 총 7명의 팀원(엽토, 노아, 룩소, 히이로, 마코, 모디, 나)들은 내가 제시한 주제로 프로젝트를 하게 되었는데, 처음에는 걱정이 많았습니다. 기획자라는 역할을 경험해보지 못했기 때문입니다. 사실 제대로 된 협업도 이번이 처음이라, 방학 때 이런저런 걱정이 있었던 것 같습니다. 그런데 레벨..
우아한테크코스 레벨2가 종료되었습니다. 레벨2는 유난히 다사다난했는데, 이 과정에서 느꼈던 점들을 기록하고자 합니다. 저번 레벨 1 회고와 마찬가지로 1. 학습 측면에서의 회고, 2. 생활 측면에서의 회고를 진행하고자 합니다 😀 https://dev-ws.tistory.com/49 우아한테크코스 레벨1 회고 우아한테크코스에 온 지 두 달이 지났고, 현재 방학을 맞이해 회고를 작성하고 있다. 정말 많은 일들이 있었고, 순식간에 지나간 레벨 1이었지만 그래도 보람찼다고 생각한다. 그래서 생활과 학 dev-ws.tistory.com 학습 측면에서 학자와 엔지니어 레벨 2 초반에 코치분들이 자주 하시던 말씀이 기억이 납니다. "스프링은 학습 범위가 넓고, 모든 것을 학습할 수 없으니 필요한 부분만 학습해라. 깊..
예외 객체와 상태코드 분리 지하철 미션을 진행하면서 리뷰어님과 '비즈니스 영역의 예외 객체가 상태코드까지 갖고 있는게 맞는가' 에 대한 이야기를 여기에서 나눈 적이 있었습니다. 그리고 리뷰어님이 실무에서는 어떻게 예외 객체와 상태코드를 처리하는지 보여주셨는데, enum을 통해 비즈니스 계층의 예외와 상태 코드를 표현 계층에서 매핑하고 있는 모습이었습니다. 좋은 방법이라는 판단이 들어서 이번 미션에서 이를 적용해보고 싶었고, enum 객체를 만들어 예외 객체와 상태코드를 공통적으로 관리했습니다. 이를 통해 ExceptionHandler에서 로깅 등의 작업에만 집중할 수 있게 되었습니다. 대략 아래와 같은 형태인데, 자세한 내용은 프롤로그에 작성해두어서 링크도 함께 첨부하겠습니다. public enum Ex..
