인프런 워밍업 클럽2기 백엔드 - 발자국 1주차 (회고)

인프런 워밍업 클럽 2기 발자국 1주차1. 한 주를 돌아보며..인프런 워밍업 클럽, 읽기 좋은 코드를 작성하는 사고법 스터디도 벌써 한 주가 지났다.사실 시간에 비해 한 주 동안 공부해야 할 양이 많은 것은 아니었지만 이해하고 몸으로 체화하는 데 시간을 더 많이 쓴 것 같다.이번 주는 추상 / 논리,사고의 흐름 / 객체 지향 패러다임에 대해 공부했다. Section 1: 추상 (抽象)이번 주에 '추상'에 대해 배웠다. 추상과 구체의 개념, 적절한 이름 짓기의 중요성, 메서드 선언부의 의미, 추상화 레벨 맞추기, 그리고 매직 넘버와 매직 스트링의 사용에 대해 학습했다.추상화 레벨을 맞추는 게 생각보다 어려웠다. 너무 추상적이면 이해하기 어렵고, 너무 구체적이면 코드가 복잡해지는데, 이 balance를 맞추는 게 관건인 것 같다. 매직 넘버를 상수로 바꾸는 건 알고 있었지만, 이게 가독성과 유지보수성에 큰 영향을 미친다는 점을 새삼 깨달았다.Section 2: 논리, 사고의 흐름인지적 경제성, Early return, 사고의 depth 줄이기, 공백 라인과 부정어 사용, 해피 케이스와 예외 처리, 그리고 stream API와 Optional 사용에 대해 배웠다.Early return이 코드의 가독성을 크게 높인다는 점이 인상 깊었다. 지금까지 작성한 코드를 되돌아보니 불필요하게 복잡한 구조가 많았던 것 같다. 또한, 부정어 사용을 줄이는 것이 생각보다 어려웠는데, 이를 위해 메서드 추출 등의 방법을 사용할 수 있다는 점이 새로웠다.Section 3: 객체 지향 패러다임객체 간 협력과 책임, 관심사의 분리, getter/setter 사용 자제, 객체에 메시지 보내기, SOLID 원칙, 그리고 DI/IoC에 대해 학습했다.getter/setter를 무분별하게 사용하는 것이 객체 지향적이지 않다는 점을 배웠다. 객체에 메시지를 보내는 방식으로 코드를 작성하는 것이 더 객체 지향적이라는 점이 인상 깊었다. SOLID 원칙은 들어본 적은 있었지만, 실제로 적용하는 것은 쉽지 않을 것 같다. 특히 단일 책임 원칙(SRP)을 지키는 것이 가장 어려울 것 같다. 2. 미션이번 주에는 추상과 구체에 대해 생각해보고 생각나는 추상과 구체의 예시를 적어보는 미션이었다. (Day2)나는 러닝으로 추상과 구체를 나누어 보았다.러닝을 한다.- 오른발 뒤꿈치가 지면에 닿으며, 발바닥이 지면을 따라 앞으로 구르듯 펴진다.- 오른발이 지면을 밀어내는 동안, 왼발은 지면에서 떨어지면서 무릎이 구부러지고 몸 앞쪽으로 들어 올려진다.- 왼발이 앞으로 나아가는 동시에 오른팔이 앞으로 움직이고, 왼팔은 뒤로 젖혀진다.- 몸통이 약간 앞으로 기울어진 채 오른발을 축으로 전방으로 회전하듯 움직인다.- 왼발 뒤꿈치가 지면에 닿으면서 1-4번 과정이 반대 방향으로 반복된다.'러닝'이라는 추상적인 개념을 구체적인 동작으로 풀어 설명했다. 처음에는 '달린다'라고만 생각했는데, 실제로 각 동작을 하나하나 떠올려보니 생각보다 복잡한 과정이었다. 이런 식으로 추상적인 개념을 구체화하는 연습을 하면 코드 작성 시에도 도움이 될 것 같다. 또 다른 미션은 코드를 리팩토링하는 것과 SOLID 원칙을 정리하는 미션이었다. (Day4)https://www.inflearn.com/blogs/8385[미션 Day4] 코드 리팩토링주어진 validateOrder 메서드를 리팩토링했다. Early return 패턴을 적용하고, 반복되는 로직을 Order 클래스의 메서드로 추출했다. 또한 부정 조건문을 제거하여 가독성을 향상시켰다.이렇게 접근한 이유는 다음과 같다:Early return으로 코드의 depth를 줄여 가독성을 높였다.Order 클래스에 메서드를 추가하여 객체의 책임을 명확히 하고 캡슐화를 강화했다.부정 조건문을 제거하여 코드의 의도를 더 명확히 했다.리팩토링 과정에서 가장 어려웠던 점은 적절한 메서드명을 짓는 것이었다. hasNoItems(), isInvalidTotalPrice() 등의 이름을 고민하는 데 시간이 꽤 걸렸다. 하지만 이런 고민이 결국 코드의 가독성을 높인다는 것을 깨달았다. SOLID 원칙 정리SOLID 원칙을 정리하면서, 각 원칙이 왜 중요한지 깊이 생각해볼 수 있었다. 특히 DIP(의존성 역전 원칙)가 어떻게 코드의 유연성을 높이는지 이해하는데 시간이 좀 걸렸다. 실제 프로젝트에서 이 원칙들을 적용해보면 코드의 구조가 훨씬 개선될 것 같다는 생각이 들었다. 정리이번 미션을 통해 추상화의 개념을 실제로 적용해보고, 코드 리팩토링의 중요성을 체감할 수 있었다. SOLID 원칙을 정리하면서 객체 지향 설계의 핵심을 이해하게 되었다. 앞으로는 이런 원칙들을 항상 염두에 두고 코드를 작성해야겠다는 생각이 들었다. 다만, 이론적으로 아는 것과 실제로 적용하는 것은 큰 차이가 있을 것 같다. 앞으로 더 많은 연습이 필요할 것 같다.다음 주에는 이번 주 내용도 다시 복습하면서 강의 내용을 더 깔끔하게 정리해 봐야 겠다.

