문의 사항
팀 사용 기술, 컨벤션 관련하여
자바 버전
- 한빈: 17 사용 추천
- 신 버전에서 새로 등장한 기술을 익혀보는 것이 좋다고 생각
- instance of 패턴 매칭(16)
- 레코드(16)
- 가능하다면, 모듈 접근제한 기능(9)
- 데브코스 내에서 신버전 사용을 권장하는 분위기(16, 17 이상)
- 민성, 민재: 굳이 높은 버전을 쓸 필요가 없다
- 민성: 어차피 11버전 이후로는 자바를 계속 쓰기 보다는 코틀린으로 넘어가는 추세다
- 민재: 직렬화 라이브러리 사용할 때 11버전이 아닌, 이후 버전 사용 시 이슈 생기는 등, 안정성이 아직은 낮다고 생각함
- 훈기: 16에 레코드를 사용하려 하는데 16버전과 17버전 중 고민이 됩니다. 스프링 표준 버전에 17이 있었다고 합니다.
- 전체적으로, 11버전 이상을 사용하자는 데에는 일치
- 집들이 게시글 엔티티와 질문 게시글 엔티티 분리 문제
- 둘이 동일 상속 계층도 내에 있다고 볼 것인지
- 이 경우 어떤 테이블 전략을 쓸 것인지,
- 단일 테이블 내에서 구별자 컬럼을 사용하는 방식
- 조인 전략 사용하기
- 아니면 상속 계층도와 별개로 완전 별개의 테이블이 되어야 할지
이미지 처리에 관하여
- 이번 프로젝트에서는 상당히 많은 부분에서 이미지 업로드, 조회 기능을 사용합니다.
- 어떻게 구현할 것인가에 대해 다양한 의견이 나왔으며,
- 팀원들 전체적으로 아직 생소한 구현 사항이기에, 더 학습 및 논의가 필요하다고 느꼈습니다.
- 민성: 이미지의 순서에 관하여
- 이미지 url을 본문 컨텐츠에 literal로 넣어도 충분할까요?
- 아니면 이미지에 대한 index?만 본문 컨텐츠에 넣고, 실제 이미지 url을 url 관리 테이블을 만들어서 관리해야 할까요?
- 훈기:
- S3나 FireBase Storage, Google Driver 같은곳에 이미지를 저장하게 하고 그 url을 불러와 1:1로 이미지 매핑이 필요한건 따로 테이블을 만들어 url을 넣고 매핑하고 아닌건 본문 컨텐츠에 이미지 url을 그대로 넣는 방식으로 즉, md 형식처럼 저장하는 방식으로 하려하는데 괜찮을까요? (대신 이러면 이미지 삭제를 어떻게 해야할지는 잘 모르겠습니다.)
CI 기술 도입에 대한 논의
- 훈기
- 기간도 너무 짧고 무조건 써야한다고 하기는 애매해 보입니다. 저희끼리도 근거가 아직 좀 더 조사해서 의견을 내려고 하는데 멘토님 의견도 듣고 싶습니다.
서비스 계층 인터페이스
- 훈기
- Service 인터페이스 정의 후 구현 방법을 쓰려고 하는데 멘토님은 어떻게 생각하시나요? 저희는 일단 쓰면 유연한 설계가 가능하다고 생각해서 쓰기로 하였습니다.
- 전체적으로, Service와 ServiceImpl 분리에 대해
- 분리 시 유연성을 가질 수 있음에는 많이 동의하였으나
- 실질적으로 그걸 활용할 때가 있으냐에 대해서는 회의적인 의견들이 있었음
- 민재
- ShortURL 과제의 경우 사용 알고리즘을 동적으로 변경하고자 할 때 도움이 될 수는 있었음
PR 단위
- 현정
- 각자 맡은 부분 개발을 진행하면서, PR 단위를 어느 정도로 잡을 것인가에 대한 이야기가 있었는데, 기능 단위(feat), 에픽, 스토리 단위 등 여러 의견이 있었습니다. 일반적으로 실무에서 진행하는 PR 단위나, 멘토님이 바람직하다고 생각하는 단위가 있을까요?
+ 추가적으로, 팀원들끼리의 ShortURL 리뷰를 마무리 하였으므로 멘토님께서 리뷰해 주시면 감사하겠습니다!!
답변
- 노션 확인하고 코멘트 드립니다.
- 자바버전 : 11, 17 어떤걸 쓰시던 상관없습니다. 좀 더 강력하게 도입하고 싶은 버전이 있으신 분이 다른 팀원들을 충분히 설득하시거나 그런것이 없을 경우 간편히 다수결로 정하시면 될 것 같습니다. 결정에 너무 시간쓰지 않으셔도 됩니다.
- 엔티티 분리는 어떤 방식을 써도 관련 없지만 동일 상속 계층으로 구성해보시는걸 추천합니다.
- 이미지를 컨텐츠에 직접 넣을거 같진 않고, 대체할 뭔가로 바꿔서 넣을 것 같아요. 이미지 정보는 별도의 테이블에 넣을 것 같구요.
- ci는 MUST개발 이후 일정에 맞춰서 추가로 고려해주세요.
- 오래전에 현업에서도 이와 관련해서 논란이 있었으나 결국엔 조직별로 규칙을 정하고 사용하는 것 같아요. 팀원들이 인터페이스 구현방식으로 쓰기로 했다면 그렇게 사용하셔도 문제 없을 것 같습니다. 저는 서비스를 여러 구현으로 나눠쓰는 경우가 많지 않아서 서비스를 일반 클래스로 하는 편입니다.
- PR 단위는 상황에 따라 질 수 있습니다. 팀원간 코드리뷰를 계획하고 있다면 주1회 정도만 할 수 있게 적절한 PR 범위를 잡는게 좋을 것 같습니다. 저는 기능 단위로 PR을 잡고 있습니다.