레벨4에 추가할 기능 및 프로젝트 방향

[jminkkk]

즈후가 정리한 이슈를 참고하여 레벨 4동안 진행할 기능에 대해 논의해봅시다.

회의 시간

월 4:30

새 기능 추가

• "구경가기" 검색
• 좋아요 기능
• "구경가기" 좋아요 순 정렬
• 퍼블릭, 프라이빗 구분
• 댓글
• 코드 고정 핀(즐겨찾기) 기능
• 익스텐션 / 플러그인
• n개씩 보기
• 계정 찾기
• AI로 제목, 설명 생성
• 스크랩
• 조회수

레벨4 동안 프로젝트 방향

[jminkkk]

추가 기능

• "구경가기" 검색
• 좋아요 기능
• "구경가기" 좋아요 순 정렬

레벨 4 방향

최소한의 기능 추가 & 기존 서비스를 리팩토링하면서 유지보수한다.

• 서비스를 운영할만한 기능은 현재만으로도 충분하다고 생각한다.
  • MVP인 템플릿 관리가 구현 되었고 구경가기까지 구현되어 있음
• 더불어 현재 리팩토링 및 개선이 필요한 기능이 많다.
  • 검색 속도 개선, 구구 500 에러, 각종 VoC, QA 에서의 보완이 필요한 사항이 많다.
  • 테스트 보완이 (매우) 또한 필요하다.

[kyum-q]

레벨 4

추가 기능

• 퍼블릭, 프라이빗 구분
• 좋아요
• 댓글
• "구경가기" 검색
• "구경가기" 정렬
• 코드 고정 핀(즐겨찾기) 기능
• 플러그인

리팩터링

• 필수정보는 * 표시
• n개씩 보기
• 에러코드 반영

[zangsu]

• 즐겨찾기 기능 (pinned)
• 익스텐션 / 플러그인 (필수는 아니나, 니즈가 꽤나 많고 나도 욕심이 나는 ~~)
• 태그 대소문자 구분 안하고 중복 검증하게
• n개씩 보기
• 계정 찾기

---

• 게시글의 public, private 기능
• 댓글 기능

[Hain-tain]

레벨 4에서 반드시 다뤄야 한다고 생각하는 부분

• 로그인 후 랜딩페이지의 ‘로그인하러가기’ 안 보이게
• 소스코드 길게 입력 안 되게 막기
• 현재 위치에 따라 헤더 하이라이팅하기
• 동일 경로의 경우 히스토리 쌓지 않기
• 회원가입, 로그인 에러 메시지 더 상세하게

레벨 4에서 다뤄보고 싶은 부분

• AI로 제목, 설명 생성
• 좋아요 기능 및 스크랩 기능

[zeus6768]

UI/UX

• 제목과 설명 입력 귀찮다, 입력을 인지하기 어렵다 (2, 6, 40, 95, 101)
• 파일명 입력 칸 안 보인다. (10, 36, 72)
• 로그인 후 랜딩페이지의 ‘로그인하러가기’ 안 보이게 (24, 27)
• 뒤로가기 제스처 (39, 75)
• 취소버튼 Alert (8)

새로운 기능

• 익스텐션 (5, 26, 29, 32)
• 구경가기 검색 (53, 89, 98)
• 조회수, 좋아요 (66, 94)
• AI로 목차, 요약, 제목, 설명, 태그 언어 생성 (2, 6, 7, 101)

[vi-wolhwa]

1. 레거시 코드 리팩토링

2. 개발 및 개선

(1) 기능개발 : 30%

• 구경가기 검색기능
• '내 템플릿' 페이지에서 사용자 통계
• 좋아요, 조회수, 스크랩

(2) 기능/버그개선 : 70%

• 런칭데이 QA 한 개씩 반영

[Hain-tain]

🙋🏻‍♀️ 레벨4 동안 프로젝트 방향에 대해 이야기를 나눠보고 싶습니다.

