web

[좋았던 점] - PM을 중심으로 원활하게 소통되는 것이 좋았습니다, 어려웠던 점은 없습니다. - 온라인 활동이라서 소통하는 것에 자유도가 높았다는 생각이 듭니다. - 매우 리더십이 뛰어난 팀원이 계셔서 소통하는 과정에서 수월하였습니다. - 다만 서로 막히는 부분이나 어려운게 있으면 2명씩 따로 대화를 하며 문제를 해결 해 나가려고 노력한 점이 소통에서의 잘한점이라고 생각합니다. - 채팅으로만 소통하는 것이 아닌 디스코드를 통해 음성으로 소통을 하다보니 좀더 적극적이고 자세히 피드백을 해줄 수 있었던것 같았다. [어려웠던 점] - 대답이나 반응이 잘 없거나 글을 남겨도 답변이 잘 돌아오지 않는 상황이 있어서 이 점이 어려웠습니다. - 어려웠던 점은 지금 각자 어떤 작업을 하고 있는지에 대한 소통이 가장 어려웠습니다. - 어려웠던 점은 다 같이 회의를 할 때, 마이크 소리가 서로 겹칠까봐인지 팀원들이 말을 많이 하지 않았던것 같아서 그게 아쉬웠습니다. 아마 오프라인으로 만나서 했다면 더 소통이 쉬웠을 것 같습니다. - 각자 의견들을 많이 내줘서 선택과 생각의 폭이 넓었습니다, 온라인으로 소통하다보니 오프라인보다 비언어적인 요소나 직접적인 소통이 어려워서 답답할 때가 있었습니다.

