Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

유저 통계와 전체 통계 분리 리팩토링(#104) #113

Open
wants to merge 23 commits into
base: dev
Choose a base branch
from

Conversation

eun-seong
Copy link
Member

@eun-seong eun-seong commented Mar 6, 2024

요약

통계 관련하여 전반적인 리팩토링을 진행하였습니다.
유저 통계(Dashboard)와 전체 통계(Statistics)를 분리하는 작업에서 파생되는 작업들입니다.
HAPPY, SAD, ... 등 DashboardType 별로 하드코딩되어 있던 부분을 최대한 제거하였습니다.

PopulationStatistic 관련 로직은 아직 기존 상태로 남아 있으며, 이는 #114 에서 진행할 예정입니다.

코드가 얽히고 설켜 있어 PR 크기가 커진 점.. 양해 바랍니다🥹

변경된 점

1. Statistics와 관련 클래스들의 패키지 이동 commit

Statistics 클래스, Statistic 클래스와 그 자식들(AverageStatistics, RatioStatistics)이 statistics 패키지에서 dashboard 패키지로 이동되었습니다.
Dashboard Collection에서 Statistics를 필드로 가지고 있으며, Statistic 구현체들 모두 dashboard에서 사용 중입니다.

이 때문에 DB에 있는 데이터 수정이 필요합니다.(특이사항 참고)

2. 통계량 업데이트 로직 분리 commit

유저의 통계량(dashboard)를 업데이트하는 로직과 전체통계량(statistics) 업데이트하는 로직을 분리하였습니다.

3. Statistic을 통해 Dashboard로 변환하는 로직 테스트 코드 작성 commit

이후 리팩토링 진행을 위해 테스트 코드 작성하였습니다.
Statistic을 DashboardDto로 변환하는 로직에 관한 테스트입니다.

4. Statistic -> DashboardComponent 변환 방식 변경 commit

기존에 DashboardType 별로 모두 각각 생성하던 로직을 3가지로 분류하였습니다.

  • BinaryDashboard
    • Character
  • RatioDashboard
    • BestWorth
    • Happy
    • Sad
  • AverageDashboard
    • Money

DashboardFactory를 통해서 DashboardComponent를 생성할 수 있으며, PopulationStatistic과 UserStatistic을 구분하였습니다.
따라서 DashboardComponent를 생성하는 로직도 DashboardService에서 Dashboard Entity로 이동되었습니다.

5. BorrowingLimitEntireStatistic -> AverageEntireStatistic commit

확장성없이 작성되어 있는 BorrowingLimitEntireStatistic을 AverageEntireStatistic로 변경하였습니다.
4번의 과정에서 Population 타입의 AverageDashboard를 처리하기 위해 추상화하였습니다.

이로 인해 API 명세가 변경되어 배포 전 프론트 개발자분들에게 노티 필요합니다.
DB에 있는 데이터도 수정이 필요합니다.(특이사항 참고)

6. Population과 User 타입에 따른 Dashboard 변환 로직 분리 commit

AnalysisType enum이 추가되었습니다.
DashboardType에서 해당 값을 가지고 있어 기존에 HAPPY, SAD, ... 등 하드코딩되어 있던 것을 dashboard.getUserDashboards() 메소드를 통해 처리할 수 있게 되었습니다.

특이 사항

배포가 되기 전, 운영 DB 데이터 중 일부를 수정해야 합니다.

  • Dashboard Collection
    • statistics 필드
      • com.dnd.namuiwiki.domain.statistic.model.* -> com.dnd.namuiwiki.domain.dashboard.model.*
  • Statistics Collection
    • statistic 필드
      • borrowingMoneyLimitEntireAverage -> entireAverage
      • com.dnd.namuiwiki.domain.statistic.model.BorrowingLimitEntireStatistic -> com.dnd.namuiwiki.domain.statistic.model.AverageEntireStatistic

@eun-seong eun-seong requested a review from rlacksgus97 March 6, 2024 12:49
@eun-seong eun-seong self-assigned this Mar 6, 2024
@eun-seong eun-seong marked this pull request as ready for review March 6, 2024 12:50
@eun-seong eun-seong changed the title Refactor/#104 유저 통계와 전체 통계 분리 리팩토링 Mar 6, 2024
@eun-seong eun-seong changed the title 유저 통계와 전체 통계 분리 리팩토링 유저 통계와 전체 통계 분리 리팩토링(#104) Mar 6, 2024
eun-seong added 22 commits March 8, 2024 21:38
@rlacksgus97
Copy link
Collaborator

고생하셨습니다! 제 개인적인 의견만 첨부하겠습니다..!

@rlacksgus97
Copy link
Collaborator

  1. Statistics와 관련 클래스들의 패키지 이동
  • 패키지를 이동하신 이유는 Statistics가 Dashboard의 하위 도메인에 속해서라고 생각되는데, 현재 Statistics의 경우, 그 자체로도 하나의 도메인으로써의 역할을 하고 있다고 생각이 됩니다.(별도의 repository 및 service를 구성하고 있기 때문에) 따라서 무조건 Dashboard에 종속되어야 하는 도메인은 아니라고 생각되긴 합니다.

@@ -1,6 +1,6 @@
package com.dnd.namuiwiki.domain.statistic.type;

public enum StatisticsType {
public enum StatisticsCalculationType {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

개인적으론 statistics라는 뜻 자체가 이미 계산을 의미하고 있어서 기존의 StatisticsType의 클래스명이 더 의미가 적절하다고 보입니다..!

@@ -0,0 +1,5 @@
package com.dnd.namuiwiki.domain.dashboard.type;

public enum DashboardStatisticType {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dashboard가 어떤 형식으로 보이는지에 대한 타입이라, DashboardViewType과 같은 클래스명이 더 적절해 보입니다.
StatisticsCalculationType과 DashboardStatisticType에 statistic이라는 이름이 동일하게 들어가는데, StatisticsCalculationType과 DashboardStatisticType이 항상 같은 값을 갖는 게 아니라서, 헷갈릴 수도 있을 것 같아요

@@ -0,0 +1,13 @@
package com.dnd.namuiwiki.domain.dashboard.type;

public enum AnalysisType {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AnalysisType의 경우, 통계의 모수에 대한 의미라고 생각되어서, StatisticSubjectType, personal, global 같은 네이밍이 어떨까요? 클래스의 위치도 statistic 도메인 하위에 위치하는 게 더 적절해 보여요

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AnalysisType의 각 요소의 뜻은 이러합니다.

  • USER : Dashboard 값 필요
  • POPULATION : Dashboard 값 필요, PopulationStatistic 값 필요

이 enum 값은 Dashboard를 DashboardDto로 변환해서 응답할 때 사용되기 때문에 Dashboard 도메인이 더 적합하다고 생각합니다.

@eun-seong
Copy link
Member Author

eun-seong commented Mar 18, 2024

패키지를 이동하신 이유는 Statistics가 Dashboard의 하위 도메인에 속해서라고 생각되는데, 현재 Statistics의 경우, 그 자체로도 하나의 도메인으로써의 역할을 하고 있다고 생각이 됩니다.(별도의 repository 및 service를 구성하고 있기 때문에) 따라서 무조건 Dashboard에 종속되어야 하는 도메인은 아니라고 생각되긴 합니다.

말씀하신 Statistics별도의 repository 및 service은 다른 것을 뜻합니다.
StatisticsDashboard entity에 속하는 클래스이고, repository 및 service는 PopulationStatistic에 해당하는 것입니다.
@rlacksgus97

@eun-seong
Copy link
Member Author

@rlacksgus97 말씀해주신대로, 네이밍을 전체적으로 통일하는 것이 필요해 보여요.
현재 상황을 정리해보자면 아래와 같아요.

types

  • (*)AnalysisType: DashboardDto 변환 시, population 통계량 필요 여부 판단
  • (*)DashboardStatisticType : DashboardDto 변환 시, 어떤 방식으로 계산할 것인지 판단
  • DashboardType : Dashboard 타입. 프론트에서 사용
  • (*)StatisticsCalculationType : 문항 별로 어떤 계산 방법을 사용할 것인지 판단

dashboard

  • Dashboard: (Entity) relation&period 별 유저가 받은 응답을 모수로한 통계량
    • (*)Statistics : Statistic 세트. Statistic을 관리(추가,갱신)하기 위한 로직이 존재
      • Statistic : Question 별로 StatisticsCalculationType에 따라서 계산된 통계량
        • RatioStatistic : Statistic의 구현체. StatisticsCalculationType.RATIO 일 경우 해당
        • AverageStatistic : Statistic의 구현체. StatisticsCalculationType.AVERAGE 일 경우 해당
  • DashboardComponent : (DTO) DashboardType
    • AverageDashboardComponent : DashboardComponent의 구현체. DashboardStatisticType.AVERAGE일 경우 해당
    • BinaryDashboardComponent : DashboardComponent의 구현체. DashboardStatisticType.BINARY일 경우 해당
    • RatioDashboardComponent : DashboardComponent의 구현체. DashboardStatisticType.RATIO일 경우 해당

statistic

  • (*)PopulationStatistic : (Entity) dashboardType에 따른 전체 사용자의 응답을 모수로한 통계량
    • (*)EntireStatistic : Question 별로 StatisticsCalculationType에 따라서 계산된 통계량
      • AverageEntireStatistic : EntireStatistic의 구현체. StatisticsCalculationType.AVERAGE일 경우 해당

변경 제안

위에서 (*) 표시된 것들에 대해 네이빙 변경 제안드립니다.

AnalysisType

=> 제거

해당 타입이 population 통계량이 필요하냐 안하냐에 대한 판단이라서, 이 enum을 제거하고 boolean으로 대체하는 건 어떨까요?
개발 당시 이 의도로 정의한 타입이기도 해서 boolean으로 변경해도 문맥이 달라지진 않을 것 같아요.
변경된다면 DashboardTypeboolean populationStatisticRequired 필드가 추가될 것입니다.

DashboardStatisticType

=> DashboardComputationStrategy

Dashboard가 어떤 형식으로 보이는지에 대한 타입이라, DashboardViewType과 같은 클래스명이 더 적절해 보입니다.

말씀해주신 내용을 고려해보았는데, view는 그래픽적으로 보이는 것이라는 느낌이 강하다고 생각해요.
그래서 계산하는 "전략"이라고 바꿔서 접근해보았습니다.

StatisticsCalculationType

=> QuestionStatisticStrategy

정리해보니 "문항"에 대해서 통계량을 계산하는 것으로 귀결되더라고요.

Statistics

=>제거
Statistics는 Statistic를 관리하는 매니저 역할을 가지고 있었는데, 오히려 복잡도를 증가시키는 것 같아 제거하고 기존에 있던 로직을 Dashboard로 옮기는 게 어떨까요?

PopulationStatistic

=> PopulationDashboard

사용자의 대시보드는 Dashboard, 전체 통계는 전체 사용자의 Dashboard로 칠 수 있지 않을까 싶었습니다.
Dashboard와 가지고 있는 필드도 거의 유사해서, 의미상 Dashboard 라는 이름을 사용하는건 어떨까요?

EntireStatistic

=> PopulationStatitsic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants