TIL - 프로젝트 예외처리, git show history

 

면접 준비를 하면서, 내가 쓰지 않은 코드도 같이 공부하고 있다. 

문득 의문이 들었다. 

 

왜 회원가입에서 중복에 대한 예외처리를 해주고 있는데, idCheck 라는 기능이 별도로 들어갈까? 

  //회원 가입
    public void registerUser(SignupRequestDto requestDto) throws Exception {
        String username = requestDto.getUsername();
        // 회원 ID 중복 확인
        Optional<User> found = userRepository.findByUsername(username);
        if (found.isPresent()) {
            throw new IllegalArgumentException("중복된 사용자 ID 가 존재합니다.");
        }
        String password = passwordEncoder.encode(requestDto.getPassword());
        String email = requestDto.getEmail();
        // 사용자 ROLE 확인
        UserRole role = UserRole.USER;
        if (requestDto.isAdmin()) {
            if (!requestDto.getAdminToken().equals(ADMIN_TOKEN)) {
                throw new IllegalArgumentException("관리자 암호가 틀려 등록이 불가능합니다.");
            }
            role = UserRole.ADMIN;
        }

        User user = new User(username, password, email, role);
        userRepository.save(user);

//        return user;

    }

 

수업에서 배운 것은 예외처리만 하지만, 예외 결과에 따라서 UI 가 바뀌지는 않는다.

사용자 중복 이름이 있는 경우 회원가입이 되지 않음. 하나만 구현하기 위함이다. 

반면, 우리 서비스에서 idCheck는 하나의 API다 (controller에서 /signup/idcheck의 url로 보낸다)

하지만 중복 체크는

(1) 회원가입 API -> exception 이 뜨면 (중복된 사용자가 있으면,) 가입이 되면 안됨. 

(2) 중복 체크 API 모두 이뤄져야 한다. 

-> true 든 false 든 결과를 전달할 뿐이다.  

public Boolean idCheck(idCheckDto idDto) {
    String username = idDto.getUsername();
    Optional<User> found = userRepository.findByUsername(username);
    Boolean response = found.isPresent();
    return response;
}

idCheck에서 true /false 값에 따라서 다른 text 를 입력해준다. 

idCheck는 idCheck만, 회원가입은 가입만. 

클래스가 제공하는 서비스는 하나의 책임 수행에 집중한다 (단일 책임 원칙)이다.   

 

    $.ajax({
        type: "POST",
        url: `${apiUrl}/signup/idcheck`,
        contentType: "application/json",
        data: JSON.stringify(info),
        success: function (response) {
            if (response == true) {
                alert("아이디 중복")
                $(".help-id").text("  이미 존재하는 아이디입니다.").removeClass("is-safe").addClass("is-danger")
                $("#loginusername").focus()
            } else {
                $(".help-id").text("  사용할 수 있는 아이디입니다.").removeClass("is-danger").addClass("is-success")
            }
        }
    });
}

프론트에서 클릭했을 때는, console 에서 에러메시지를 확인할 수 없지만 (중복 확인이 안되면 가입 요청을 보낼 수 없도록 프론트 로직을 짰기 때문이다. ) postman 에서 api 요청을 보내면, 에러 메시지가 콘솔에 뜬다. 

 

 

이번에는 추천하기 기능의 username 중복 부분을 보자. 

삼겹살로 postman 을 보내면 (이미있는데이터다) query did not return a unique result라는 에러가 뜬다. 

이는 음식을 저장한 후, foodRepo 에서 다시 찾아올 때, 기존 데이터가 있기 때문에 2개의 result가 조회되기 때문이다. 그래서 API 가 성공적으로 실행될 수 없다. 그렇기에 이렇게 에러처리를 해주는 것이 훨씬 에러를 디버깅하기에 쉽다. 

 

오늘은 인텔리제이 Git 의 Show History를 처음으로 써봤다.

설마 설마 했는데 이렇게 깔끔하다니.. 인텔리제이는 정말 천재인 것 같다..

인텔리제이는 어쩜 이름도 인텔리제이일까... 개발자들이 특정 기술의 팬이 되는게 아직은 남일처럼 멀어보였다. 그렇게 되고 싶지만, 난 일부의 기능을 소화하기도 바빠서 그 기술이 얼마나 대단하고 멋진지를 헤아릴 새가 없었다. 

그런데 인텔리제이의 UI는 정말 깔끔하고 핵심적인 것 딱 들어가있고. ㅜ.ㅜ.. 진짜 짱이다..당신.. 

 나는 단축키도 꼭 써야하는 것만 쓰고, 그리 요령은 없는 편이다. 

그런데 개발을 배우면서, 생산성을 생각하게 된다. 올해는 그런 노력을 해보고 싶다. 

계속 새로운 걸 접하고, 써보는 게 두렵기도 하다. 불편하기도 하고. 그럼에도 디버그를 하고, 하나라도 써서 RUN 을 할 때, COMFORT ZONE이 조금씩 넓어진다. 

 

Mypage의 N+1 문제를 살펴보면서, 떠난 팀원이 만든 파일이었기 때문에 그 히스토리를 살펴봐야 했다. 두개 비교하는 거라면 commit history를 볼 수 있었지만, 여러개를 비교하자니 막막했다.  

한달 전의 나라면, 대충 한달 전의 파일을 다운로드 받아서 비교해보았을 것이다. 이제 이 기능 덕분에 파일 별로 히스토리를 볼 수 있다. 너무너무 기쁘다.