어제 회의에서 새 기능 추가에 대한 논의를 먼저 시작해서인지 기능 추가하는 것이 default 가 되어버렸고, 추가하는 기능들과 새 기능 추가에 들일 리소스의 크기에 대해서도 잘 협의가 되지 못했다는 생각이 들었습니다.

따라서 오늘 오전 회의를 제안합니다. 안건은 아래와 같습니다.

1. 각자 레벨 4 프로젝트에서 중심을 두고 싶은 부분이 어떤 부분인지.
2. 새 기능 추가가 필요하다고 생각하는지
   2-1. 필요하다면, 어떤 기능이 최우선적으로 필요하다고 생각하는지

회의 시간: 11시 ~ 12시

[zangsu]

도출 되었으면 하는 결과

1. 각자가 어떤 것을 원하는지 상황 공유 (러프하게)
2. 1의 결과를 토대로 우리의 방향성을 확립한다.

[zangsu]

켬미

우리의 서비스를 확장하기 보단 보완시키고 싶다.

좋아요 기능이 들어가는 이유
-> 구경가기를 만들어 두었고, 이 구경가기를 더 잘 활용하기 위해 좋아요 기능이 필요하다.

초롱

새 기능 관심 없고, 성능 개선과 코드 개선, 테스트코드 추가, 테이블 구조 변경 등 리팩토링에 중점을 두고 싶다.
우리 서비스 코드를 좋게 발전시키고 싶다.

서비스 개선보다 코드 개선, 구조 개선 등에 관심이 더 많다.

짱수

유저의 경험 개선 및 문제 발생에 대처할 수 있는 서비스를 만들고 싶다.
+) 우리가 원래 제공하고자 했던 핵심 가치를 확실하게 제공하고 싶다.
-> 코드를 빠르게 저장하고 빠르게 확인한다. (개인의 코드 관리)

월하

코드 리팩토링과 기능 개선을 적절히 분배해서 병렬적으로 발전 시키고 싶다.
팀원들이 여럿이기에 하나에만 집중을 할 필요는 없다고 생각한다.

마스터위

리팩토링 4 : 새 기능 6
서비스를 사용해 보니 불편한 점이 너무 많아서 기능 개선이 필요하다.

+) 기능은 목록화가 되어 있는데 리팩토링의 리스트업이 되어있지 않아서 추상적으로 느껴진다.

마위가 생각하는 새 기능 : 검색 쿼리 개선 등
리팩토링 : 기능적 변화는 없이 코드 개선, 코드 추상화 등

몰리

Level 4는 구현을 "잘" 해야 하는 기간이라고 생각한다.
우리의 코드는 성능, 테스트, 클린코드 어느 관점에서도 부족하기에 이 부분에 대한 보완이 필요하다.
그 이후 새 기능에 대한 추가가 필요하다.

위의 관점들에 대한 퀄리티가 충족 되는 새 기능이 추가 되어야 한다.

헤인

리팩토링 3 : 새 기능 + 성능 개선 7

리팩토링이 필요하지만, 현실적으로 완벽한 것을 추구하기는 어렵다.
개발자로 이것 저것 많이 시도하는 것 보다 실사용자에게 피드백을 받고 개선 시키고 다시 피드백을 받는 하나의 사이클 경험이 우리의 원래 니즈
사이클이 거의 돌았기 때문에 개선을 시키는 것이 중요하다.
이 관점에서의 새 기능이 필요하

[zangsu]

각자가 Level4 팀 프로젝트에서 가져가고 싶은 경험

마위, 헤인 : UX 개선
몰리 : 개선 경험 (수치로 파악할 수 있는 것들)
켬미 : 사용자를 유치해 보고 싶다. (배포를 하고 싶고, 이를 위해 안정적인 기능을 확보하고 싶다. + 사용자가 할 수 있는 기능)
초롱 : 1. 쿼리 개선 / 2. 테스트코드 개선 / 3. 모니터링 개선 (라벨링, 알림.. 효율적으로 사용하기)
짱수 : 이미 돌아가는 레거시에서 새로운 기능을 추가하더라도, 서비스를 계속 유지보수 하는 경험 (굳이 완벽한 코드를 만들기 위해 기능 추가를 All stop 할 필욘 없음)
월하 : 실 사용자를 유치하기 위해 기능을 추가, 치명적인 QA 를 해결

