[개인 프로젝트1] My DevBoard 프로젝트 회고

[ 기획 배경 ]

  저의 첫 SpringBoot 프로젝트였기 때문에 기본에 충실하고자 하였습니다. 웹 프로젝트의 입문이자 기본이라고 할 수 있는 게시판 CRUD를 구현하면서  SpringBoot에 대한 감을 잡는 것이 이번 프로젝트의 첫 목표였습니다. 추가적으로 본격적인 팀프로젝트에 들어가기 전에 개발 프로세스를 익숙해지는 것이 두번째 목표였습니다.

 

[ 초기 설계 과정 ]

1. 와이어프레임

 : Figma를 사용하여 제작하였습니다.

 : 기존 프로젝트들에서 사용하던 카카오오븐의 한계를 느끼고 Figma를 배워 적용하였습니다.

와이어프레임 설계

2. API설계

 

 

[ 완성작 ]

개발 관련된 게시글을 조회, 작성, 수정, 삭제할 수 있습니다.

 

[ 배운점 ]

1. 개발 프로세스 익숙해지기

이번 프로젝트의 개발 프로세스

  본격적인 팀프로젝트가 들어가기 전에 개발 프로세스에 익숙해지는 것이 이번 프로젝트의 목표 중 하나였습니다. 때문에 개인 프로젝트임에도 불구하고 개발 프로세스를 지키려고 노력했습니다. 이번에 제가 느낀 체계화된 개발 프로세스를 지킬때 좋은 점은 '각 단계에만 집중할 수 있다' 입니다.

 와이어프레임을 미리 설계해두니 프론트를 개발할 때 디자인에 대한 고민을 할 필요가 없었습니다. API를 미리 설계해두니 프론트 개발과 백엔드를 개발은 서로를 신경 쓸 필요가 없었습니다. html와 JS를 만지다가 Java를 만지는 등 왔다갔다 해야할 일이 없었습니다. 실제 이번 프로젝트에서 저는 백엔드 개발을 모두 마치고, 테스트를 거친 후, 프론트 개발을 하였습니다.

 

 

2. 와이어프레임 툴, Figma

Figma로 만들고 있는 이번 프로젝트의 와이어프레임

  현재 전세계적으로 많은 회사들이 디자인툴로 Figma를 채택해서 사용하고 있습니다. Figma는 웹 브라우저 기반, 무료, 쉬운 조작법, 협업 가능이라는 많은 장점을 가지고 있습니다. 물론 저는 백엔드를 희망하고 있지만 지금 배워둔다면 추후에 디자이너-프론트 앤드 개발자분들과 함께 작업하는 다음 팀작업을 수월하게 할 수 있을 것이라고 생각해 배우게 되었습니다.

 

 

3. 커밋 메시지와 이슈 관리

이슈와 커밋메시지 관리

  이슈는 왼쪽 사진과 같이 일정한 틀을 가지도록 했습니다. 또한 라벨을 붙여 이슈의 타입이 무엇인지 빠르게 확인할 수 있게 하였습니다. 예를 들어 첫번째 이슈인 '작성 날짜 기준으로 내림차순 정렬'은 Repository단에서 생긴 Bug임을 한눈에 확인할 수 있게합니다.

  커밋메시지 역시 일정한 틀을 가지고 있습니다. Udacity의 커밋메시지 스타일을 따라서 작성하였습니다. 뿐만 아니라 오른쪽 사진에서 볼 수 있다싶이 연관된 이슈가 있다면 커밋 메시지에 적어 바로 연결되게끔 작성하였습니다. 오른쪽 사진에서 보이는 첫번째 커밋에서는 해당 이슈를 Fix했으며 두번째 커밋에서는 해당 이슈에 대한 Test를 했다는 것을 바로 알 수 있습니다.

 

 

4. Projects와 Wiki 활용하기

이번 프로젝트의 Projects

  개인적으로 그것이 코드가 되었든, 일반 글이 되었든 깔끔하고 군더더기 없이 눈에 잘 들어와야한다고 생각합니다. 이번 프로젝트에서는 더 깔끔하게 문서를 관리하기 위해서 Wiki를 적극적으로 활용하였습니다. 덕분에 리드미 역시도 정돈될 수 있었습니다. 뿐만아니라 Projects를 활용하여 일정을 관리하였습니다.

 

 

5. 테스트

테스트 커버리지 툴인 Jacoco 화면

  저번 Spring 팀 프로젝트를 거치면서 테스트의 중요성을 깨달았었습니다. 때문에 이번 프로젝트에서는 테스트를 만들어보고 싶다는 생각이 있었습니다. 테스트에는 Junit5를 사용했습니다. Spring의 3계층인 Controller-Service-Repository 각각에 대해 테스트를 만들겠다고 생각했습니다.

  테스트에서 @SpringBootTest를 사용하게되면 스프링을 실행시켜 모든 빈을 등록하여 테스트를 진행합니다. 덕분에 테스트 코드는 쉽게 짤 수 있지만, 테스트 실행속도는 현저히 느려지게됩니다. 때문에 저는 @SpringBootTest대신 각 계층에 맞는 테스트를 진행하려고 노력했습니다. Service계층에는 Mock객체를 이용하여 테스트를 진행하고 Repository계층에서는 @DataJpaTest를 사용하였습니다. Controller계층에 대해서는 API 테스트 툴을 활용하였습니다.

 

[ 아쉬운 점 ]

1. 부족한 테스트 커버리지

테스트 커버리지 Jacoco 화면

  Controller에 대한 테스트는 직접 테스트 코드를 작성하는 대신 API 테스트 툴을 사용했었습니다. 다음에 기회가 된다면 Controller에대한 테스트 역시 직접 테스트 코드를 작성해보고 싶습니다. Jacoco를 통해서 알아본 이번 프로젝트의 테스트 커버리지 퍼센트는 40%였습니다. 다음에 기회가 된다면 이보다 높은 테스트 커버리지 퍼센트를 달성해보고 싶습니다.

 

2. Pull Request

  커밋 메시지와 이슈 적용하는 것에 신경쓰다보니 Pull Request - Merge 과정을 해보지 못했습니다. 보통 팀 프로젝트에서는 코드 리뷰와 코드충돌을 방지하기 위해서 Pull Request을 사용하는 것으로 알고 있습니다. 다음 저의 프로젝트에서는 브랜치 전략에 대해서 공부해보고 브랜치를 만들어서 Pull Request-Merge를 경험해보고 싶습니다.

 

 

[ 프로젝트 관련 자료 ]

1. Github

  : https://github.com/mangdo/myDevBoard

 

2. Website

  : http://startspring.shop/