1. 이번주 공통 피드백에서 인상 깊었던 것에 생각 붙이기
인상 깊었던 부분 위주로만 짧게 정리하고 내 생각()을 덧붙이겠다.
•
비즈니스 로직과 UI 로직 분리 (단일 책임 원칙)
◦
현재 객체의 상태를 보기 위한 로그 메시지 성격이 강하다면 toString() 사용
◦
View에서 사용할 데이터라면 getter 메서드 통해 데이터 전달
◦
나는 getter를 쓰기 싫어서 dto를 쓰고서 이를 outputFormatter에서 포맷팅 해줬었는데, toString(로그 메시지 성격 강할 시)을 쓰는 것도 방법이 될 수 있단걸 배웠다.
•
연관성 있는 상수는 static final 대신 enum 활용
◦
상수로 표현 가능한 것들에 대해 enum을 쓸지 상수를 쓸지 고민한적이 있었는데, LottoRule 같은 enum을 활용했음 좋았을 거 같다.
•
인스턴스 변수 수를 줄이기
◦
필드 수가 많은 건 그 인스턴스가 여러 책임을 떠맡은건 아닐지 의심해볼 만 하다 생각해왔다. 책임 관점에서 가 아닌 버그 발생 가능성, 객체 복잡도 측면에서 불필요한 필드를 없애 필드 수를 최소화하란 관점이 인상깊었다.
•
성공이랑 예외 둘다 테스트하기. 특히 경계값 부분
◦
테스트코드를 작성하면서부터 생성 테스트는 꼭 해야할까란 고민이 들었었는데 이 역시 쌓여서 단위 테스트의 일부로 동작할것이기에 성공 테스트로서 생성테스트도 해야 한다 판단했다.
•
테스트코드도 리팩터링 하기. 특히 중복 코드 제거
◦
테스트코드,, 무지성으로 짜다보면 중복 코드가 왕창 나오기 쉽다. 주의하자.
•
테스트를 위한 편의 메서드는 구현 코드에 구현하지 않기
◦
테스트를 위한 메서드를 stub 같은 형태로 테스트패키지쪽으로 빼는 것도 방법이 될 거 같고, functional interface로 만들어 람다식으로 활용해보는 것도 좋은 거 같다.
•
단위 테스트가 어려운 코드 리팩토링 → 테스트 하기 어려운 것을 클래스 내부가 아닌 외부로 분리
◦
테스트 하기 어려운 것과 쉬운 것의 관계를 그림처럼 표현해서 좋았다. 더 나아가, 테스트 하기 어려운 부분은 단위 테스트하지 않아도 된단 건 랜덤값은 테스트하지말라는 힌트도 된다 생각했다. 한 단계 윗 객체로 보낸다해도 여전히 그 윗 객체는 테스트가 어려울텐데, 이런 경우 인터페이스와 구현체를 활용하면 좋을 거 같다.
•
테스트 쉽게 구현하기 위해 가독성 이상의 일을 하는 private 함수를 테스트하고 싶다면 이는 객체 분리의 신호
◦
private 함수의 역할을 가독성 그 이상인지 이하인지 측면에서 바라보는 게 인상깊었다. 어쩌면 당연한 이야기인데 이는 테스트코드를 안짜고선 느끼기 힘들다. 테스트코드가 주는 이점이란 생각이 들었다.
2. 이번주 코수타를 보고 든 생각 정리하기
•
디자인 패턴에 대해
◦
2주차에 썼다가 뒤늦게 yagni 원칙에 위반한단 걸 알게 됐었다. 따라서 3주차엔 최대한 yagni 원칙을 위반하지 않게 생각하려 하다보니 자연스레 사용하지 않게 됐었다.
◦
코수타에서도 해당 과제에선 디자인 패턴에 대해 권장하지 않는단 걸 보고 잘 따라가고 있었구나 라고 생각했다.
•
mvc1과 mvc2
◦
mvc1을 1주차부터 써왔다.
◦
mvc 패턴을 썼을 때 다가온 장점은 controller가 모델과 뷰 사이에서 코드를 간결하게 정리해준 단 점이 컸다.
◦
그러다 지난 주차에 controller가 너무 비대해져 service 레이어가 추가된 mvc2를 적용해볼까 고민한 적이 있었다.
◦
하지만, 이는 도메인끼리 역할 분담이 제대로 되지 않아 발생한 일이었다 판단해 mvc2 도입은 적절치 않다 결정했다.
◦
이번 4주차에선 도메인끼리 적절히 메시지를 주고받게해 controller가 비대해지는 문제를 해결해보겠다.
Today in 프리코스
TIL 작성하기
몰입
코수타 듣고 느낀 점 적기
공통 피드백 보고 느낀 점 적기
Search