댕냥 ffㅗ짝

[좋았던 점] - 팀 분위기도 좋고 다들 적극적이라 소통하는데 문제가 없었습니다. - 오프라인이 아니라 디스코드나 슬랙에 없으면 바로바로 물어 보는게 어려웠지만 사소한 질문이라도 다 받아주시는 팀원들 덕분에 실력도 많이 늘었는 것 같습니다. - 시간에 구애받지 않고 누구한테든 궁금한점 생기면 바로바로 디엠을 보내거나 허들로 대화 나눌수 있는 점이 가장 좋았습니다. 중간에 노션을 통해서 매일의 진행상황을 공유한 점도 좋았습니다. - 어디까지 또 언제까지 할 것인지에 대한 명확한 기준을 세워놓지 않았기 때문에 소통의 왕래가 없었는데 딱 기준을 세워 놓고 진행하니 훨씬 소통도 잘되고 좋았어요! 이렇게 말을 많이 할 수 있었구나 질문을 잘받아주었구나 라는 생각을 할 정도로 ^^ 너무 좋았습니다! [어려웠던 점] - 어려웠던 건 팀 회의하는 등 개발 외적인 부분에 시간이 많이 들어가 예상했던 개발 완료일보더 조금씩 늦춰져서 아쉬웠습니다. - 처음에는 서로 뭘 하고 있는지 공유가 자연스럽지 못했던 것 같습니다. 하지만 문제를 찾고 방법을 찾아나가려고 대화를 하고 풀어나가려는 노력이 좋았습니다. - 초반에 소통이 조금 어려웠었습니다. - 저희 팀은 욕심도 있었고 소통도 잘되서 좋았는데 프론트엔드를 담당하며 많이 힘들었습니다...