[Jaymyong66]

리팩토링이란 무엇인가?

마위, 헤인 : DX 증가(코드 추상화, 가독성 개선 등), 요구사항 변경 X... 성능 개선은 기능으로 되지 않나
켬미, 몰리 : 리팩토링은 기능이 변화되는게 아니다. 예를 들어 검색 기능은 유지되니 검색 쿼리 개선은 리팩토링이다

[zangsu]

각자 원하는 리팩토링 / 성능 개선 등등... 에 해당하는 부분을 리스트업 해둡시다.

[HoeSeong123]

백엔드 리팩토링 리스트업

[jminkkk]

리팩토링

테스트 코드

• 인수 테스트 작성
• 단위 테스트 작성
• 인수 테스트 환경에서 발생할 환경상 문제 (ex.시간, 환경 일치) 개선

각 도메인간 의존성 재설계

현재 도메인 간 의존성이 잘 관리 되고 있지 않다. (서비스가 서로를 가리키는 등)

• 의존성 설계
• 코드 변경
• 테이블 정규화 / 반정규화할 것이 있는지 확인

성능 개선

검색 기능

• like 절 사용 -> 인덱스 적용 & 수치 측정
• 인덱스 -> 검색 전문 인덱스 적용 & 수치 측정
• 검색 전문 인덱스 적용 -> 검색 엔진 구축 & 수치 측정

쿼리 내용 개선

• 레포지토리의 사용자 커스텀 메서드의 쿼리가 어떻게 발생되는지 확인
• 쿼리가 의도한 바와 다르게 발생되는 경우 개선
  • 현재 이를 확인하지 않고 있어서 N + 1 문제가 발생해도 이를 알 수가 없는 상태

쿼리 갯수 개선

• 각 엔드포인트 별로 몇개의 쿼리문이 발생되는지 측정
• 각 엔드포인트당 쿼리문의 갯수를 최소화

[HoeSeong123]

• 5차 데모데이 요구사항 만족 (검색 기능 개선)

  • 인덱스 설정
  • 몰리가 말한 엔진?? 그런 것도 설정
  • 근데 잘 모르는 분야라 얼마나 걸릴지 잘 모르겠음
    • 2주? 정도 예상합니다.

• 테스트 코드 개선

  • 현재 작성되어 있지 않은 기능 또는 예외에 대한 테스트 코드 작성
  • 현재 작성되어 있는 테스트 코드가 유효한 테스트인지 확인 후 개선
  • 페이크 디비를 사용할지 말지도 정해야 함
    • 이로 인해 테스트 코드 자체에 대한 학습이 필요하다고 생각됨
  • 내 생각엔 1주 ~ 1주 반 정도면 충분하다고 생각됨.

• 모니터링 개선

  • 모니터링을 효율적으로 활용할 수 있는 방법에 대한 고민 및 학습
    • 어떤 알림을 띄울 건지
    • 라벨 별로 정리해서 보여주는 것
    • 어떤 정보를 공개할지
  • 이것도 1주 ~ 1주 반 정도면 충분하다고 생각됩니다.

• 테이블 구조 개선

  • 외래키 제약조건, 양방향 연관관계 등에 대해서 고민 및 학습이 필요함
  • 해당 부분이 개선되면 현재 코드도 깔끔해질 것 같고, 성능도 개선될 것으로 기대됨.
  • 또한 이후 기능 구현에 있어서도 유용할 것으로 예상
  • 1주 안으로는 완료할 수 있을 것으로 생각됨.

[zangsu]

DX - 객체 의존관계 다시 고민해보기

-> 객체지향을 잘 지키고 있나? 에 대한 점검 (아마 하루 안걸릴듯?)

