Code Review History

진행했던 코드 리뷰 중 의미 있는 것들을 기록합니다. - Codesquad, Codestates, Programmers

JPA entity 의 식별자 기본 생성 전략 선택

@GeneratedValue strategy

Entity 의 field type 은 무엇이 적절한가?

Entity의 field type

@Controller 클래스 레벨에 @RequestMapping 을 명시하는 것

nit

  • 저는 RequestMapping을 클래스 레벨로 묶는 것을 선호하지 않습니다.

  • 경험상 에러가 발생하면 url을 통해 엔드포인트로 바로 가고 싶은 니즈가 있는데, 이렇게 분리되면 복붙이 불편했습니다.

GET 메서드에 payload 를 사용한 것

GET 메서드에 payload를 사용해도 되는가?

Builder Pattern 사용

Builder Pattern

API 설계는 어떻게 해야 되는가?

특정 목적의 API는 어떻게 만들어야 할까?

현재는 access token(JWT)만 내려주고 있지만, 추후에는 refresh token도 추가해 볼 생각입니다. 두 토큰이 똑같이 authIdexpired_time만을 갖게 하려고 했는데, access token과 refresh token과 차이를 나게하는 부분이 expired_time만 있게 해도 되는지 잘 모르겠습니다. (둘을 구분할 수 있는 속성이 더 있어야 하는지?)

  • 보통 claims를 활용합니다. registerd claims를 활용한 예시를 첨부합니다.

TimeZone.setDefault(TimeZone.getTimeZone("GMT")); 에 대한 리뷰

For most purposes, UTC is considered interchangeable with Greenwich Mean Time (GMT), but GMT is no longer precisely defined by the scientific community.

  • UTC 명시를 권장합니다.

DB에서 TIMESTAMPDATETIME 타입의 차이

한방 쿼리 vs 애플리케이션에서 조립

java spring init 설명

  • api 스펙을 공유하고 수정함에 있어 생산성을 고려해야 합니다.

    • swagger 를 통해 코드와 밀접하게 관리할 수 있다.

  • docker compose 활용을 권장합니다.

    • local 세팅으로 프로젝트를 띄우기에 가장 쉬운 방법이다.

  • readme 를 잘 활용해야 합니다.

    • 면접관은 readme 와 프로젝트 구조를 보고 더 볼지를 판단한다.

인증을 어떻게 해야되나?

  • 커리큘럼상 security 를 학습했지만, 지금 사용하기에는 너무 어려운 기술이다. 추천하지 않는다.

  • OAuth2 에 대해 학습은 좋지만, 구현은 추천하지 않는다.

  • session 구성을 권장한다.

레이어 구분과 dto

백엔드 개발 환경 설정

지속적인 기술 정보 얻기

  • RSS

  • 커리어리

코드 리뷰

멘토링 개선 의견

페어와의 기술 선택 협의에 작은 어려움이 있다. 리뷰시 더 강한 표현을 해주셨으면 좋겠다.

페어로 작업을 하다보면 어느 한쪽의 의견이 강하거나, 기술 선택에 욕심이 생길 수 있습니다. 아쉽지만 위 내용의 조율은 제가 개입하기 힘듭니다. 실제로 제 의견은 중요하지 않구요. 제가 드릴 수 있는 가이드는 아래 정도 일 것 같습니다.

  • 현재의 과정에서 최신 기술의 도입은 전혀 중요하지 않다.

    • 내부를 잘 모르는 외부 라이브러리의 도입보다는, 시간이 걸리더라도 내부를 직접 구현해보는 것을 추천한다.

  • 기능을 최대한 줄여라. 최소 기능이 구현된 후에 추가 기능을 고민하면 된다.

    • 본인들이 지금 생각하는 것보다 더 기능을 줄여야한다. 극단적으로 CRUD 만 해도 좋다.

라이브 세션 전에 주제를 공유하면 좋겠다.

본 gitbook 을 지속적으로 업데이트하겠습니다. 메이저 변경이 있는 경우 채널로 노티하고, 최소 D-1 에는 완성본을 공유할 수 있도록 하겠습니다.

PR 의 단위와 브랜치 활용에 대해

멘티님들 입장에서는 코멘트가 남아있으니 다 수정하고 머지해야 되는 것 아니냐? 고 말할 수도 있습니다. 하지만 0주차에 말한 것 처럼 제 코멘트를 모두 수용할 필요는 없습니다. 필요에 따라 본인의 생각을 관철하셔도 좋습니다.