워밍업 클럽 2기(클린코드, 테스트코드) 과제 (Day 4)

Readable Code: 읽기 좋은 코드를 작성하는 사고법(링크)코드 리팩토링기존 코드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; }리팩토링 코드public boolean validateOrder(Order order) { if (order == null) { log.info("주문 정보가 없습니다."); return false; } if (order.hasNoItems()) { log.info("주문 항목이 없습니다."); return false; } if (order.isInvalidTotalPrice()) { log.info("올바르지 않은 총 가격입니다."); return false; } if (order.hasNoCustomerInfo()) { log.info("사용자 정보가 없습니다."); return false; } return true; }public class Order { private List items; private double totalPrice; private CustomrInfo customerInfo; public boolean hasNoItems() { return items == null || items.isEmpty(); } public boolean isInvalidTotalPrice() { return totalPrice SOLID 정리SOLIDSRPSingle Responsibility Principle (단일 책임 원칙)하나의 클래스는 단 한 가지의 변경 이유만을 가져야 한다.객체가 가진 공개 메서드, 필드, 상수 등은 해당 객체의 단일 책임에 의해서만 변경 되어야 함.관심사의 분리높은 응집도, 낮은 결합도OCPOpen-Closed Principle (개방-폐쇄 원칙)확장에는 열려 있고, 수정에는 닫혀 있어야 한다.기존 코드의 변경 없이, 시스템의 기능을 확장할 수 있어야 한다.추상화와 다형성을 활용해서 OCP를 지킬 수 있다.LSPLiskov Substitution Principle (리스코프 치환 원칙)상속 구조에서, 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 치환할 수 있어야 한다.자식 클래스는 부모 클래스의 책임을 준수하며, 부모 클래스의 행동을 변경하지 않아야 한다.LSP를 위반하면, 상속 클래스를 사용할 때 오동작, 예상 밖의 예외가 발생하거나, 이를 방지하기 위한 불필요한 타입 체크가 동반될 수 있다.ISPInterface Segregation Principle (인터페이스 분리 원칙)클라이언트는 자신이 사용하지 않는 인터페이스에 의존하면 안 된다.인터페이스를 잘게 쪼개야 함ISP를 위반하면, 불필요한 의존성으로 인해 결합도가 높아지고, 특정 기능의 변경이 여러 클래스에 영향을 미칠 수 있다.DIPDependency Inversion Principle (의존성 역전 원칙)상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안 된다. 둘 모두 추상화에 의존해야 한다.의존성의 순방향 : 고수준 모듈이 저수준 모듈을 참조하는 것 의존성의 역방향 : 고수준, 저수준 모듈이 모두 추상화에 의존하는 것저수준 모듈이 변경되어도, 고수준 모듈에는 영향이 가지 않는다.