[회고록] 가천대학교 졸업인증시스템 : Gradu

아연·2023년 10월 10일
0

project

목록 보기
1/10
post-thumbnail

단기간에 이렇게 몰입해 애정을 가지고 시간을 투자한 프로젝트는 이번이 처음이었기에, 그리고 우리의 대장 덕분에(ㅎㅎ) 단 하나도 버릴 게 없는 경험이었다.

졸업인증시스템 그래듀(Gradu) 회고록 스타트 - !! 🎬

(( 후기 2023.12.08. ))

♡〜٩( ˃́▿˂̀ )۶〜♡ .+:｡ 기대

ː̗̀*Ꙩꙻ₀Ꙩꙻ)ː̖́ 긴장

ჱ̒⸝⸝•̀֊•́⸝⸝)‪ ̖́– 자신감

〣( ºΔº )〣걱정
.
.
.
그리고 런칭


0. 프로젝트 일정

📆 2023.05.06.
→ 프로젝트 시작

📆 2023.05.08. - 2023.06.04.
→ 요구사항 분석 및 설계서 작성

📆 2023.05.22. - 2023.08.02.
→ 기능 구현 및 QA

📆 2023.08.03.
→ 프로젝트 마감

📆 2023.08.04. -
→ 유지보수


1. Gradu가 뭔데? 🤷

프로젝트 소개 🎓

기존 졸업인증 방식은 학생들이 졸업인증 신청서를 직접 학과 이메일로 제출하고, 학과 홈페이지에서 결과를 확인하는 절차로 이루어졌다. 이메일과 학과 홈페이지라는 서로 분리된 체계로 인해 졸업인증 신청, 결과 조회 그리고 심사 관리에 불편함이 있었다.

이를 개선하기 위한 서비스가 바로 그래듀(Gradu)이다.

졸업인증 서비스 그래듀(Gradu)는 REST API를 기반으로 학생들의 졸업인증 심사 신청과 심사 통과 여부를 기록한다. 이를 통해 학생들이 졸업인증 신청이나 결과 확인을 하나의 체계에서 수행함으로써 학생들의 수고를 줄이고자 하였다. 또한, 심사 결과 등록에서 발생하는 오차를 방지하는 효과도 기대한다.


기술 스택 ⚙️

BE

  • Java 17
  • Spring Boot 3.0.6
    • JPA
  • Spring Security
  • MariaDB
  • JWT

FE

  • Next.js
  • Typescript
  • Redux-toolkit
  • Styled Component

Conventions

브랜치 전략

브랜치 컨벤션

타입/이슈번호/이슈이름
feat/#1/학생-및-관리자-로그인-구현

커밋 컨벤션

  • Udacity

  • 사용법

    • 각 파트는 빈 줄을 두어 구분

      			type: Subject (제목)
			body (본문)        
			footer (꼬리말)
    • type
      • 커밋 의도 작성
    • subject
      • 50글자가 넘지 않도록 작성
      • 마침표는 찍지 않음
    • body
      • 긴 설명이 필요한 경우, 무엇을 왜 했는지 작성 (what, why)
      • 최대 75자를 넘기지 않음
    • footer
      • issue tracker ID 기입

  • 태그 종류

    태그 이름설명
    feat새로운 기능을 추가할 경우
    fix버그를 고친 경우
    designCSS 등 사용자 UI 디자인 변경
    !BREAKING CHANGE커다란 API 변경의 경우
    !HOTFIX급하게 치명적인 버그를 고쳐야하는 경우
    style코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
    refactor프로덕션 코드 리팩토링
    comment필요한 주석 추가 및 변경
    docs문서를 수정한 경우
    test테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X)
    chore빌드 태스트 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X)
    rename파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
    remove파일을 삭제하는 작업만 수행한 경우

  • 예시

