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

강의 수강강의 요약추상과 구체에 대한 개념을 학습하고 내가 작성한 코드를 다른 사람들이 봤을 때 읽히기 쉽도록, 즉 가독성이 좋게 하기 위한 방법들에 대해 학습했다.코드를 읽는 과정에서 사고의 depth를 줄이기 위한 추상화 레벨 고려, 부정어구 사용, 변수명 고려 등을 학습하였다. 코드의 설계가 잘 되어있지 않으면 후에 코드가 더 무거워지고 복잡해지면 기능의 추가, 삭제 및 변경 시 수많은 문제에 시달리게 될 것이다. 따라서 SOLID 라는 객체지향 5원칙을 준수하며 코드를 설계하면 이러한 문제를 줄일 수 있게되고 이 SOLID에 대해 학습하고 코드의 전반적인 리팩토링 과정을 학습했다. 일주일 회고아쉬웠던 점과 추후 목표섹션 1~3까지의 내용은 지금까지 코드를 작성한 나에게 있어서도 변수명에 대한 고민부터 시작해 사고의 depth를 줄이기 위한 고민, 추상화를 위한 고민 등 지금까지 작성했던 코드를 보며 어떤식으로 리팩토링을 시킬지 감이 잡혔지만 SOLID를 시작으로 Value Object, 일급 컬렉션 등 익숙하지 않은 내용으로 그저 강사님의 코드를 따라치기만 하며 나의 코드에서 해당 개념을 어떻게 적용시킬지 감이 잡히지 않는 모습을 보며 추가적인 공부와 경험이 필요하겠다는 생각이 들었습니다. 미션[Day2] 추상과 구체 구체로부터 정보를 덜어내고 가장 중요한 정보는 남기는 추상화 과정을 통해 추상을 하게 된다.추상과 구체를 보여주기 위한 예시로 방 청소를 하는 행위를 추상으로 두고 해당 추상을 구체화 시켜봤다.바닥에 놓여진 물건들을 치운다.빗자루를 들고와 바닥을 쓴다.물티슈를 가져와 바닥을 닦는다.방 청소를 하는 과정에서 내가 무엇을 가지고 어떠한 청소를 했는지, 자세한 내용은 모두 덜어내고 가장 중요한 정보인 내가 방 청소를 했다. 라는 내용만 보여주면 되므로 추상을 방 청소를 한다 로 설정했다. [Day4] 읽기 좋은 코드로 리팩토링 및 SOLID코드 리팩토링public boolean validateOrder(Order order) { if (order.getItems().size() == 0) { log.info("주문 항목이 없습니다."); return false; } else { if (order.getTotalPrice() > 0) { if (!order.hasCustomerInfo()) { log.info("사용자 정보가 없습니다."); return false; } else { return true; } } else if (!(order.getTotalPrice() > 0)) { log.info("올바르지 않은 총 가격입니다."); return false; } } return true; }사용자가 생성한 주문이 유효한지를 검증하는 메서드로 강의에서 배운 내용을 활용해 가독성을 높이는 작업을 했다.먼저, 검증 메서드를 실행시키기 위해 주문하는 사람, 물건, 주문 객체를 모두 생성해줬다. 새로운 주문에 대한 검증과정은 주문시 생성된 Order 객체 자신이 가장 잘 알 것이라고 판단해 validateOrder() 메서드를 Order 클래스 내에 넣어줬다.public class Order { private static final Logger log = Logger.getGlobal(); private final Customer customer; private final List orderItems; public Order(Customer customer, List orderItems) { this.customer = customer; this.orderItems = orderItems; } public boolean validateOrder() { // 1번 및 2번 if (orderItems.isEmpty()) { log.info("주문 항목이 없습니다"); return false; } // 3번 if (isNotAvailablePrice()) { log.info("올바르지 않은 총 가격입니다"); return false; } // 4번 if (hasNotCustomerInfo()) { log.info("사용자 정보가 없습니다"); return false; } return true; } private boolean isNotAvailablePrice() { return getTotalPrice() 기존의 코드에서 가독성을 높이기 위해사고의 depth를 줄이기 위한 중첩 분기문 분리 및 공백 라인 추가메서드명을 보고 무엇을 의미하는 메서드인지 이해하기 쉽도록 메서드명 변경두 번 이상의 사고를 줄이기 위한 부정어 제거의 고려사항을 두고 코드를 리팩토링 해주고 비교했을 때 확실히 기존의 코드보다 리팩토링 과정을 거친 코드를 읽을 때 머리가 편하다는 느낌을 받았다. SOLID소프트웨어 개발에서 좋은 설계를 만들기 위한 5가지 기본 원칙으로 나만의 언어로 바꿔 설명하기 위해 레스토랑에서 음식을 준비하고 서빙하는 과정으로 SOLID 원칙을 설명했다.SRP, 단일 책임 원칙레스토랑에서 주방장이 요리만 하고, 서빙 직원이 손님에게 음식을 가져다 주는 것과 같다. 주방장이 요리도 하고 서빙도 하면 효율이 떨어지게된다. 따라서 주방장은 요리만, 서빙 직원은 서빙만 하게 하면 각자 맡은 일에 집중할 수 있다. OCP, 개방-폐쇄 원칙레스토랑에서 새로운 메뉴가 생겼을 때, 기존의 주방 시스템을 바꾸지 않고 메뉴판에만 새로운 메뉴를 추가하는 것처럼 주방 시스템이 잘 되어 있다면 추가된 메뉴도 쉽게 조리할 수 있다.LSP, 리스코프 치환 원칙레스토랑에서 일하는 직원들이 모두 손님에게 서비스를 제공해야 한다. 서빙 직원이나 매니저, 혹은 주방 보조 등 누구든지 필요할 때 손님을 도울 수 있어야 한다(계산, 주문 등등). 즉, 어떤 역할이든 기본적으로 손님을 응대하는 일은 모두 잘할 수 있어야 한다.ISP, 인터페이스 분리 원칙주방장은 요리하는 방법만 알면 되고, 서빙 직원은 손님에게 음식을 가져다주는 방법만 알면 된다. 주방장이 서빙 절차를 알 필요는 없고, 서빙 직원이 요리하는 방법을 알 필요도 없다. 각자 필요한 일만 집중해서 하면 된다.DIP, 의존성 역전 원칙레스토랑에서 주방장이 어떤 요리 도구 (가스레인지, 조리 도구)를 사용하든 상관없이, 요리만 잘 하면 상관이없다. 즉, 주방장(고수준 모듈)은 구체적인 도구(저수준 모듈)에 의존하지 않고 요리 도구라는 추상적인 개념에 의존하는 것이다. 그래야 나중에 도구가 바뀌어도 주방장은 문제없이 요리할 수 있다.