인프런 워밍업 클럽 스터디 3기 - 백엔드 클린 코드, 테스트 코드 2주차 발자국
학습 내용 정리
이번 주차에서는
코드 외적인 부분에서 추구할 수 있는 클린 코드 규칙
새로운 프로젝트에서 실습, 피드백
테스트 코드 작성 입문 이론
1. 코드 외적인 부분으로도 맥락이 형성 된다.
변수와 메서드를 어떻게 위치 시킬 것인가
고도화 될 수록 변수, 메서드가 많아질 수 있다.
이에 따라 필요한 변수 메서드를 찾는 비용이 점점 증가할 수 있다.
이 때 특정 규칙/맥락에 따라 잘 정리한다면 비용을 상당히 많이 감소 시킬 수 있겠다.
여러 사람이 같이 일할 때 특히 더 강력해지는 도구가 될 수 있다.
주석에 대한 것
주석의 필요성에 대해 모호하던 상황이었다.
정책 의사 결정의 세부 사항, 히스토리 같은 것들은 코드로 표현하기 어렵고, 따로 문서로 정리하게 될 것이라고 생각된다.
이 때 주석이 정말 강력한 도구가 될 수 있겠는 것을 알게 되었다. 문서를 따로 만들 필요 없이 단일화 할 수 있겠구나.
다만 이 때 주석을 사용하게 된다면 버전 이라는 새로운 맥락을 형성하므로, 코드와 주석을 같이 업데이트 시켜주는 것에 매우 신경 써야 한다.
2. 새로운 프로젝트에서 실습, 피드백
실습 진행 프로젝트 위치
https://github.com/aammddkkzxc/readable-code/tree/main/src/main/java/cleancode/studycafe/practice피드백 요청 사항
내용 요약
검증 메소드를 검증하고자 하는 해당 클래스 내부에 위치 시키자
생성자에서 의미 부여를 피하자
정적 팩토리 메서드의 강력한 점은 네이밍을 부여하여 역할을 명확히 할 수 있다는 것
따라서 의미가 부여되는 초기화 작업이 있다면, 생성자 보다는 정적 팩토리 메서드 내부에서 하는 것이 좋을 수 있다
정답을 찾아내려고 하지 말고 논리와 의도에 집중하자
코드에 대한 선택은 모든 맥락에 의해서 정해진다. 심지어 팀 내부 상황 같은 외부적 요인까지도 영향을 미친다
정답이 있다고 가정하고 접근하게 된다면, 각종 원칙이나 용어에 매몰될 위험이 있다. 언제까지나 원칙과 용어들은 더 나은 선택을 위한 도구일 뿐이라는 것을 잊지 말자.
명확한 의도를 가지고 구현/리팩토링 하되, 요구 사항이나 합의가 변하면 언제든 변경할 수 있는 자세를 지니자
클린 코드를 왜 추구하는가
팀의 생산성을 위해서. 주종 관계의 역전에 주의하자
느낀 점
저번 주에 배운 원칙들을 적용 시키는 것에 대해 어려울 것으로 예상했는데, 역시 쉽지 않았다.
보는 것 만으로는 한계가 있다는 것을 다시 한번 체감했다.
이번에 실제 연습을 해봄으로써 좀 더 성장할 수 있었다
최근 개발 공부를 하면서 침체기와 막막함을 느끼고 있었는데, "그래 나 이런 것 재밌어 했지"라고 리프래쉬 할 수 있었다.
3. 테스트 코드
테스트 코드/TDD의 중요성
이전엔 그냥 막연하게 확실히 하는 것이 좋으니까 중요하겠지라고 생각했었고, 크게 동기 부여가 되지 않았었다.
강의를 통해 배운 중요성
피드백이 빠르다
클라이언트 관점으로 개발하여 해피케이스에 매몰되는 것을 피할 수 있다.
모호한 기획이나 암묵적인 약속들을 찾아낼 수 있다
과감한 리팩토링이 가능해진다
테스트 하기 어려운 케이스란?
코드를 실행 할 때마다 바뀌는 부분을 함수 내부에 가지고 있으면서, 제어하기 힘든 경우
날짜/시간, 랜덤 값, 전역 변수/함수, 사용자 입력 등
함수 내부에 갖고 있지 않도록 분리한다. (매개변수로 받아오는 형태로 만들면 제어 가능)
어느 레이어 까지 분리 시킬 지 결정이 필요해진다
외부에 영향을 주는 경우
외부 세계라는 것 자체가 테스트 시 검증이 어렵다
표준 출력(로그), 메세지 발송, 데이터베이스 에 기록 등
코드외에 다른 테스트 도구 필요
DisplayName을 섬세하게, BDD스타일
단순 명사의 나열 x 행위부터 결과 까지
도메인 관점으로 상세하게 작성
메서드 자체의 관점 x
테스트 현상 중점 x
개발자가 아닌 사람이 봐도 이해할 수 있을 정도로
댓글을 작성해보세요.
