인프런 워밍업 클럽 스터디 3기 - 백엔드 클린 코드, 테스트 코드 2주차 발자국

섹션 6 코드 다듬기해당 섹션에서 가장 와닿았고, 머리가 아팠던 것은 "과연 좋은 주석이란 무엇일까?" 에 대한 것이었다.결론적으로, 좋은 주석은 코드에 비즈니스 요구 사항과 의도를 모두 잘 녹여냈다는 가정 하에 더 전달해야만 하는 정보가 남았을 때 남기는 것이다! 섹션 7 리팩토링 미션이제까지의 학습을 바탕으로, 리팩토링 진행https://github.com/Chaeruin/readable-code/pull/1단계적으로, 공통적인 것부터 추상화 및 리팩토링을 진행하였다.io 패키지 인터페이스 추상화model 일급컬렉션 분리Machine 기능 추상화버그 수정!이후 중간 점검 세션을 통해 다른 분들 코드와 비교하고, 말씀해주신대로 다음날 리팩토링 + 강의 수강을 통해 간과하고 있었던 Provider의 개념, 리팩토링을 놓친 부분 (FileHandler 등...), VO에 대한 부족한 이해가 있음을 알고 이에 대해 더 학습하는 시간이 필요할 것 같다는 생각... 더 미루지 말고 다음 주에는 꼭 !! 해보아야겠다. 참조 강의 :: https://www.inflearn.com/course/readable-code-%EC%9D%BD%EA%B8%B0%EC%A2%8B%EC%9D%80%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%EC%82%AC%EA%B3%A0%EB%B2%95섹션 2 테스트는 왜 필요할까?테스트의 중요성 -> 테스트 코드의 부재는 결국 유지보수의 어려움을 낳는다테스트 코드는 빠른 피드백과 코드의 자동화, 이는 곧 전체 프로젝트의 높은 안정성을 낳는다 섹션 3 단위테스트단위 테스트란? 작은 단위(클래스나 메소드와 같은-)의 코드를 독립적으로 검증하는 테스트이다.JUnit5/AssertJ를 기반으로 해피 케이스 / 예외 케이스 / 경계값 모두 테스트 해야함 섹션 4 TDDTDD는 왜 하는걸까? 처음엔 시간이 오래 걸리는 것처럼 보이지만, 디버깅 시간 단축, 빠른 문제 식별, 리팩토링 안정성 보장 덕분에 장기적으로 개발 속도가 빨라진다고,Flow (3단계 순환)Red : 빨간 불을 보는 테스트를 먼저 작성 (내부 메서드 구현X 혹은 더미값)Green : 단순하고 빠르게 테스트를 통과할 수 있는 로직 구현 Refactor : 해당 Green을 기준으로 같은 값을 낼 수 있는 로직으로 리팩토링장점복잡도가 낮고, 테스트 가능한 코드를 구현할 수 있게 한다.쉽게 발견하기 어려운 엣지 케이스를 놓치지 않게 해준다.과감한 리팩토링이 가능해진다. 섹션 5 테스트는 [ ] 다.JUnit5부터 @Display 를 통해 명사의 나열보다 문장으로테스트 행위에 대한 결과까지 기술도메인 용어를 사용하여 한층 추상화된 내용을 담아테스트의 현상을 중점으로 기술하지 말 것 BDD 시나리오 기반 테스트 케이스에 집중한 테스트Given // When // Then참조 강의 :: https://www.inflearn.com/course/practical-testing-%EC%8B%A4%EC%9A%A9%EC%A0%81%EC%9D%B8-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B0%80%EC%9D%B4%EB%93%9C

인프런 워밍업 클럽 스터디 3기 - 백엔드 클린 코드, 테스트 코드 1주차 발자국

섹션2. 추상추상화에 대해 깊게 생각해보거나 코드의 추상화, 구체화에 대해 예시를 들어보며 깊이 있게 생각해본 경험이 부족하다는 생각이 들었다. 이번 강의를 수강하고 실습을 진행하며 추상화란 구체화된 정보에서 정보를 덜어내는 일련의 과정임을 알게 되었다.이 과정에서 코드를 단순화하여 유지보수를 쉽게 하고, 팀원간의 협업 수준을 높일 수 있음을 알고 실제 프로젝트에서의 중요성을 크게 느꼈다.섹션3. 논리, 사고의 흐름Early Return 을 통해 메소드, 사고의 depth를 줄이고 이를 통해 코드의 흐름을 명료하게 하는 과정을 추상화 과정과 더불어 주로 어떠한 방식으로 진행해야 하는지 강의와 실습을 통해 알아가는 시간을 가졌다.섹션4. 객체 지향 패러다임추상화, 코드 흐름을 명료하게 하는 과정에서 SOLID 원칙을 활용하여 코드를 설계해야 한다.SOLID 원칙SRP(단일 책임 원칙): 클래스가 하나의 명확한 책임만 가지도록 설계OCP(개방-폐쇄 원칙): 기존 코드를 수정하지 않고 확장할 수 있도록 설계LSP(리스코프 치환 원칙): 자식 클래스가 부모 클래스를 대체해도 프로그램이 정상 작동하도록 설계ISP(인터페이스 분리 원칙): 사용하지 않는 메서드를 구현하도록 강요받지 않도록 인터페이스를 작게 분리DIP(의존성 역전 원칙): 고수준 모듈과 저수준 모듈 모두 추상화된 인터페이스에 의존하여 유연성을 높이기회고전반적으로 코드를 추상화 하는 것이 정확하게 무엇인지, 추상화는 어떤 기준을 가지고 어떻게 진행해야 하는지에 대해 명확한 판단 기준이 없던 상태에서 강의를 듣고 실습을 진행하다 보니 내면 한 켠에 무의식적으로 추상화 레벨에 대한 기준이 생긴 것 같다. 이 기준을 말로 설명하기 까지는 더 많은 시간이 걸리겠지만, 더 많은 학습을 통해 한 걸음 나아가고자 한다.