3주차 후기
문제 난이도
클래스를 쓰면서 만들려고 하니 갑자기 난이도가 확 상승한 느낌이었다.
좋았던 점
고민하기
클래스를 쓰다보니 구조에 대한 고민을 더 깊게 할 수 있었다.
이게 이 객체의 역할에 맞는가?를 고민하며 구조를 고민하고 파악해보는 시간을 가질 수 있었다.
테스트코드 작성에 익숙해짐
그래도 몇번 했다고 이젠 테스트코드를 먼저 작성해보는 것도 덜 어색하다. 특히 예외사항같은 경우엔 테스트코드를 먼저 작성해보면서 충분히 생각해볼 수 있어 빼먹지 않을 수 있었다. 또 예외처리 부분을 만들고 난 뒤에 바로 테스트를 돌려볼 수 있어서도 좋았다.
힘들었던 점
클래스가 어색한 나
클래스 사용이 어색해서 좀 진땀이 났다. 피드백보면 뼈 맞은 느낌이다.
아쉬웠던 점
input
입력받는걸 따로 분리를 못 해냈다. 그러다보니 자꾸 로직이 한눈에 안 보이게 된다. 다 제출하고 다른분들 코드를 보다가 방법을 알았다ㅠ promise를 쓰면 되는데..!!! 마지막 주차엔 반영해봐야겠다.
3주차 공통 피드백보며 반성하기
함수(메서드) 라인에 대한 기준 - 공백도 라인이다.
난 공백은 아니라고 생각해서 15줄 잘 맞췄다고 생각했는데 아니었다^^
발생할 수 있는 예외 상황에 대해 고민한다
비즈니스 로직과 UI 로직을 분리한다
비즈니스 로직과 UI 로직을 한 클래스가 담당하지 않도록 한다. 단일 책임의 원칙에도 위배된다.
이렇게까지 뼈를 맞을 수가 있을까..
객체의 상태 접근을 제한한다
필드는 private class 필드로 구현한다. 이거에 대한 생각을 하긴했는데 행동엔 옮기지 않았다..반성하자아
객체는 객체스럽게 사용한다
https://tecoble.techcourse.co.kr/post/2020-04-28-ask-instead-of-getter/
getter를 좀 썼는데..아예 안 쓰기엔 내겐 너무 어렵다ㅠㅠ
필드의 수를 줄이기 위해 노력한다
내 방법이 틀리지 않았지만 복잡하다고 생각했는데 내가 저 코드를 App 내부에 다 넣어서 복잡했던거였다ㅎ 역할을 묶을 수 있는 부분이었으니 다음엔 꼭 객체로 분리해내자.
성공하는 케이스 뿐만 아니라 예외에 대한 케이스도 테스트한다
이건 잘 한거 같다..!!!
테스트 코드도 코드다
테스트 코드도 코드이므로 리팩터링을 통해 개선해나가야 한다. 특히 반복적으로 하는 부분을 중복되지 않게 만들어야 한다. 예를 들어 단순히 파라미터의 값만 바뀌는 경우라면 아래와 같이 테스트할 수 있다.
테스트를 위한 코드는 구현 코드에서 분리되어야 한다
이것도 나한텐 해당사항이 아니라 다행이다.
단위 테스트하기 어려운 코드를 단위 테스트하기
https://tecoble.techcourse.co.kr/post/2020-05-07-appropriate_method_for_test_by_parameter/
테스트는 만들어도 만들어도 어려운거 같다..ㅠㅠ 아니 내 메소드들이 테스트하기 나쁜 메소드들인 것이겠지ㅎㅎ
자랑글
반성과 절망만 가득했지만 그래도 어떤 분이 내게 좋은 글을 주셔서 작은 위안이 되었다.
역시나 배울점이 많은 한 주였다. 이제 마지막 미션인데 마지막까지 잘해보자!!
