[인프런 워밍업 클럽 3기 BE 클린코드 & 테스트] 1주차 발자국 제출

강의 수강학습 내용 요약섹션2. 추상변수 리네이밍메서드 레벨의 추상화추상화 레벨을 맞추기 위해 추가적 메서드 추상화 수행매직 넘버, 매직 스트링 제거섹션3. 논리, 사고의 흐름인지적 경제성 추구early return, 무분별한 else문 사용 자제중첩 분기문 및 반복문 depth 감소공백 라인 추가하여 가독성 향상부정연산자 제거사용자입력 예외 처리 수행섹션4. 객체 지향 패러다임동일 관심사 그룹화해 객체 생성객체 레벨 리팩토링 수행SOLID 원칙 적용하여 리팩토링 SOLID 원칙: 객체 지향 설계에서 코드의 유지보수성과 확장성을 높이기 위한 소프트웨어 개발 원칙단일 책임 원칙 (SRP): 클래스 레벨에서 많이 이야기하며, 하나의 클래스가 하나의 책임만 가져야 함.그 책임이 변경될 이유도 하나여야 함. 변경 이유가 곧 책임확장-폐쇄 원칙 (OCP): 확장에는 열려 있고, 수정에는 닫혀 있어야 함. 기존 코드 변경 없이 기능 확장이 가능해야 함. 추상화와 다형성을 활용해 지킬 수 있음리스코프 치환 원칙 (LSP): 부모 클래스와 자식 클래스가 있을 때, 부모가 있는 곳에 자식 클래스의 인스턴스로 대체해도 정상 동작하여야 함.자식 클래스는 부모 클래스의 역할을 완전히 대체할 수 있어야 함인터페이스 분리의 원칙 (ISP): 인터페이스는 기능 단위로 잘게 쪼개야 함.복잡한 인터페이스는 분리 필요의존성 역전의 원칙 (DIP): 고수준 모듈은 저수준 모듈(구체적 객체)에 의존하지 않음고수준 모듈과 저수준 모듈 모두 추상화에 의존해야 함.(저수준 모델이 바뀌어도 고수준 모델이 타격받지 않음)1주차 회고 회사를 다니면서 스터디를 하는 것이어서 긴장감을 가지고 임했는데, 그러길 잘한 것 같다. 우선 1주차는 무사히 마무리했다. 오티에서도 멘토님이 열심히 하셔야 한다는 뉘앙스로 말해주셨는데, 한 주에 강의를 수강하고 소화해낸다는 게 쉬운 일은 아닌 것 같다. 다행히 강의 시간이 긴 강의들도 귀에 쏙쏙 들어오는 내용들이라 강의를 이해하는 데 추가적으로 많은 시간이 소요되지는 않았다. 다만 여유 있게 따라간다는 느낌이 아니어서, 2주차에는 좀 더 시간 투자를 많이 해야 할 것 같다.차주 미션을 미리 봐 두었는데, 화요일까지는 수행을 해야 마감일인 수요일에 다시 볼 수 있을 것 같다. 앞으로 3주 더 힘내서 무사히 완주하고 싶다. 워밍업 클럽이 종료된 후 코드 보는 눈이 더 길러질 것 같아 기대된다. 미션 관련 회고배웠던 사항들을 하나씩 되뇌어보며 리팩토링을 수행하려고 노력했다. 커밋 메시지를 의식적으로 강의 요점을 담으려 하면서 작성했는데, 도움이 많이 되었다. 학습 내용 요약을 할 때에도 유용했다. 스터디 시작한 지 딱 일주일 지났지만, 이전보다는 보는 눈이 조금 길러진 게 느껴진다. 감으로만 알고 파악하던 것들에 대해 한 번씩 짚고 갈 수 있어서 좋았다.디스코드를 음성 채팅 혹은 강의 실시간 수강용으로만 써 보았고, 이런 식으로 봇 같은 기능을 활용한 것은 처음이라 첫 미션 제출 때까지는 조금 버벅거렸던 것 같다. 이건 차주부터는 괜찮을 것 같다.

[인프런 워밍업 클럽 3기 BE 클린코드 & 테스트] Day 4 미션 제출

리팩토링섹션3까지의 내용을 중심으로 리팩토링하였습니다. (처음에 섹션 4까지의 내용을 모두 적용하여 리팩토링 하는 것으로 파악하였는데, 아니어서 문구 수정하여 그대로 제출합니다. )public class OrderValidator { private static final String NO_ITEMS_ERROR = "주문 항목이 없습니다."; // 에러 메시지를 상수로 정의해 가독성 향상 private static final String INVALID_TOTAL_PRICE_ERROR = "올바르지 않은 총 가격입니다."; private static final String NO_CUSTOMER_INFO_ERROR = "사용자 정보가 없습니다."; public boolean validateOrder(Order order) { if (hasNoItems(order)) { log.info(NO_ITEMS_ERROR); return false; // early return 적용 } if (isTotalPriceInvalid(order)) { log.info(INVALID_TOTAL_PRICE_ERROR); return false; } if (hasNoCustomerInfo(order)) { log.info(NO_CUSTOMER_INFO_ERROR); return false; } return true; } private boolean hasNoItems(Order order) { // 한 메서드가 하나의 기능만 수행하도록 함(단일책임원칙) return order.getItems().isEmpty(); } private boolean isTotalPriceInvalid(Order order) { return order.getTotalPrice() SOLID 원칙을 자신의 언어로 정리하기SOLID 원칙: 객체 지향 설계에서 코드의 유지보수성과 확장성을 높이기 위한 소프트웨어 개발 원칙단일 책임 원칙 (SRP): 클래스 레벨에서 많이 이야기하며, 하나의 클래스가 하나의 책임만 가져야 함.그 책임이 변경될 이유도 하나여야 함. 변경 이유가 곧 책임확장-폐쇄 원칙 (OCP): 확장에는 열려 있고, 수정에는 닫혀 있어야 함.기존 코드 변경 없이 기능 확장이 가능해야 함. 추상화와 다형성을 활용해 지킬 수 있음리스코프 치환 원칙 (LSP): 부모 클래스와 자식 클래스가 있을 때, 부모가 있는 곳에 자식 클래스의 인스턴스로 대체해도 정상 동작하여야 함.자식 클래스는 부모 클래스의 역할을 완전히 대체할 수 있어야 함인터페이스 분리의 원칙 (ISP): 인터페이스는 기능 단위로 잘게 쪼개야 함.복잡한 인터페이스는 분리 필요의존성 역전의 원칙 (DIP): 고수준 모듈은 저수준 모듈(구체적 객체)에 의존하지 않음고수준 모듈과 저수준 모듈 모두 추상화에 의존해야 함.(저수준 모델이 바뀌어도 고수준 모델이 타격받지 않음)