[댕냥🐈 ffㅗ짝🐕팀을 향한 칭찬] - 복잡한 기능 구현에 도전한 점을 응원합니다. - 기록을 관리하고 공유하는 기능이 복잡한 기능이지만 구현하려고 노력하신 것 같습니다. - 기획한 내용들을 잘 구현한 것으로 보입니다. - Jacoco와 SonarQube와 같은 테스트와 정적 분석을 활용해서 커버리지를 확인하고 코드스멜을 줄인 것도 잘하셨습니다. - 특히 캘린더 기반 서비스를 제공할 때, 논리적 구조를 짜기도 어렵고 화면에 표시하는 로직을 구성하기도 어려운데 굉장히 잘 구현하신 것 같네요. - 전반적으로 완성도가 뛰어나보입니다. 배포상의 에러만 해결하셨으면 좋겠습니다. - 문서화 기능도 잘 사용하신 것 같아 좋았습니다. - 코드 구성이 명확하고 가독성이 높은 것으로도 보여요. 커밋 규칙도 잘 지켜지고 있구요. - Github Flow를 활용한 것으로 보이는 브랜칭 전략까지 각 브랜치 앞에 이슈티커를 기재하시고 잘 작업을 진행한 것으로 보입니다. - 전체적으로 복잡한 구조임에도 불구하고 기능 구현을 잘 하셨습니다. 또한 REST Docs, sonarQube, FCM 등 다양한 기술을 시도한 것도 칭찬하고 싶습니다. - 반려동물 타겟해서 귀엽게 프로젝트 잘 꾸며주셨습니다 - 여타 다른 SNS와의 연동도 잘 되면 좋을것 같고 공유기능도 되면 좋겠음 - 캘린더 기능 깔끔하게 잘 구현해주었음 - RTR 도 적용해서 token활용한 인증을 많이 고찰한 것 좋았음 - 배포 이후 버전 업그레이드 시 다운타임을 고려해 무중단 배포를 구현하신게 좋았어요. - 인프라 쪽으로 많은 고민을 하느라 개발시간이 부족했을텐데 좋은 결과물이 나왔네요. 댕냥뽀짝!!!! 화이팅입니다~! - 유용하고 재미있는 주제를 선정한 팀입니다. [댕냥🐈 ffㅗ짝🐕팀에게 드리는 피드백] - 배포되었을 때 사이트가 잘 작동이 하지 않는 점은 아쉽네요. - 아마 캘린더 서비스 개발, Rest Docs에 많은 시간이 소요되었을 것 같은데 다른 실 사용자들을 위한 더 좋은 기능들을 추가해 PWA 등을 적용한다면 실 사용자를 모을만한 애플리케이션도 될 수 있어 보입니다. - 확인해보니 프론트엔드도 부트스트랩으로 반응형 구조가 되어 있는 것 같아요. 따라서 서비스 워커를 설치하고 메니페스트 등을 작성해서 PWA로 앱을 만들었을 때 서비스 운영을 해보는 것도 좋아보이네요. - 주석처리에 javadoc 등을 활용하시는 것도 검토해보시면 좋을 것 같아요. - 요청 유효성 체크와 인프라 구조를 더 신경 쓰시면 바로 프로덕션 환경 운영이 가능할 것으로 보이는 프로젝트입니다. - AWS ELB 적용을 고려해보면 좋을 것 같습니다. - 무중단 배포 전략은 세가지(롤링/블루-그린/카나리)가 있는데 각 각의 장단점이 있으니 공부해두시면 좋습니다! 그리고 FCM, Jenkins 사용 경험은 앞으로도 많은 도움이 될거라 생각합니다. - 프런트가 다소 많이 아쉬움. 반료동물 일지 작성도 구글캘린더 같은 형태라 아쉬움이 있고, 요즘 SNS처럼 인스타 형태가 가장 일반적인 실제 상용화 된 서비스의 형태인지라 (유사 서비스를 많이 찾아보고 벤치마킹 해볼 것) - 사용자가 수동으로 입력해야 할 필드들이 너무 많아 사용성(UX적) 인 고려가 함께 되면 더 좋고, 요즘은 백엔드 개발자라도 서비스의 컨셉과 사용성까지 고려하며 개발 하는것이 이런 서비스 개발의 트랜드라 고민해볼 것. - gitlab, jenkins, sonarqube 는 또 ec2에서 별도로 다 구동하고 있는데, 이런것을 다 gitlab 하나로 대체 할 수도 있는지라 통합 고려. 또한 push 알림 등도 aws에도 기능들이 있는데 굳이 firebase 를 사용해서 알림전달을 한다거나 과도하게 많은 서비스 컴포넌트를 통해 쉬운 서비스를 다소 어렵게 구현하였음. (nginx 리버스 프록시도 aws elb 로 대체 할 수도 있고, 아니면 전체를 도커 컨테이너로 배포 하거나, 여러가지 방안이 있음.) - 서비스 개발 중 레디스 해킹 관련 언급이 있었는데, 일단 매우 좋은 경험이고, 해당 경험을 기반으로 보안성에도 꼭 신경을 쓰는 백엔드 개발자가 되길 바람.. (또한, 더 크게는 애초에 접근제어를 통한 설계단계에서부터 보안성을 고려해볼 것. 개발 이후가 아닌 개발 이전..) - 개발을 잘 하고도 개발한 내용물을 잘 포장해서 설명하지 못하면 우리가 얼마나 열심히 했고 얼마나 많은 일을 했는지 전달하기 어렵습니다. - 다양한 기술과 다양한 툴을 통해 재미있는 서비스를 만들었다는 것이 발표 자료에서는 충분히 느껴지고, 기술 스택이나 개발 과정에 대한 자세한 설명 대비 프로젝트나 서비스에 대한 설명 부분이 조금 부족하지 않았나 싶습니다. - [기획] 기획 관점에서 향후 보완이나 추가가 필요하다고 판단되는 부분은 아래와 같습니다. 1. 반려견 "주치의 " 개념을 도입해보거나 기타 동물병원과의 연계를 통한 수익 창출 방안을 추가로 모색해보는 것도 좋을 듯 합니다. 충분히 확장성이 있는 서비스입니다. 2. UX가 다소 복잡해서 다이어리나 기타 정보를 생성하고 교환하는 사용자의 경험이 "즐거운 것 "이 아닌 "일 "처럼 느껴지는 부분이 조금 아쉽습니다. 정보를 생성하고 교환하는 사용자의 경험을 조금만 더 개선시킬 수 있다면 충분히 좋은 사업 아이템이라고 생각됩니다. - [개발] 다음과 같은 부분은 개발 관점에서 아쉬웠습니다. 1. 전체적인 서비스 UX로 선택한 캘린더뷰가 사용성 측면에서는 기존 우리에게 익숙한 다른 서비스 UX에 비해 조금 불편해보입니다. 일반적인 타임라인 뷰 형식을 띤 스토리 형식이었더라도 좋았을 것 같습니다. 2. 알림과 일정은 왠만하면 별도로 개발하기 보다는 MVP 차원에서 기존 사용자 플랫폼 이용하는 것도 MVP 관점에서는 어땠을까 하는 아쉬움이 있습니다. 3. 서비스 안정성 4. 낮은 완성도 (동작하지 않거나 완성도가 낮은 feature들이 사이트에 제법 보입니다) - [개발] 다양한 기술들을 적용하면서 동시에 아래와 같은 시도를 한 것에 대해 긍정적으로 평가합니다. 1. 무중단 배포 - 다음은 모든 팀에 공통으로 적용되는 피드백입니다. [발표자료] 주요 기능을 설명할 때 기능(function) 위주의 설명 보다 사용자 시나리오(user scenario) 위주의 발표 자료 작성이 더 효과적입니다. [개발] 해커톤 프로젝트는 핵심 기능이 아니라면 가능하면 기존 서비스를 최대한 이용하는 것이 MVP 관점에서도 유리합니다. (캘린더, SNS 등) [WBS] WBS를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다.