Code Review History
진행했던 코드 리뷰 중 의미 있는 것들을 기록합니다. - Codesquad, Codestates, Programmers
Last updated
Was this helpful?
진행했던 코드 리뷰 중 의미 있는 것들을 기록합니다. - Codesquad, Codestates, Programmers
Last updated
Was this helpful?
@Controller 클래스 레벨에 @RequestMapping 을 명시하는 것nit
저는 RequestMapping을 클래스 레벨로 묶는 것을 선호하지 않습니다.
경험상 에러가 발생하면 url을 통해 엔드포인트로 바로 가고 싶은 니즈가 있는데, 이렇게 분리되면 복붙이 불편했습니다.
authId와 expired_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 명시를 권장합니다.
TIMESTAMP와 DATETIME 타입의 차이api 스펙을 공유하고 수정함에 있어 생산성을 고려해야 합니다.
swagger 를 통해 코드와 밀접하게 관리할 수 있다.
docker compose 활용을 권장합니다.
local 세팅으로 프로젝트를 띄우기에 가장 쉬운 방법이다.
readme 를 잘 활용해야 합니다.
면접관은 readme 와 프로젝트 구조를 보고 더 볼지를 판단한다.
커리큘럼상 security 를 학습했지만, 지금 사용하기에는 너무 어려운 기술이다. 추천하지 않는다.
OAuth2 에 대해 학습은 좋지만, 구현은 추천하지 않는다.
session 구성을 권장한다.
RSS
커리어리
페어와의 기술 선택 협의에 작은 어려움이 있다. 리뷰시 더 강한 표현을 해주셨으면 좋겠다.
페어로 작업을 하다보면 어느 한쪽의 의견이 강하거나, 기술 선택에 욕심이 생길 수 있습니다. 아쉽지만 위 내용의 조율은 제가 개입하기 힘듭니다. 실제로 제 의견은 중요하지 않구요. 제가 드릴 수 있는 가이드는 아래 정도 일 것 같습니다.
현재의 과정에서 최신 기술의 도입은 전혀 중요하지 않다.
내부를 잘 모르는 외부 라이브러리의 도입보다는, 시간이 걸리더라도 내부를 직접 구현해보는 것을 추천한다.
기능을 최대한 줄여라. 최소 기능이 구현된 후에 추가 기능을 고민하면 된다.
본인들이 지금 생각하는 것보다 더 기능을 줄여야한다. 극단적으로 CRUD 만 해도 좋다.
라이브 세션 전에 주제를 공유하면 좋겠다.
본 gitbook 을 지속적으로 업데이트하겠습니다. 메이저 변경이 있는 경우 채널로 노티하고, 최소 D-1 에는 완성본을 공유할 수 있도록 하겠습니다.
멘티님들 입장에서는 코멘트가 남아있으니 다 수정하고 머지해야 되는 것 아니냐? 고 말할 수도 있습니다. 하지만 0주차에 말한 것 처럼 제 코멘트를 모두 수용할 필요는 없습니다. 필요에 따라 본인의 생각을 관철하셔도 좋습니다.
그리고 한번 열린 pr 이 몇 번의 핑퐁을 거쳤음에도 닫히지 않는다는건 pr 의 단위가 너무 큰 것이 아닌가 고민하셔야 됩니다. 어렵겠지만 다수의 피쳐를 다수의 브랜치를 활용해 다수의 pr 을 올릴 수 있어야 합니다. 이것은 개발자가 많아지면 당연한 수순이고, 자연스럽게 컨플릭트를 피하기 위해 SRP 와 같은 설계를 고민하게 됩니다.
고급 기술 스택의 활용보다 이런 일련의 과정을 아시는 것이 더 중요하다고 생각합니다.
@Controller 클래스 레벨에 @RequestMapping 을 명시하는 것API 명세 공유 방법을 고민하는 동료를 위해 방법을 찾음.
클린 코드, 이펙티브 자바 보다는 입문서로 엘레강트 오브젝트를 추천합니다.
JPA 의 기능들을 모두, 잘 써야만 된다는 생각에 대해서 입니다.
최범균님 유튜브의 JPA 기초는 모두 시청하기를 권장합니다.
풍부한 단위 테스트는 좋은 설계가 전제되어야 하고 테스트 객체에 대한 이해가 필요해 꽤 힘든 일입니다.
현재 단계에서는 유스 케이스 기준의 시나리오 테스트를 추천합니다.
테스트 더블에 대해 공부하는 것도 좋습니다. fixture, stub 위주
분산 환경에 적합하지 않습니다.
파일 저장 요청을 통해 A 서버 파일이 저장됩니다. (murtipart)
파일 불러오기 요청이 B 서버로 가면 A 서버의 파일을 가져올 수 있을까요?
실무에서는 보통 S3 를 활용합니다.
세션 클러스터링의 접근법을 공부하시면 좋습니다.
만약 업무 요건 상 온프레미스로 구현해야 한다면 2가지 정도의 방법이 있을 것 같습니다.
중앙 저장 공간을 구성한다. ex) NAS
DB 에 blob type 으로 저장한다.
최근 가장 핫한 커뮤니티.
하지만 태그 기능이 빈약하고 학생들 위주라 그런가 프론트 위주임.
전통의 강자 커뮤니티
리뉴얼이 되어도 올드한 느낌이 나긴 하지만, 근본 Java 로 시작한 커뮤니티라 백엔드가 많음.
단 광고나 MVP 개발을 위한 글도 있으니 주의.
업무라는 것에 대해 접근하는 생각
기업의 간판은 전혀 중요하지 않다. 나에게 필요한 무엇을 경험할 수 있는 곳이 중요하다.
소프트웨어만 지속적인 것이 아니다. 나 역시도 지속적이어야하기 때문이다.
결론부터 얘기하면 수정해도 된다 입니다.
하지만 수정의 목표는 설계를 좋게하기 위함이지, 테스트를 하기 위함이어서는 안됩니다.
변경이 잦은 초기 개발 단계에는 어울리지 않을 수도 있다.
SpringBoot 2 (Spring 5) 까지는 큰 문제가 없지만 SpringBoot 3 (Spring 6) 부터는 문제가 될 수 있습니다.
