Code Review History
진행했던 코드 리뷰 중 의미 있는 것들을 기록합니다. - Codesquad, Codestates, Programmers
JPA entity 의 식별자 기본 생성 전략 선택
@GeneratedValue strategyEntity 의 field type 은 무엇이 적절한가?
Entity의 field type@Controller
클래스 레벨에 @RequestMapping
을 명시하는 것
@Controller
클래스 레벨에 @RequestMapping
을 명시하는 것nit
저는 RequestMapping을 클래스 레벨로 묶는 것을 선호하지 않습니다.
경험상 에러가 발생하면 url을 통해 엔드포인트로 바로 가고 싶은 니즈가 있는데, 이렇게 분리되면 복붙이 불편했습니다.
GET 메서드에 payload 를 사용한 것
GET 메서드에 payload를 사용해도 되는가?Builder Pattern 사용
Builder PatternAPI 설계는 어떻게 해야 되는가?
특정 목적의 API는 어떻게 만들어야 할까?현재는 access token(JWT)만 내려주고 있지만, 추후에는 refresh token도 추가해 볼 생각입니다. 두 토큰이 똑같이 authId
와 expired_time
만을 갖게 하려고 했는데, access token과 refresh token과 차이를 나게하는 부분이 expired_time
만 있게 해도 되는지 잘 모르겠습니다. (둘을 구분할 수 있는 속성이 더 있어야 하는지?)
authId
와 expired_time
만을 갖게 하려고 했는데, access token과 refresh token과 차이를 나게하는 부분이 expired_time
만 있게 해도 되는지 잘 모르겠습니다. (둘을 구분할 수 있는 속성이 더 있어야 하는지?)보통 claims를 활용합니다. registerd claims를 활용한 예시를 첨부합니다.
TimeZone.setDefault(TimeZone.getTimeZone("GMT"));
에 대한 리뷰
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에서 TIMESTAMP
와 DATETIME
타입의 차이
TIMESTAMP
와 DATETIME
타입의 차이한방 쿼리 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
을 명시하는 것
@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 표현에 대해
SpringBoot 2 (Spring 5) 까지는 큰 문제가 없지만 SpringBoot 3 (Spring 6) 부터는 문제가 될 수 있습니다.
Last updated
Was this helpful?