-> 개선사항이 생겨나면 시간은 많이 걸리는 작업이 될 것 같음

DX - 동적쿼리 개선

-> 새로운 라이브러리 도입 (QueryDsl)

성능 - 쿼리 성능 최적화

검색, 필터링 작업에 대한 성능 최적화

• 인덱스 걸기
• 이외의 어떤 작업이 필요한지 학습 필요 -> 같이 해보면 더 좋을 것 같아용

[kyum-q]

• DB 성능 개선

  • MySQL 인덱스 사용으로 검색 성능 개선
  • (성능개선에 도움이 된다면) MySQL에서 PostgreSQL으로 마이그레이션

• 테스트

  • 레파지토리 테스트 구현
  • 각 기능에 따른 인수 테스트 구현
  • Swagger에 존재하는 에러 테스트 보완

[HoeSeong123]

검색 기능 (7 ~ 10)

• 인덱스 적용 & 수치 측정
• 검색 전문 인덱스 적용 & 수치 측정
• 검색 엔진 구축 & 수치 측정

쿼리 개선 (7 ~ 10)

• 쿼리가 의도한 바와 다르게 발생되는 경우 개선
  • 레포지토리의 사용자 커스텀 메서드의 쿼리가 어떻게 발생되는지 확인
  • 현재 이를 확인하지 않고 있어서 N + 1 문제가 발생해도 이를 알 수가 없는 상태
• 각 엔드포인트 별로 몇개의 쿼리문이 발생되는지 측정
• 각 엔드포인트당 쿼리문의 갯수를 최소화

테스트 코드 (7 ~ 10)

• 각 기능에 따른 인수 테스트 구현
• 사용자 시나리오에 따른 통합 테스트 (Http 요청 ~ Http 응답) (E2E 테스트)
• 단위 테스트 작성 (레포지토리, 도메인 등등)
• 현재 작성되어 있지 않은 기능 또는 예외에 대한 테스트 코드 보완
  • 현재 작성되어 있는 테스트 코드가 유효한 테스트인지 확인 후 개선
• 테스트 환경에서 사용할 디비 결정 (ex. 페이크디비)
• 인수 테스트 환경에서 발생할 환경상 문제 (ex.시간, 환경 일치) 개선

테이블 구조 개선 (2 ~ 3)

• 외래키 제약조건, 양방향 연관관계 등 개선
• 테이블 정규화 / 반정규화할 것이 있는지 확인

도메인 (3 ~ 5)

• 각 도메인간 의존성 재설계

모니터링 (3 ~ 5)

• 모니터링을 효율적으로 활용할 수 있는 방법에 대한 고민 및 학습
  • 어떤 알림을 띄울 건지
  • 라벨 별로 정리해서 보여주는 것
  • 어떤 정보를 공개할지

DB 툴 변경 (1 ~ 2)

• 새로운 라이브러리 도입 (QueryDsl)

MySQL에서 PostgreSQL으로 마이그레이션 (이건 선택)

[Jaymyong66]

30일

• 에러핸들링 : 2일

• hook개선, hook분리 : 3일

• 공통 로직, 디자인토큰 반영 : 2일

  • 스토리북 배포

• 컴포넌트 재사용에 대한 고민, 스토리북 : 5일

  • Flex 없애고, 스토리북 정비, 피그마, 컴포넌트 생성 방식 일관화, 최소한의 추상화, 서브 컴포넌트화
  • 피그마는 가능한 선에서만 사용, 정리는 하자

• QA 반영

• 토스트 UI 개선, 로직 : 1일

• components의 폴더 구조 개선

  • 예를 들면, 도메인 별로

• E2E 테스트

  • 최대한 리팩토링하면서 테스트코드도 리팩토링하지 않도록

• 검색결과 성능 개선 - 이미 검색결과가 없으면 더이상 쿼리 보내지 않도록

• SEO

• 성능개선

• 접근성 개선

나중에

• 다크모드 반영 고민