10주차
5/25 15시 20분 ~ 16시 20분 진행
면담 주제
코드리뷰 하면서 느낀점
활동 내용
1. javassist.NotFoundException? 체크드 익셥션
- > try-catch가 강제됨 좋지않아.. 잘알아보고 써라...
2. Optional 안티 패턴..
Optional<User> userById = userRepository.findById(userDto.getId());
if (userById.isEmpty()) {
Optional에서 지원하는 것을 써라
3. 래퍼 클래스와 프리미티브 타입 -> 엔티티 필드로 어떤 것을 사용할 것인가?
접니다... 래퍼타입-> 객체 리스트에 넣을수있음, null이 가능한가
프리미티브타입을써야할때 => 박싱과 언박싱, 프리미티브타입을 파라미터로 받을때는 사용적절
4. @GeneratedValue(strategy = GenerationType.AUTO) ?
연결된 DB의 방언을 따름
직접지정해서 쓰는이유 - DB가 변경시 수정해야되는 부분이 많음
5. JSON Body를 테스트 할때?
요청할때도 DTO를 만들어서 JSON으로 바꿔서 보내고 , JSON받은걸 DTO으로 바꾸고 DTO를 검증하는걸 추천함(?)
6. @RestControllerAdvice의 사용
예외 핸들링
runtimeexception을 던집니다
-> controller까지 내려온 예외를 @RestControllerAdvice로 해결
특정 인프라에 있는 예외면 추상화해서 던질 필요가있음본인의 기준이 있어야 됨(왜 이렇게 했니)
7. 소프트 딜리트에 대한 적용
@Entity
@Table(name = "post")
@Where(clause = "is_deleted = false")
@SQLDelete(sql = "UPDATE post SET is_deleted = true WHERE id = ?")무송님한테 배워라
8. @Transactional 의 readOnly 설정
flush를 안함, 수정하면 예외가 발생할텐데쓰기가 필요한지 아닌지를 생각해서
9. @Repository가 해주는 역할
DB에서 나오는 예외를 추상화된 예외를 바꿔줌
그리고 Component를 상속해서 빈으로 등록해줌
10. 실패좀 테스트하자..
특정기능이 실패하는 시나리오도 테스트 '해 줘'
11. JSR-303, 380 스펙에 따른 유효성 검사
Bean Validation 이라는 자바 스펙
DTO유효성은 303으로 유효성검사를 간결하고 깔끔하게 가능
12. ApiResponse 이거 뭐임..?
가지는 문제점, HTTP Status코드를 가지고있음
응답바디에 왜 가지고 있는가질문
- 세션을 왜 실무에서 사용하지않을까요? (특정 클라이언트와 특정 서버의 상태를 가져야되기 때문에) =>토큰사용JWT 토큰자체로 인증이 가능함(어느서버로 가든 인증이 가능)
단점은 강제로 로그아웃이 안됨(만료 시간까지 기다려야됨)
다른 토큰도 많아영
에프님의 한마디
- 개발은 소신 있게 해라
- 시큐리티 너무 어려우면 다른 것부터 공부하자. 나중에 자연스레 알게됨
11주차
6/2 13시 00분 ~ 14시 20분 진행
면담 주제
학습 내용 파악, 팀 질의응답 진행
활동 내용
- 협업 관련 학습중 → 협업을 어떻게 해야하는가..
- 지금부터 어디든 지원해보라고함.
- 개인 프로젝트를 최대한 많이 해보자. → 혼자 개발할 수 있는 사람이 같이도 개발할 수 있다.
- 멘토의 회사 이야기..
12주차
6/9 17시 ~ 18시 10분 진행
면담 주제
학습 내용 파악, 팀 질의응답 진행
활동 내용
1. 스토리 포인트 산정 (송)
업무를 처리하는데 걸리는 시간 = 실질적으로 생각해서 배정2. 플래닝 과정에 개발에 무관한 사람도 참여하는가?(송)
팀이 어떻게 일하는가에 따라 달라짐
이해 관계자들과 밀접한 관계가 있다면 참여하는게 좋음
현실적으로는 큰 규모는 필요, 작은 규모는 필요없음3.shorturl에서 왜 id를 base62로 인코딩하는 값을 사용하는가?(송)base58를 주로 사용함 => 사람들이 보통 직접 친다고 생각해 비슷하게 생긴거 빼기f - 똑같은 서비스를 먼저 사용해보고 어떻게 만들어주는가를 보고 귀납적으로 추론을 해라(왜 이렇게 만들어질까)4.team user에서 여러명의 user를 team에 넣을 때
민감한 정보 제외한 id값만 넣어서 만든다. 이게 맞나?(형)
예) 배달에서 여러가지 음식을 시킨 리뷰f - 처리 방법은 일단 맞음. 그렇게 하셔도 무관할것같다
도메인에서 사용되는 user에서 필드로 비밀번호를 딱히 가지고 있지 않을것 같다.5. (정리못해서 멘붕) (형)
f - 스토어를 가져옵시다. 쿼리 한두번은 성능적으로 괜찮다.6. 간단한 일을 수행하는 녀석들은 모아놓는 패키지 명은 무엇으로 해야 될까요? (송)
f -
특정 코드를 검색하면 그 코드가 들어있는 레포를 찾을 수 있음
다른사람들이 어떻게 네이밍을 만드는지 확인할 수 있음(본인 논리 있거나 소신있게)7. 보통 엔티티를 담는 패키지를 모델이라고 하는 사람도 있고
도메인이라고 하는사람도 있고 맞는 표현일까(송)f - 어떤 아키텍쳐를 따라 가고 있는지를 보고 판단해라
모델 - MVC
도메인 - DDD
dto 와 entity를 굳이 따로 나눌 필요는 없고 거대해지면 나눠도 됨8. 객체 참조가 꼭 필요한가?(완)
f - 꼭 필요하진 않다.경계 밖의 객체는 ID를 이용해 접근한다.
객체참조는 객체지향을 설명하는데 많이 사용된다. 간단하고 객체지향을 잘 나타낼 수 있기 때문이다.
현업으로 가면 객체참조는 최대한 자제하고 객체를 어떻게 분리하고 합치는지가 중요하다.
개념과 현업의 괴리가 있다.