[web팀을 향한 칭찬] - SpringBoot 3.x쓴점 좋습니다. - 지도 기능이 있어서 좋네요. - 버킷 리스트를 올리고 신청 수락하는 과정을 알림으로 처리해서 흐름을 잘 구성하신 것 같습니다. - 채팅방에 연결까지 잘 하셨습니다. - 전반적인 완성도가 뛰어난 팀입니다. - 채팅 내역 저장하는 부분 비동기 구현한 아이디어가 좋네요. - 많은 시도를 했고 구현을 잘 하셨습니다. - 기획의 볼륨은 좁지만 여러가지 고민이 많이 녹아든 프로젝트입니다. - 채팅과 같은 구현이 완성도 높게 되어 있고 커뮤니티 기능도 우수한 편입니다. - Nginx와 리버스프록시 https를 적용한 것이 눈에 띄네요. - 지도 연동도 잘 하셨고 캐싱과 같은 것도 추가한 것이 재밌네요. - 커밋 규칙도 일관성 있게 잘 따른 것으로 보입니다. Git Flow와 비슷한 브랜칭 전략을 사용한 것으로 보이네요. front와 back을 나누려고 시도한 것이 좋습니다. - 서비스 흐름이 사용자가 느끼기에 자연스러워서 좋았습니다. - 알림 처리와 클릭 시 확인이 가능하게 처리한 것과 채팅방 구현, 지도 API를 적용한 게 좋았습니다. - 발표도 집중도 끌어올수있게 잘 해주셨고 채팅기능에서 디테일한 부분도 잘 해주셨고 비동기처리를 위해 진행한 부분도 좋았음(퇴장 기능 디테일 좋았음) - 발표자료에 문제 도출 및 해결 방안을 제시한 부분에서 그간 많은 고민을 해오며 개발에 몰두하신게 보였습니다. - 백엔드 개발에만 집중하기에도 바쁘셨을텐데 프론트단 코드 중복 해결을 위해 axios interceptors까지 고려하신점 좋았어요. 또 반응형 웹으로 까지 잘 구현해주셨네요. - 백엔드 프로그래밍을 배우며 프로그램이 어떻게 돌아가는지에 대한 감이 생겼기에 가능했던 일이라고 보여집니다. 앞으로 회사에 가시게 되면 처음 보는 기술을 접할 기회가 많아질텐데 잘 이해하고 수용할 수 있는 멋진 개발자가 되셨으면 좋겠습니다! - 반응성이나 전반적인 서비스 품질은 좋음 - 전반적으로 무난하게 적절한 기술들 다양하게 활용해서 잘 개발 하였음! - 재미있는 주제로 적절한 개발 범위 내에서 무난히 개발을 진행한 것 같습니다. "에어 플래닝 " 팀(4조)과 구조적으로 서비스가 유사해 보이나 백엔드 커리큘럼 특성상 비슷한 프로젝트처럼 보이는 부분이 많은 것 역시 인지하고 있습니다. [web팀에게 드리는 피드백] - 캐싱을 했는데 속도가 약간 아쉽네요. - 코드 가독성에서 좀 더 개선이 가능해 보입니다. 메서드명들이 명확하지 않은 것들이 자주 보입니다. - Issues를 버그 트래킹을 위해 사용할 수 있습니다. 프로젝트 기능 개발 후 버그 리스트를 Issues에 기록, 해결하며 지속적으로 소프트웨어의 품질을 개선하고 프로젝트 관리를 효율적으로 진행 할 수 있습니다. - 요청 유효성 체크 및 테스트도 더 추가해보시고 Jacoco, SonarQube를 수행해보시면서 차별화된 기능들을 더 추가해보시면 완성도가 더 높아질 것으로 보입니다. - RESTful한 URL이 무엇인지 고민해보면 좋을 것 같습니다. - 버킷리스트인데… 그냥 여행/트립 서비스 같음. 그래서 정체성이 살~짝 모호해짐. - 스웨거로 API 만든것. 스크린샷에 내용은 적지만 설계적으로 매우 치명적인 실수들을 많이 하였음. URI를 잘 설계하는 기법 꼭 찾아볼 것, 단수형/복수형 경로명 등등 경로에 POST 등의 메소드가 안나와야 함. (URI 컨벤션들이 너무 많이 틀림) - [기획] 기획과 관련한 피드백은 아래와 같습니다. 1. 메인 페이지에서 버킷 리스트 항목 보여줄 때 개인화가 안되어 있는 점은 조금 아쉽습니다. 메인 화면에는 결국 내가 관심있는 카테고리의 항목들만 보이는 것이 조금 더 바람직한 기획이 아닐까 생각합니다. (로그인하지 않았거나 개인화를 위한 데이터가 수집이 덜 된 상태라면 지금처럼 보여지는 것이 맞습니다) - [개발] 개발과 관련해서는 다음과 같은 피드백을 드립니다. 1. 짧은 시간 내에 많은 걸 구현하려고 노력한 부분이 엿보입니다. 긍정적으로 평가합니다. 2. 개별 서비스 구현을 위해 많은 시도와 시행착오를 겪은 부분을 기술한 내용도 매우 긍정적으로 평가합니다. 3. Swagger 외에도 조금 더 다양한 개발 지원 도구들을 사용해볼 수 있었으면 더 좋았을 것 같습니다. 4. 채팅 메시지를 비동기 저장한다고 했는데 사용자의 다양한 통신 환경을 고려했을 때 절대적 시간을 중심으로 하는 "엄격한 " DB 저장 보다는 백엔드 로직의 복잡도나 서버 로드 관점에서 더 다양한 솔루션들을 살펴보는 것도 권해봅니다. 5. API를 문서화 하는 것 자체도 중요하지만 내가 어떤 목적으로 API를 문서화 하는지, 어디까지 공유하는지도 함께 고려하면서 문서화 도구를 사용하면 더 좋을 것 같습니다. - 다음은 모든 팀에 공통으로 적용되는 피드백입니다. [발표자료] 주요 기능을 설명할 때 기능(function) 위주의 설명 보다 사용자 시나리오(user scenario) 위주의 발표 자료 작성이 더 효과적입니다. [개발] 해커톤 프로젝트는 핵심 기능이 아니라면 가능하면 기존 서비스를 최대한 이용하는 것이 MVP 관점에서도 유리합니다. (캘린더, SNS 등) [WBS] WBS를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다.