[우테코] 체스 미션 3, 4단계 회고: 예외 처리는 조심스럽게, 테스트 코드의 맹점, 리팩터링할 때는 기존 코드를 그대로 두면서...

 

이번 리뷰어였던 디디는 예외 메세지에 대한 피드백을 몇 개 달아주었다. 달아주면서도 예외 처리에 대한 부분은 아직 감이 잘 오지 않을 것이라고 말해주긴 했지만 이번에 알게된 몇 가지를 정리해 보았다. 

 

 

💋 예외 처리는 조심스럽게...

 

내가 받은 리뷰이다. 

RuntimeException 전체를 한번에 잡아서 message를 출력해주는건 어플리케이션의 취약점을 노출할 수 있는 포인트가 될 수 있어요. 예를들면 SQL 관련된 Exception의 메세지를 그대로 view에 보여줘서 사용자가 데이터베이스의 constraint 예외 메세지를 받을수도 있거든요. catch문을 좀 더 세분화 해서 잡아서 원하는 동작을 하도록 하는것도 일종의 방법일 수 있습니다. 혹은 예외메세지를 view로 보여주지 않고 공통된 메세지가 내려가도록 정의해주는 방법도 있습니다.

 

기억해야 할 것은 두 가지이다.

1. 예외 메세지에는 사용자에게 보여서는 안될 메세지가 존재할 수 있다는 것을 염두해 두어야 한다.

2. catch문을 활용해서 예외 메세지를 좀 더 세분화해서 처리하자!

 

 

이번 미션에서 IAE, ISE에 대해서는 예외 메세지를 그대로 보내고, 이외의 메세지에 대해서는 예기치 못한 상황이 대다수이니, 공통 메세지를 내려보내도록 수정했다.

 

private void play() {
    try {
        // ...
    } catch (IllegalArgumentException | IllegalStateException exception) {
        OutputView.printExceptionMessage(exception.getMessage());
    } catch (Exception exception) {
        OutputView.printExceptionMessage("예기치 못한 예외가 발생했습니다.");
    }
}

 

 

 

💋 테스트 코드의 맹점은 완벽하지 않는 테스트가 신뢰될 때

 

체스 룰 중 점수 계산에 대한 룰이 있다. 

pawn의 기본 점수는 1점이다. 하지만 같은 세로줄에 같은 색의 폰이 있는 경우 1점이 아닌 0.5점을 준다.

세로줄에 같은 색의 폰이 있는지 확인해야 하는데, 이에 대한 테스트 케이스를 잘 작성했다고 생각했다. 우연히 Color를 확인하지 않아도 통과하는 테스트 케이스였던 것이다...ㅠㅠ

 

 

TDD가 조금 손에 익으니, 좀 생각 없이 프로덕션 코드를 작성하게 되어서 한 두 번 정도 이렇게 빈 케이스들을 리뷰어가 찾아줬었다. 테스트 케이스에 대한 설계에 좀 더 신경써야 할 것 같다. 

 

 

 

 

💋 에러 로그와 커스텀 예외

 

예상치 못한 예외는 에러 로그를 찍고, 공통 메세지를 담은 커스텀 예외를 던지는 것이 좋다고 한다!

 

 

 

 

💋 리팩터링은 기존 코드를 그대로 두면서 하는 것이 좋다

선택 구현사항을 구현하면서, gameId를 더하게 되니 하나의 DAO에 두 가지 테이블에 대한 SQL 쿼리문이 섞여 있었다. 이 두 가지를 ChessPieceDao와 ChessStatusDao로 분리하고 싶었다.

 

분리하기 위해서 IDE의 기능들을 사용해서 거침없이 코드를 변경하던 중에 빨간불이 예상치 못한 곳에서 뜨기 시작했고, 이제는 어떤 것이 원인인지도 파악하기 어려울 정도로 힘들어졌다. 머리가 아파서 더이상 하기 어렵고 너무 힘들어졌다. 그래서 허브를 찾아갔다. 허브는 굉장히 리팩터링과 디버깅을 깔끔하게 해서, 꽤 많이 배웠다. 앞으로는 나도 막 지우지 말고 더 차분하게 해서, 빨간불 안뜨면서 원하는 방향으로 리팩토링 해야겠다. 헤헤