그리고 한번 열린 pr 이 몇 번의 핑퐁을 거쳤음에도 닫히지 않는다는건 pr 의 단위가 너무 큰 것이 아닌가 고민하셔야 됩니다. 어렵겠지만 다수의 피쳐를 다수의 브랜치를 활용해 다수의 pr 을 올릴 수 있어야 합니다. 이것은 개발자가 많아지면 당연한 수순이고, 자연스럽게 컨플릭트를 피하기 위해 SRP 와 같은 설계를 고민하게 됩니다.

고급 기술 스택의 활용보다 이런 일련의 과정을 아시는 것이 더 중요하다고 생각합니다.

@Controller 클래스 레벨에 @RequestMapping 을 명시하는 것

Entity 의 field type primitive, wrapper 중 어느 것이 적절한가?

목적이 있는 문서를 작성하고 공유해라

  • API 명세 공유 방법을 고민하는 동료를 위해 방법을 찾음.

클린 코드를 공부해라.

  • 클린 코드, 이펙티브 자바 보다는 입문서로 엘레강트 오브젝트를 추천합니다.

JPA Entity 연관 관계를 어떻게 작성해야 될까?

  • JPA 의 기능들을 모두, 잘 써야만 된다는 생각에 대해서 입니다.

  • 최범균님 유튜브의 JPA 기초는 모두 시청하기를 권장합니다.

테스트

  • 풍부한 단위 테스트는 좋은 설계가 전제되어야 하고 테스트 객체에 대한 이해가 필요해 꽤 힘든 일입니다.

  • 현재 단계에서는 유스 케이스 기준의 시나리오 테스트를 추천합니다.

  • 테스트 더블에 대해 공부하는 것도 좋습니다. fixture, stub 위주

서버에 파일을 직접 저장하는 구현에 대해

  • 분산 환경에 적합하지 않습니다.

    • 파일 저장 요청을 통해 A 서버 파일이 저장됩니다. (murtipart)

    • 파일 불러오기 요청이 B 서버로 가면 A 서버의 파일을 가져올 수 있을까요?

  • 실무에서는 보통 S3 를 활용합니다.

    • 세션 클러스터링의 접근법을 공부하시면 좋습니다.

  • 만약 업무 요건 상 온프레미스로 구현해야 한다면 2가지 정도의 방법이 있을 것 같습니다.

    • 중앙 저장 공간을 구성한다. ex) NAS

    • DB 에 blob type 으로 저장한다.

중괄호 개행에 대해

추가 사이드 프로젝트 진행에 대해

제일 좋은 것은 지인이나 closed 한 커뮤니티에서 직접 모집하는 것 입니다.

  • 최근 가장 핫한 커뮤니티.

  • 하지만 태그 기능이 빈약하고 학생들 위주라 그런가 프론트 위주임.

  • 전통의 강자 커뮤니티

  • 리뉴얼이 되어도 올드한 느낌이 나긴 하지만, 근본 Java 로 시작한 커뮤니티라 백엔드가 많음.

  • 단 광고나 MVP 개발을 위한 글도 있으니 주의.

Bean Validation 실수

리소스 정의에 대해

인프콘 2022 에서 재미있는 주제

마인드셋에 대해

  • 업무라는 것에 대해 접근하는 생각

  • 기업의 간판은 전혀 중요하지 않다. 나에게 필요한 무엇을 경험할 수 있는 곳이 중요하다.

  • 소프트웨어만 지속적인 것이 아니다. 나 역시도 지속적이어야하기 때문이다.

멀티모듈에서 나오는 레이어 분리

프로그래밍의 옳고 그름이란

if-else 개선하기

nullable 객체의 예외 처리에 대해

테스트를 위해 운영 코드를 수정해도 될까?

결론부터 얘기하면 수정해도 된다 입니다. 하지만 수정의 목표는 설계를 좋게하기 위함이지, 테스트를 하기 위함이어서는 안됩니다.

TDD 를 꼭 해야 되는 것인가?

변경이 잦은 초기 개발 단계에는 어울리지 않을 수도 있다.

RequestMapping 의 value 표현에 대해

@GetMapping("/")
@GetMapping("")
@GetMapping

SpringBoot 2 (Spring 5) 까지는 큰 문제가 없지만 SpringBoot 3 (Spring 6) 부터는 문제가 될 수 있습니다.

Last updated

Was this helpful?