[Weekly Feedback] 05. 정글 끝나고는 이렇게

주간 피드백

• 왜 그렇게 로드맵을 만들었는지에 대한 설명 출력(왜 이런 코스를 추천하는지): 서비스 이용자에게 서비스에 대한 신뢰도를 향상시킬 수 있을 것
• 댓글 작성자 작성일 추가 할 것
• 로드맵이 2개씩 만들어진다.: 정렬 순서 불러오기 / 백에서 페치 중에 오류가 발생한 듯

기능 추가 제안

• 다양한 공부 방법, 자료 소스 등을 제공. 처음하는 사람을 위해,
  • npm이 뭐고
  • 왜 배우고
  • 무엇으로 학습하느냐
  • 블로그 → 글 쓰고 나서 우측 버튼을 클릭하면 그 개념에 대한 ai가 설명을 작성해 주는 기능
  • 좋아요 보여야
• elastic search 해보면 좋지만, 시간이 별로 없으니 ⇒ mysql의 full text search 를 통해 지원 기능을 이용해 보는 것 추천
• 페이지 오류: 정렬 조건 없을 때에는 랜덤으로 가져온다. 좋아요 없을 때 후속 정렬: 중복데이터일 수 밖에 없으니 / 최신을 위로 / id 값
• 참여한 사람 누구인지 보여주는게 좋을 듯
• db 컬럼 길이 제한으로 터질 수 있음→ 제목 길이: internal server error 에러 명확해야

코드 피드백

• println 대신 로거를 써라
  • 로컬에서는 출력되고 베타 운영에서는 출력 안되도록해야
  • if문 대신에 로거를 사용하면 log.debug(); ⇒ 로그 레벨이 디버그 이상일 때에만 출력되므로 일일히 if 문 안 써도 됨.
  • println이나 console.log를 쓰면 ==서버나 브라우저 성능을 많이 잡아먹는다.==
• 답이 없는 사항에 대한 것들:
  • 문제 발생 - 예외로 처리햐냐 or status 반환으로 처리하냐?
  • dto, entity 변환은 어느 계층에서 해야 하나?
  • 무조건 선배 개발자에 물어보는게 좋다.
  • 한 명한테는 물어보지 않는다.
• DTO, Entity 변환은 어느 계층에서 → Service에서 toEntity등 entity에서 구현된 함수를 통해 dto, entity로 변환
  • 프로그래밍을 할 때에는 » 안정적인 계층 -> 불안정한 계층: 안정적인 계층이 불안정한 계층에 의존(자바 언어적으로는 import)해야 한다.
  • 변화가 적은 곳, 변화가 있으면 많은 부분에서 영향을 받는 중요한 곳: Entity(설계의 기반)
  • 변화가 잦은 곳, 변화가 있어도 적은 부분에서만 영향을 받는 덜 중요한 곳: DTO(기획에 따라 바뀔 수 있음)
• 구독 인원 수 표시: 아직 백엔드에서 보내주지 못하고 있음
  • 동시성 이슈
  • 내가 클릭했는데 3명이 왜 올라가지?: 새로고침해서 할 때에는 3명까지 반영해도 되지만
  • 내가 클릭하면 프론트에서 그냥 +1만 해서 보여주는게 사용지 입장에서는 리즈너블
  • 즉, 내가 클릭했을 때에만 제대로 올라가는 것이 반영되는 것이 우선이지, 정확한 수치를 보여 줄 필요는 없다.
• 404? 백엔드에서 응답값 어떻게? 에러 어떻게 처리하는지 보기 때문에 S3 문제인것 같으니 대답해야할 것👉 결국 프로젝트 추가 개선 없이 끝나서 해결이 안됐다. 하…
• 가능 질문: 왜 프론트 본인이 보았을 때 장단점?
• 댓글 기능
  • 댓글 페이지네이션 / 게시글 검색 페이지네이션에서: 왜 full url을 가져와야 하는건지?
  • 왜 그렇게 구현했는지 이유가 합당해야 함: 기존 방식보다 어떤 점에서 나아서 선택했다…
    • 처음 페이지네이션을 구현할 때 프론트엔드에서 요청한 대로 Previous page, Next page URL을 전달해주는 API를 작성하였으나,
  • 이 방법은 NO Offset방식으로, 쿼리 속도를 높이기 위한 방법으로 사용되는 것이다. 즉, 아무런 생각없이 하라는대로 한 것인데, 그렇다보니 No Offset 방식이 아닌 전달 데이터만 Previous Page, Next Page를 보여주는 가짜 No Offset방식으로 구현된 것이다: https://jojoldu.tistory.com/528
  • 댓글 수정, 삭제, 좋아요 기능이 들어가게 되면 numbering은 의미가 없을듯: 다시 autoincrement된 primekey를 쓸 수 밖에 없음.pk값이 있으면 따로 roadmap id를 만들 필요가 없음.
• 날짜 포멧이 페이지 마다 차이가 남: 날짜 가공 시켜서 보내줄 것이냐 아닐 것이냐. 일시필요하다면 하나의 포맷으로 정해야: 이 것도 일종의 convention
  • 형식(포멧) 자체는 화면 담당자(프론트엔드)가 결정
  • 백엔드 → 플랫폼 성격이 강해서 api가 제공하는 정보를 가공해서 전달해야함
• 테이블의 명명을 대체로 표준으로 할 것 : 일관성 있도록 컬럼, 필드명 동일하게!
• 테이블 스키마 snake_case vs. json 스키마: camelCase

Gradle

Gradle multi module을 확인해 볼 것. Mono Repo == Multi Module(이와 별개로, multi repo로도 구현을 해 볼 것)

• private api(부와 통신하는 코드): DTO → 내부에서 원하는 형태로 JSON 내려주어야
• public api(외부와 통신하는 코드): DTO → FE가 원하는 형태로 JSON 내려주어야
• core(주요, 공통 코드): Entity
• batch: 같은 계층끼리는 서로 참조하지 않음

시연 시 주의사항

• 시연할 때에는 최신순으로 보이게
• 안 쓸 거라고 생각되는 것은 ui에서 빼기
• 데이터 클렌징: 시연 데이터를 좋은 퀄리티의 시연이 가능하도록 만들어야.
• ui 쪽 개선이 끝나면 보이지 않는 오류들 모두 잡아야 함
• 미리 보기 어떻게 구현할지는 프론트엔드가

프로그래밍을 더 잘하고 싶다면?

다시 한 번 강조하면: 중요한 코드는 안중요한 코드를 import해서는 안된다. 안 중요한 것은 중요한 것을 알아도 되지만, 중요한 것은 안중요한 것을 알면 안된다.

객체지향 프로그래밍에 대한 내용은 다음 책을 읽어보는 것을 추천한다. 프로그램을 설계할 때 어떤 기준으로 설계해야 하는가를 설명하는 것들이다.

• Interface는 왜 써야? 구현체가 바뀔 수 있으니 유연한 대응
• 서비스 쪽은 비즈니스 로직을 담고 있는데 바뀔 일이 있나? 레포지토리는 언제든 교체될 수 있지만.

이런 문제들에 대한 근거를 대려면 책을 많이 읽어야 한다.