인프런 워밍업클럽 4기 BE - 1주차 발자국

✍️ 1주차를 마무리 하면서!클린코드에 깊이 접근해볼 수 있었다.그동안 클린코드에 대한 열망이 있어서 책을 읽고 개선해보려고도 노력했지만 쉽지 않아 강의를 신청했고, 이번 워밍업 클럽도 신청했다! 강의를 수강하면서 코드에서 클린코드 하나에만 집중하다보니 직접적으로 어떤 식으로 수정해야하는지 깨달을 수 있었다. 그동안의 아쉬운 부분이 클린코드를 공부해도 실제 내 코드에 적용하기는 어렵다는 점이었는데, 매번 과제를 하면서 직접 고치게 되고 클린코드에 대해 생각하는 연습을 반복해서 실제 내 것에도 점점 적용될 수 있었다.그렇지만 쉽지 않았다..!시간을 충분하게 내어, 강의를 듣고 과제를 하는게 마냥 수월하진 않았다. 강의를 듣는게 얼핏보면 하루 3시간 정도는 쉽다고 생각할 수도 있다. 하지만 그냥 수강해서 흘려보내는 게 아니라, 계속 생각하는 연습을 하고 강의를 듣고 또 적용을 해보는 과정까지 다 합하면 하루에 클린코드에만 쓰는 시간이 꽤 많아졌다. 사실 처음 하루이틀은 이게 맞나 싶기도 했는데, 확실히 코드를 보며 생각하는게 조금씩 달라져서 앞으로도 더 잘해봐야겠다는 생각이 든다!앞으로 남은 주차동안 더 열심히 해봐야겠다! 첫 주차라서 미션도, 발자국도 조금씩 아쉬움이 남는 것 같다. 더더욱 열심히 하고 연습끝에 내 코드에 반영시키고 생각하는 연습을 더 많이 해야겠다!

인프런 워밍업클럽 4기 BE- 클린코드&테스트 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; } import java.util.List; import org.slf4j.Logger; import org.slf4j.LoggerFactory; record Item(int price) {} record Customer(String name) {} class Order { private final List items; private final Customer customer; Order(List items, Customer customer) { this.items = items; this.customer = customer; } void validate() { if (items.isEmpty()) throw ex("주문 항목이 없습니다."); if (totalPrice() 부정 연산자 제거 Early Return (예외를 던져 첫 실패시 즉시 반환함) 불필요한 클래스 제거 (OrderItems, ValidationResult 없애기) 레코드 사용 (Item, Customer를 Record로 사용해, 불변 데이터 정의를 간결화 함) SOLID 원칙단일 책임 원칙 (Single Responsibility Principle, SRP)책임이 명확히 분리된 코드는 읽기 쉽고, 유지보수와 테스트가 쉬워진다.여러 기능이 한 클래스에 섞이면 변경이 자주 발생하고, 코드의 복잡도가 증가한다. 개방-폐쇄 원칙 (Open/Closed Principle, OCP)인터페이스나 추상 클래스를 활용해 유연하게 설계하면, 변화에 강한 구조를 만들 수 있다.새로운 기능 추가 시 기존 코드를 수정하지 않고, 확장만으로 요구사항을 반영할 수 있어야 한다. 리스코프 치환 원칙 (Liskov Substitution Principle, LSP)상속 구조에서 자식 클래스가 부모 클래스의 규약을 깨지 않도록 설계해야 한다. 인터페이스 분리 원칙 (Interface Segregation Principle, ISP)하나의 큰 인터페이스보다는 여러 개의 구체적인 인터페이스로 분리하는 것이 좋다.불필요한 의존성을 줄이고, 각 구현체가 꼭 필요한 기능만 구현하도록 유도할 수 있다.의존 역전 원칙 (Dependency Inversion Principle, DIP)구체적인 구현이 아니라, 인터페이스나 추상 클래스에 의존하도록 설계한다.코드의 결합도가 낮아지고, 테스트와 확장이 쉬워진다.

인프런 워밍업 클럽 4기 BE- 클린코드&테스트 DAY2 과제 (일상에서의 추상과 구체)

추상 → 구체[걷는다.]- 오른쪽 다리와 왼쪽 다리를 교차하며 땅을 딛는다.- 오른쪽 다리가 땅에 닿는다면, 왼 쪽 다리는 한 발자국 앞으로 나아가고, 왼 쪽 다리가 땅에 닿는다면 오른 쪽 다리가 한 발자국 앞으로 나아간다.- 오른쪽 다리와 왼쪽 다리의 교차를 빠르게 수행한다. 구체 → 추상- 오른쪽 손과 왼쪽 손을 서로 15cm 정도의 간격을 둔 채, 가슴 앞에 가져다 둔다.- 두 손을 빠르고 힘있게 마주친다.- 이때 두 손이 마주치는 힘에 의해 해당 공간 안에서 공기가 진동한다.- 공기를 통해 전달된 진동은 고막, 달팽이 관을 거쳐 청각세포, 청신경을 통해 뇌로 전달된다.- 뇌로 전달된 청신경을 통해, 청각 피질에서 ‘박수 소리’로 해석된다.[박수를 치고, 그 소리가 박수임을 인지하기]