KPT
Keep
- GitHub Actions를 사용한 CI/CD 구축으로 개발 안정성, 생산성 증가
- GItHub Project와 Issue를 활용한 프로젝트, 브랜치 관리
- REST Docs를 사용한 프로덕션 코드 수정 없는 API 명세서 작성 및 배포로 프론트와 협업
- 단위테스트와 통합테스트 모두 작성
Problem
- 기간에 맞춰 개발하기 위해 코드리뷰가 미흡해짐
- 프론트와 협업하기 위한 API 명세서의 배포 속도 느림
- 프론트와 API설계에 대한 논의를 충분히 하지 못해 이해의 차이가 생기는 기능발생
Try
- 개발 초기부터 RestDoc을 적극 활용하여 프론트분들과 API 명세서를 공유한다면 협업의 효율이 좋아 질 것 같습니다.
- ElasticSearch, Redis 등의 새로운 기술 도입으로 어플리케이션 성능 향상시켜보면 좋을 것 같습니다.
- Mocking 기술을 다양하게 활용하면 프론트의 요구사항 빠르게 충족해줄 수 있을 것 같습니다.
- 주기적으로 각 파트의 개발이슈와 기능에 대한 이해도를 맞춰보면 좋을 것 같습니다.
자체 평가 의견
프로젝트 완성도 (90%)
잘 한 부분 | 아쉬운 부분 |
기획한 MVP를 모두 구현 | 소셜 로그인 부재 |
프로젝트 난이도 (80%)
잘 한 부분 | 아쉬운 부분 |
기간 내 완성 가능한 난이도 설정 | 기술적인 챌린지가 다소 아쉬움 |
기획 의도 일치 정도 (90%)
잘 한 부분 | 아쉬운 부분 |
기획 의도에 맞게 프로젝트 구현 | 공유 서비스 미흡 |
서비스 확장 가능성 (80%)
잘 한 부분 | 아쉬운 부분 |
도커, JPA 사용으로 마이그레이션 용이 | 단일 모듈 서비스 |
서비스 독창성 (70%)
잘 한 부분 | 아쉬운 부분 |
북마크를 폴더로 관리하고 스크랩 기능으로 인한 타 서비스와의 차별성 | 유사 서비스 많음(북마크 서비스) |
느낀점
ㅤ | 느낀점 |
하워드 | 약 1달간 최종프로젝트를 진행하며 이론적으로 알던 내용들이 왜 실무에서 필요한지 알게되었습니다. 👍 |
엘라 | 프론트랑 함께 작업을 하면서 요구사항을 맞추는 것부터 API설계까지 고려해야할 지점들이 훨씬 많았고 그만큼 깊은 고민들을 할 수 있었던 시간이었습니다. 팀원들과 함께 했기 때문에 짧은 기간이었지만 만족스러운 결과물을 만들 수 있었고 다양한 기능들을 구현할 수 있었으며 그 과정에서 함께 고민하며 발전할 수 있었습니다. |
해리 | 프론트와의 협업을 통해 다른 직무와의 소통 그리고 요구사항 파악을 할 수 있는 경험을 하였습니다. 또한 사용자 입장에서 어플리케이션을 사용할 때 많은 검증과 기능들이 필요하다는 것을 느꼈습니다. 어플리케이션의 성능을 위해 앞으로 코드를 더 효율적으로 유지보수해야 한다고 생각합니다. |
란 | 어떻게 협업을 해야 더 효율적으로 개발할 수 있을지에 대하여 소통하는 방법을 배운 것 같습니다. |
스미스 | ㅤ |
ㅤ | ㅤ |