: 매일 저녁, 하루를 마무리하며 작성 !
: ⭕ 지식 위주, 학습한 것을 노트 정리한다고 생각하고 작성하면서 머리 속 흩어져있는 지식들을 정리 !
class Solution {
public int[] solution(int[] arr) {
if(arr.length == 1){
int[] answer = {-1};
return answer;
}
int min = arr[0];
int[] answer = new int[arr.length -1];
for(int i=0; i<arr.length; i++){
min = Math.min(min,arr[i]);
}
int count = 0;
for(int i=0; i<arr.length; i++){
if(min == arr[i]){
continue;
}else{
answer[count++] = arr[i];
}
}
return answer;
}
}
RestAPI 를 잘 작성해주셨습니다.
request dto 객체에는 기본생성자가 존재해야 스프링에서 제대로 값을 매핑해 줄 수 있습니다. 아무 생성자가 없는 경우에 자동으로 기본 생성자가 생성되지만 명시적으로 어노테이션(lombok의 noargsconstructor)이나 기본생성자를 작성해주시는 것이 좋습니다.
엔티티와 dto 객체 사이에 변환을 잘 작성해주셨는데요. 엔티티 객체는 실제 DB와 연동되는 객체이기때문에 최소한의 로직만 작성해주시는 것이 좋을 것 같습니다. 따라서 dto를 entity 로 변환해주는 로직도 dto 쪽에 작성해주시는 것이 더 좋을 것 같습니다.
JdbcTemplate 을 이용해 DB처리를 잘 작성해주셨는데요. 컨트롤러에서 JdbcTemplate을 직접 사용하기보다는 별도 bean 클래스(service or repository) 를 생성하셔서 JdbcTemplate 를 관리하는 용도로 사용해주시면 가독성 관점이나 객체의 관심분리 측면에서도 더 좋은 코드가 될 것 같습니다.
과제 요구사항에 공통 조건을 보시면 일정 작성, 수정, 조회 시 반환 받는 정보에 비밀번호는 제외되도록 되어있습니다. 사소한 부분이지만 실제 현업에서는 이러한 부분들이 서비스에 큰 영향을 끼칠 수 있기 때문에 꼼꼼히 확인해보시면 좋을 것 같습니다.
API 설계에 따른 request, response 를 잘 구현하셨습니다. 다만, request의 경우에는 기능에 따라 사용되는 필드가 상이할 수 있으므로 기능에 따라 별도 request를 작성해주시는 것도 좋을 것 같습니다. (ex. ScheduleCreateRequestDto, ScheduleGetRequestDto 등)
조금 더 가독성 있는 코드를 원하신다면 if문은 짧게, 브레이스({})에 의한 depth는 깊어지지 않게 작성해주시는 것이 좋습니다.
ex.
Scheduler scheduler = findById(id);
if (scheduler == null) {
throw new IllegalArgumentException("선택한 일정은 존재하지 않습니다.");
}
// 비밀번호 확인
if (!scheduler.getPassword().equals(requestDto.getPassword())) {
throw new ResponseStatusException(HttpStatus.FORBIDDEN, "비밀번호가 올바르지 않습니다.");
}
// scheduler 삭제
String sql = "DELETE FROM scheduler WHERE id = ?";
jdbcTemplate.update(sql, id);
return id;