[Audit] Code Design: Service→PORO 이관 & 파이프라인 분해 (DESIGN-01~04)

[stadia]

요약 (Code Design 카테고리 묶음 · Medium/Low)

---

DESIGN-01 (Medium) — Service Object 명명 (thoughtbot PORO 관점)

• app/services/*_service.rb 11개. *Service 접미사가 도메인 개념을 흐림.
• 맥락: 이 프로젝트는 이미 app/functions/(모듈 함수)로 클래스리스 리팩터링 진행 중이며 OperationService(dry-monads Result 파이프라인)는 합리적 패턴. 전면 개명보다 점진 이관이 적절.
• 권장: 신규 로직은 app/functions/ 모듈 또는 도메인 명사 PORO로. 기존 *Service는 상태 없는 것부터 점진 이관. 무리한 일괄 개명 지양.

DESIGN-02 (Medium) — ArticleAgentsService 복잡도

• app/services/article_agents_service.rb(242줄, complexity 277, smells 43, D). 다단계 파이프라인 + 프롬프트 문자열까지 한 클래스에 집중.
• 권장: 각 step을 개별 함수/PORO(Articles::Embedding, Articles::Humanization, Articles::JapaneseTranslation)로 추출. 서비스는 오케스트레이션만. 프롬프트는 별도 상수/템플릿으로 분리.

DESIGN-03 (Medium) — 유사 리스트 뷰 3종 중복

• app/views/profiles/{post_list,blog_list,comment_list}.rb (동일 cost 23.77).
• 권장: 공통 Profiles::ActivityList 컴포넌트로 통합. (CQ-01과 연계)

DESIGN-04 (Low) — 법적 문서 페이지 Phlex 복잡도

• app/views/home/{privacy_policy,terms,about}.rb (F/D). 대부분 정적 콘텐츠.
• 권장: 장문 정적 콘텐츠는 Markdown/HTML 파셜 또는 I18n YAML로 옮기고 Phlex는 래핑만.

---

전체 감사 리포트: RAILS_AUDIT_REPORT.md → §6 Code Design