🔨 Describe
장점이 많은 ResponseEntity를 사용합시다

✅ Tasks

• 1. Controller 레이어에서 모든 리턴에 ResponseEntity를 사용합니다.

🙋🏻 할 말

✨ Describe
테스트 작성 형식을 맞추고 CommandDocsService 테스트 코드를 작성합니다

✅ Tasks

• 테스트 작성 형식 정하기
• CommandDocsService 테스트 코드 작성

🙋🏻 할 말

🔨 Describe

✅ Tasks

• 1. unused import 삭제 및 코드 컨벤션에 맞게 변경

🙋🏻 할 말

✨ Describe
S3 -> R2 이전
✅ Tasks

• [ ]
  1.

🙋🏻 할 말

🔨 Describe

개발할 때에는 DB 쿼리를 추적을 해야합니다. 그러나 서버로 올라가게 된다면 DB 쿼리는 로그를 확인하기에 복잡하기만 합니다. Yaml 파일을 분리함으로써 해결할 수 있습니다.

✅ Tasks

• 1. local, dev, prod Yaml 파일 분리

🙋🏻 할 말

🐞 Describe
우리 프로그램 위험하다고 합니다.

조졌구만 이거
✅ Tasks

• 1. Security Hotspots 해결

🙋🏻 할 말

🔨 Describe

coin 도메인 리팩토링하기

✅ Tasks

• [ ]
  1.

🙋🏻 할 말

🐞 Describe
popular docs조회시 500 에러 해결하였습니다

✅ Tasks

• 1. 조회 sql 수정

🙋🏻 할 말

🐞 Describe
getUserThumbsUP에서 발생하는 ExpressionException해결해야 합니다

✅ Tasks

• 1. dto확인하기
• 2. select에서 dto와 다른 값을 가지는 지 확인하기

🙋🏻 할 말

✨ Describe
우리의 코드 품질을 위해 SonarCloud를 적용해보는 것이 좋을 것 같습니다. 우리와 같은 문제를 겪고있는 글을 보았고 해결 방법으로 SonarCloud가 있었으니 사용해봅시다 !

✅ Tasks

• 1. CI시에 SonarCloud 적용

🙋🏻 할 말

🔨 Describe
실행을 위한 docs 전체 리팩토링을 진행하였습니다

🔨 Describe
Docs 도메인에 우리가 정의한 개발방식과 맞지 않는 부분이 여러곳에서 보여요. 이 부분들을 수정을 해야해요.

수정해야하는 부분들

1. DocsInformationService에서 QueryDocsService로 변경해야해요.
2. DocsMergeConflictService가 CommandDocsService와 QueryDocsService에서 빠져있어요.
   
3. Controller도 마찬가지예요. API가 많아서, Command와 Query는 구분할 수 있어도, DocsMergeConflictController와 DocsPopularInformationController는 Command 혹은 Query에 추가해야해요.
   
4. 구현된 Repository Infra 레이어로 변경

✅ Tasks

• DocsInformationService에서 QueryDocsService로 변경
• DocsMergeConflictService를 CommandDocsService와 QueryDocsService로 분리
• DocsMergeConflictController와 DocsPopularInformationController는 Command 혹은 Query Controller에 추가
• 구현된 Repository Infra 레이어로 변경

🙋🏻 할 말

🔨 Describe
코드를 보면 Facade 패턴 사용 많이 했는데, Service가 Facade를 의존하는게 맞나요? 아쉬운 점은 현재 Facade 라고 명시해주신 클래스들보다, ~Service들이 더 퍼사드 객체에 가까워보인다는 점이네요.. 😢
세부적인 로직(분기)를 service 에서 결정하고, Facade 객체들은 수직적으로 자신이 할 일을 진행하는 걸로 보여요.

현재 레이어 의존도

✅ Tasks

• 1. 퍼사드 패턴 레이어 재구성

🙋🏻 할 말
관련된 좋은 글 있어서 첨부드립니다.
https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EC%95%84%EC%A3%BC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-SRP-%EB%8B%A8%EC%9D%BC-%EC%B1%85%EC%9E%84-%EC%9B%90%EC%B9%99

✨ Describe
jacoco로 테스트 커버리지 구성

✅ Tasks

• 1. jacoco 적용

🙋🏻 할 말

🔨 Describe

CommandDocsServiceTest, QueryDocsServiceTest 리팩토링

✅ Tasks

🙋🏻 할 말

🔨 Describe
build.gradle 파일이 너무 큽니다
build.gradle 파일을 분리합시다!

✅ Tasks

• 1. build.gradle 파일을 분리합니다
• 2. 끝!

🙋🏻 할 말
build.gradle을 build하는법

🔨 Describe
프론트엔드가 next를 도입하면서 SSG방식으로 프론트가 동작하게 되었습니다. 그래서 사용자가 좋아요를 누른다면, 좋아요 개수가 몇 개인지 새로고침을 해야하는데 우리는 문서를 조회할 때 좋아요 개수를 던져줍니다. 이 말인즉슨 좋아요를 누를 때마다 그 문서를 프론트에서 다시 가져오기를 해야하고 무거운 작업이 됩니다. 그래서 좋아요 개수를 확인하는 api를 분리해야합니다.

✅ Tasks

• 1. 문서 좋아요 개수 조회 api 생성

🙋🏻 할 말

🔨 Describe
Auth도메인은 Security를 분리하는 작업을 선제적으로 진행했기 때문에
우리가 정의한 개발 방식으로 되어있지 않습니다. 전체적으로 바꾸어야 합니다
✅ Tasks

• UserSignUpOrUpdate와 AccessTokenRefresh를 CommandAuthService로 합친다
• 서비스에 구현되어 있던 내용을 implementation 레이어로 분리합니다
• User에 대해서도 Auth에서 사용하고 있는 부분을 implementation 레이어로 분리시킵니다
• Bsm정보를 가져오는 것도 infra레이어로 분리해야합니다
• Header로 받아오는 정보를 Body에서 받아와야할지 정해야해요

🙋🏻 할 말

✨ Describe
스웨거 ui 도입

✅ Tasks

• 1. 스웨거 적용

🙋🏻 할 말

🔨 Describe
선생님이나 동아리를 조회했을 때, /club으로 조회하면 현재는 전공 동아리만 불러오며, 따로 /free_club API로 조회해야 일반 동아리까지 불러와집니다.
또한 선생님을 불러올 때도 /major_teacher, /mentor_teacher 등의 API로 하나씩 불러와야하는 점이 있습니다.
이를 한 API, 즉 /club, /teacher처럼 합친다면 프론트엔드 단에서도 /teacher, /student 등의 라우터를 사용해 처리하던 작업을
/[docsType]으로 처리받아 한 파일로 여러가지의 문서 리스트들을 처리할 수 있는 장점이 있습니다.

✅ Tasks

• 1. 선생님이나 동아리 목록을 조회할 때, /teacher로 요청을 보내면 멘토 선생님, 전공 선생님, 일반 선생님 모두 불러와질 수 있었으면 합니다.
• 2. /club도 마찬가지로 일반 동아리, 전공 동아리 모두 불러와질 수 있었으면 합니다.
• 3. 그 외 다른 DTO들도 똑같이 처리할 수 있게 배열에 감싸져있는 형태로 DTO를 변경해주실 수 있나요?

🙋🏻 할 말
감사합니당

🔨 Describe
현재 Docs의 버전을 조회하면

위와 같이 이전 버전의 Contents까지 던집니다. 이게 지금처럼 이번 버전과의 차이를 보여주는게 아니라 이번 버전의 문서를 보여줬을 때의 반환 결과가 아직 남아있다고 생각됩니다. contents는 반환하지 않아도 될 것 같아요!

그리고 위와 같이 현재 상태의 문서도 반환할 필요가 없을 것 같아요.

✅ Tasks

• 1. 버전 문서 반환에서 Contents를 제외한다.
• 2. 문서 버전 조회에서 현재 문서의 상태는 반환하지 않는다.

🙋🏻 할 말

🐞 Describe
닉네임이 길면 로그인이 되지 않는 현상

✅ Tasks

• 1. 닉네임 길이제한은 BSM과 동일하게 한다

🙋🏻 할 말

🔨 Describe
thumbsUp 도메인을 리팩토링합니다

✅ Tasks

🙋🏻 할 말

✨ Describe
부마위키 문서에 MergeConflict 기능을 추가합니다.

✅ Tasks

• 1. 문서에 MergeConflict 기능을 추가

🙋🏻 할 말

🔨 Describe
파일 도메인을 리팩토링합니다.

🔨 Describe
User 도메인 리펙토링
✅ Tasks

• 1. 유저 리펙토링

🙋🏻 할 말

✨ Describe
CI/CD를 위한 도커파일 세팅

✅ Tasks

• 1. 도커파일을 세팅합니다.

🙋🏻 할 말

🐞 Describe
buma.wiki에서 로그인을 할 때 프론트엔드 API의 baseURL을 buma.wiki/api로 바꿨음에도 불구하고 로그인이 되지 않습니다!

✅ Tasks

• 1. 제 생각엔 BSM OAuth의 redirectURL 문제 같습니다. 클라이언트 수정해서 다시 설정 부탁드립니다!

🙋🏻 할 말

🐞 Describe

우리 깃플로우 커밋 컨벤션 코드 컨벤션 정리해야 할 듯 합니다. 너무 난장판입
✅ Tasks

• 1. 정리

🙋🏻 할 말

🐞 Describe
thumbs/up/get API 즉 유저가 해당 문서를 좋아하는지를 불러오는 API에서,
Authorization을 넣지 않았을 경우 ( 로그인을 하지 않은 경우 ) 500 에러가 발생합니다.

🙋🏻 할 말
아잉 고쳐줏세용~~~ 히히

🔨 Describe

자신이 문서를 좋아하는지 확인하는 api가 호출되었을 떄 기본 4번의 쿼리 + 자신이 좋아하는 문서 개수 만큼의 쿼리가 호출되게 됩니다. DB와의 상호작용이 적을수록 응답시간이 빨라지게 됩니다! 즉 DB에 보내는 쿼리를 최소화하는 작업을 해야합니다.

✅ Tasks

• 1. 자신이 좋아하는 문서 조회 DB 쿼리 수정

🙋🏻 할 말

이거 말고도 DB와 필요 이상으로 상호작용하는 작업의 수가 많습니다. 하나씩 다 확인하고 수정할 필요가 느껴집니다 🥸

🔨 Describe
어떤 요청이든 AccessToken을 가지고 서버에 접근하면 DB에서 User를 조회하는 버그가 있습니다! 서버에 부하가 갈 수 있으니 �필요할 때에만 DB에서 유저를 조회하는게 어떤가요?

✅ Tasks

• 1. 접근 처리와 유저 조회 분리

🙋🏻 할 말

✨ Describe

QueryDocsService 테스트 코드 작성

✅ Tasks

• QueryDocsService 테스트 코드 작성

🙋🏻 할 말