프로젝트명 : A4블라인드
프로젝트 소개 : 익명 커뮤니티
주요 기능
게시물 / 댓글 CRUD
사용자 인증 / 인가
프로필 수정
와이어프레임과 api 명세
ERD 와 Error Code 정의
ErrorCode 를 정의하고 Error 객체를 만들어 관리
=> 에러 코드의 일관성 유지 => 유지보수 용이 => 프론트와의 협업 용이
패키지 구조
도메인 주도 설계 DDD 를 기반으로 한 패키지 구조
domain 하위의 post/comment service 에서
각각의 repository 만 주입받아 사용
=> 각자 맡은 기능을 충돌없이 코드 작성
api 하위의 service 에서 위의 service 를 주입받고 추가로 비밀번호 로직 관리
=> 낮은 결합도로 유지보수성 ↑
트러블 슈팅
1 데이터베이스 Postgres 사용 이유
기본 구현 요구사항에 비밀번호를 수정 시 최근 3번안에 사용한 비밀번호는 사용할 수 없도록 지정해야 했다.
이 경우 최근 3번 안에 사용한 비밀번호를 전부 DB 에 저장해서 비교 해야하는데 여러 개의 값을 하나의 컬럼에 넣고 간편하게 비교할 수있는 방법이 필요했다.
기존의 데이터베이스가 별도의 추가 로직을 작성해야 하는 반면 Postgres 는 테이블의 컬럼을 가변적인 배열로 간편하게 정의할 수 있었기에 채택하게 되었다.
배열 필드를 활용하여 한 컬럼에 array['비밀번호1','비밀번호2'] 와같이 여러 개의 데이터를 효과적으로 저장할 수 있었다.
또한 컬럼 타입을 배열로 정의할 때도 Utils 라는 라이브러리로 편하게 정의할 수 있었는데
실행시켜보니 해당 라이브러리는 Hibernate 의 6.3 버전까지는 지원한다는 문제가 있었다. 현재 사용중인 Hibernate 는 6.4 였는데 Spring Data JPA 의 모든 버전을 낮추는 것은 부담스러웠기 때문에 일부만 낮추기로 하였고 그 방법을 찾았다.
2 익명 닉네임 생성
프로젝트 주제의 정체성과 가까운 익명 닉네임을 어떻게 생성할 것인가에 대한 방법을 찾았다.
첫 번째는 UUID 메소드를 이용해보았다.
중복될 가능성이 현저히 낮은 아이디를 생성해내는 만큼 주로 고유 식별자로 쓰이는 메소드인데 단순히 작성자 이름으로 들어가기에는 패턴이 너무 길고 불필요하다고 생각되어 다른 방법을 찾았다.
두 번째로 찾은 방법은 Random 메소드를 이용해 직접 구현해내는 방식이었다.
지정한 문자열을 특정한 숫자 범위 내에서 랜점하게 뽑아내는 것을 이용해 닉네임을 만들 수 있었다.
그러나 문자열을 일일이 임의로 지정해줘야하고 숫자나 대문자 등도 넣길 원하는데 그러면 문자열이 과도하게 길어져 불필요하다는 생각이 들었다.
세 번째로 찾은 방법은 Apache.commons.lang 라이브러리를 이용하는 것이었다.
뽑아낼 문자열의 범위를 지정할 수있을 뿐만 아니라 문자열의 길이, 문자 사용유무, 숫자 사용유무 등도 자유롭게 지정해 줄 수 있었다. Random 메소드를 사용했던 것처럼 직접 구현해내도 되지만 편하게 사용하라고 이미 구현되어 있는 라이브러리를 이용하는 것이 한 눈에 알아보기도 좋고 닉네임 요구사항이 바뀌거나 할 때에 코드를 수정하기도 편리해서 이 방법을 채택하게 되었다.
깃헙 : https://github.com/BackofficeA4/main/tree/main
GitHub - BackofficeA4/main
Contribute to BackofficeA4/main development by creating an account on GitHub.
github.com
KPT 회고
Keep
-패키지 구조의 쓰임새 알고 들어가기->프로젝트 규모가 커질 수록 더 중요한 것 같다.
-깃 협업 적극 활용 -> 코드리뷰참여로 다른 사람의 코드를 더 적극적으로 볼 수 있었고 issue생성으로 추가 기능이나 오류발생 부분에서 더 확실히 짚고 넘어갈 수 있었다.
-sequence diagram 으로 로직에 대한 이해도를 높일 수 있는게 정말 좋은 것 같다. 다음에도 활용하고싶다.
Problem
-프로젝트 초반에 각종 설계를 제대로 하고 넘어가야할 것 같다.
-확실한 서비스 방향을 정해야 구현해야할 기능이 명확해지고 분업해도 효율적이지 않을까. 주제를 솔직히 너무 대충 정했나싶다.
Try
-깃 컨벤션 정해서 깔끔하고 명확한 커밋 기록을 남겨보고 싶다.
-배포 다시 시도하기
'회고' 카테고리의 다른 글
| 240115 TIL | 뉴스피드 프로젝트 회고 (3) | 2024.01.15 |
|---|---|
| 2023년을 보내며 (7) | 2024.01.01 |
| 1주차 미니 프로젝트 회고록 (1) | 2023.12.01 |
프로젝트명 : A4블라인드
프로젝트 소개 : 익명 커뮤니티
주요 기능
게시물 / 댓글 CRUD
사용자 인증 / 인가
프로필 수정
와이어프레임과 api 명세
ERD 와 Error Code 정의
ErrorCode 를 정의하고 Error 객체를 만들어 관리
=> 에러 코드의 일관성 유지 => 유지보수 용이 => 프론트와의 협업 용이
패키지 구조
도메인 주도 설계 DDD 를 기반으로 한 패키지 구조
domain 하위의 post/comment service 에서
각각의 repository 만 주입받아 사용
=> 각자 맡은 기능을 충돌없이 코드 작성
api 하위의 service 에서 위의 service 를 주입받고 추가로 비밀번호 로직 관리
=> 낮은 결합도로 유지보수성 ↑
트러블 슈팅
1 데이터베이스 Postgres 사용 이유
기본 구현 요구사항에 비밀번호를 수정 시 최근 3번안에 사용한 비밀번호는 사용할 수 없도록 지정해야 했다.
이 경우 최근 3번 안에 사용한 비밀번호를 전부 DB 에 저장해서 비교 해야하는데 여러 개의 값을 하나의 컬럼에 넣고 간편하게 비교할 수있는 방법이 필요했다.
기존의 데이터베이스가 별도의 추가 로직을 작성해야 하는 반면 Postgres 는 테이블의 컬럼을 가변적인 배열로 간편하게 정의할 수 있었기에 채택하게 되었다.
배열 필드를 활용하여 한 컬럼에 array['비밀번호1','비밀번호2'] 와같이 여러 개의 데이터를 효과적으로 저장할 수 있었다.
또한 컬럼 타입을 배열로 정의할 때도 Utils 라는 라이브러리로 편하게 정의할 수 있었는데
실행시켜보니 해당 라이브러리는 Hibernate 의 6.3 버전까지는 지원한다는 문제가 있었다. 현재 사용중인 Hibernate 는 6.4 였는데 Spring Data JPA 의 모든 버전을 낮추는 것은 부담스러웠기 때문에 일부만 낮추기로 하였고 그 방법을 찾았다.
2 익명 닉네임 생성
프로젝트 주제의 정체성과 가까운 익명 닉네임을 어떻게 생성할 것인가에 대한 방법을 찾았다.
첫 번째는 UUID 메소드를 이용해보았다.
중복될 가능성이 현저히 낮은 아이디를 생성해내는 만큼 주로 고유 식별자로 쓰이는 메소드인데 단순히 작성자 이름으로 들어가기에는 패턴이 너무 길고 불필요하다고 생각되어 다른 방법을 찾았다.
두 번째로 찾은 방법은 Random 메소드를 이용해 직접 구현해내는 방식이었다.
지정한 문자열을 특정한 숫자 범위 내에서 랜점하게 뽑아내는 것을 이용해 닉네임을 만들 수 있었다.
그러나 문자열을 일일이 임의로 지정해줘야하고 숫자나 대문자 등도 넣길 원하는데 그러면 문자열이 과도하게 길어져 불필요하다는 생각이 들었다.
세 번째로 찾은 방법은 Apache.commons.lang 라이브러리를 이용하는 것이었다.
뽑아낼 문자열의 범위를 지정할 수있을 뿐만 아니라 문자열의 길이, 문자 사용유무, 숫자 사용유무 등도 자유롭게 지정해 줄 수 있었다. Random 메소드를 사용했던 것처럼 직접 구현해내도 되지만 편하게 사용하라고 이미 구현되어 있는 라이브러리를 이용하는 것이 한 눈에 알아보기도 좋고 닉네임 요구사항이 바뀌거나 할 때에 코드를 수정하기도 편리해서 이 방법을 채택하게 되었다.
깃헙 : https://github.com/BackofficeA4/main/tree/main
GitHub - BackofficeA4/main
Contribute to BackofficeA4/main development by creating an account on GitHub.
github.com
KPT 회고
Keep
-패키지 구조의 쓰임새 알고 들어가기->프로젝트 규모가 커질 수록 더 중요한 것 같다.
-깃 협업 적극 활용 -> 코드리뷰참여로 다른 사람의 코드를 더 적극적으로 볼 수 있었고 issue생성으로 추가 기능이나 오류발생 부분에서 더 확실히 짚고 넘어갈 수 있었다.
-sequence diagram 으로 로직에 대한 이해도를 높일 수 있는게 정말 좋은 것 같다. 다음에도 활용하고싶다.
Problem
-프로젝트 초반에 각종 설계를 제대로 하고 넘어가야할 것 같다.
-확실한 서비스 방향을 정해야 구현해야할 기능이 명확해지고 분업해도 효율적이지 않을까. 주제를 솔직히 너무 대충 정했나싶다.
Try
-깃 컨벤션 정해서 깔끔하고 명확한 커밋 기록을 남겨보고 싶다.
-배포 다시 시도하기
'회고' 카테고리의 다른 글
| 240115 TIL | 뉴스피드 프로젝트 회고 (3) | 2024.01.15 |
|---|---|
| 2023년을 보내며 (7) | 2024.01.01 |
| 1주차 미니 프로젝트 회고록 (1) | 2023.12.01 |