feat: 새로운 기능 추가 (#30 이슈번호)

새로운 기능은 이러한 이유 때문에 추가하였습니다

close: #[이슈번호] (#29 이슈번호)

이슈 컨벤션

  • 이슈 컨벤션
  [type] 이슈 번호 이슈이름
  [feat] #1 학생 및 관리자 로그인 구현
  • 이슈 템플릿 (기능)
1. 무엇을?
2. 상세 설명
3. 추가 사항
  • 이슈 템플릿 (버그)
1. 문제 정의
2. 원인 파악
3. 해결
4. 결과 확인

PR 컨벤션

  • label
    • feat
    • bug/fix
    • refactor
    • docs
    • style
    • design
  • 제목
[type] #[number] [PR 내용]
  • 내용
## 1. 무슨 이유로 코드를 변경했나요?

## 2. 어떤 위험이나 장애를 발견했나요?

## 3. 관련 스크린샷을 첨부해주세요.

## 4. 완료 사항

DB 모델링 💾

구현 기능 🔮

유저

번호주요기능명상세기능명
1사용자 인증로그인
2회원 가입
3계정 정보 수정
4컴공졸업인증 심사신청/조회심사신청 일정 조회
5심사신청/수정
6심사신청 결과 확인
7컴공졸업인증 심사결과조회심사결과 확인
8심사결과 합격증 발급
9공지사항 게시판공지사항 목록/조회
10질의응답 게시판질의응답 목록
11질의응답 작성/수정/삭제
12자료실학과내규/자료실

관리자

번호주요기능명상세기능명
1사용자 인증로그인
2회원 가입
3계정 정보 수정
4학생 계정 관리계정 목록
5계정 등록
6계정수정/삭제
7비밀번호 초기화
8현재학기 일정관리심사일정 등록
9심사일정 수정
10심사신청 접수 관리신청 목록/검색
11신청내역조회/접수승인
12신청내역인쇄
13졸업인증 심사결과 관리심사결과 목록
14심사결과 등록
15심사결과 조건별 인쇄
16심사학기 마감
17공지사항 게시판공지사항 목록
18작성관리
19질의응답 게시판질의응답 목록
20작성관리
21자료실학과내규/자료실

2. 프로젝트 진행 💻

나의 역할

Issue

PR


3. 프로젝트를 통해 얻은 것

요구사항 분석 및 설계의 중요성

교수님이 주신 요구사항은 약 14페이지 분량이었다. 하지만 Gradu의 최종 설계서(v1.4)는 약 200 페이지 . . .

프로젝트를 제대로 시작하기도 전에 포기할까 싶은 마음이 들었다.
기능 개발 때문이 아니라 설계서 작성 때문에 . . .

하지만 몇 번의 수정을 거쳐 만들어 낸 200 페이지의 설계서는 일단

뿌듯하다 ! !
ㅋㅋ

뿌듯한 건 둘째치고, 설계서를 작성하면서 기능에 대해 팀원들이랑 더 소통하는 과정이 있었다. 우리는 프로세스를 클래스 다이어그램을 이용해서 설계하였는데, 여기서 좋았던 건 다른사람이 어떤 생각과 목적으로 해당 클래스를 설계했는지 파악할 수 있었다는 점.

아키텍처에 대한 고민

  • 클린 아키텍처
    • 주 목적은 역참조, 순환참조를 없애는 것
    • 각 코드의 종속성은 외부(API)에서 내부(Domain)로 가리킬 수 있도록 설계
├── calendar
│   ├── domain
│   │   └── repository
│   ├── exception
│   ├── presentation
│   │   ├── dto
│   │   └── mapper
│   ├── type
│   └── usecase
│   │   ├── CreateCalendar.java
│   │   ├── CreateCalendarImpl.java
│   │   			...
│   │   ├── GetCalendarDetails.java
│   │   └── GetCalendarDetailsImpl.java

코드 리뷰 📝

다른 사람에게 내 코드를 보여주는 것이 부끄러웠는데, 이 감정이 내가 하나라도 더 찾아보고 공부하게 된 계기가 되었다. 팀원이나 불특정 다수에게 더 나은 코드로 나를 보여주고 싶다는 욕심이 생겼다.

그리고 내 PR을 정성스럽게 리뷰해 준 백 멤버들에게 보답하고 싶었다. 더 도움이 되는 리뷰를 남기기 위해 하나라도 더 찾아보고, 한 번이라도 더 고민한 뒤 리뷰를 달았던 나...


4. 아쉬운점

애자일 프로세스

애자일 프로세스란 ?
1. 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통을 중시한다.
2. 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시한다.
3. 계약과 협상 중심이 아닌, 고객과의 협력을 중시한다.
4. 계획 중심이 아닌, 변화에 대한 민첩한 대응을 중시한다.

회고록을 작성하면서 돌이켜보니, 교수님께서는 완강한 폭포수 모델 (^^;;) 스타일이셔서 과연 무작정 도입한 애자일이 올바른 선택이었나 싶은 생각이 든다.
200 페이지가 넘는 설계서를 작성하고 변화에 대한 민첩한 대응에 대비하려 하다니

애자일 프로세스 중 제대로 진행한 것은 데일리 스크럼뿐인 듯하다. 하하
사실 데일리 스크럼도 항상 40분을 넘어가는... 하지만 스크럼마다 너무 즐겁게 했다. 내가 구현한 기능을 자랑하는 기분이었다. 새로운 이슈가 발생하는 건 항상 떨렸지만,,^^

아무튼 잘 받아준 팀원 덕분에 수월하게 굴러간 스크럼 ㅎ

다음에는 더 체계적인, 애자일의 이점을 더 확보할 수 있도록 !!

클라이언트의 요구 🗣️

아쉬운 점은 클라이언트의 요구에 무신경했다는 점이다. 개발자의 입장에서 A 기능이 왜 필요한지, 'A 보단 B가 더 낫지 않나?' 라고 생각한 적이 있다. 우리 팀은 내부회의를 통해 이 기능의 우선순위를 낮게 잡고 개발을 진행하였다.

그 결과 교수님과 QA시간에 지적을 당했다.

클라이언트의 요구명세서에는 모든 기능마다 각각 이유를 기재할 수 없다. 그렇기에 개발자 입장에서 기능에 의문이 생기고 그 기능들의 우선순위를 제대로 파악하기 어려울 수 있다. 하지만 이것은 팀 내 소통만으로 결정할 문제가 아니라, 클라이언트와 소통으로 해결해야한다는 것을 배웠다.


즉시 로딩에 N + 1문제가 발생한다는 이슈를 회고록을 작성하면서야 알게 되었다.
이를 해결하기 위한 @EntityGraph ... 다음에는 꼭 써봐야지

팀원들과 매일같이 만나며 열심히 가꿔낸 프로젝트 Gradu.
(진짜 비대면으로라도 매일만남.. 지금 생각하면 그저 신기하다. 다들 진심이었군)

보안상 우리의 Repository를 공개할 수는 없지만
( 너 무 너 무 공개하고 싶음 ! ! 자랑하고 싶어 ! ! )

가천대학교 컴퓨터공학과의 발전을 위해 조금이나마 기여했다는 점이 자랑스럽고 뿌듯하다.

profile
아연
다음 포스트

[회고록] 동아리 모집 올인원 솔루션 : CRAYON

0개의 댓글