[인프런 워밍업 클럽 4기] BE 스터디 1주차 발자국

1주차 회고 - "좋은 코드는 결국, 좋은 이름에서 시작된다" 이번 주는 단순히 코드를 '돌아가게' 만드는 것이 아니라, '읽기 좋게', '유지보수하기 쉽게' 만드는 것의 중요성을 깊이 느낀 한 주였다. 특히 추상화, 이름 짓기, 그리고 SOLID 원칙이 실제 코드에서 어떤 식으로 녹아들어야 하는지를 고민하게 되었다. [추상에 대한 이해] 처음에는 "추상화가 중요하다"는 말이 와닿지 않았다.하지만 '어떻게 할지는 숨기고, 무엇을 할지는 보여주는' 추상의 개념을 코드에 직접 녹여보며, 추상화는 단순히 기능을 감추는 것이 아니라 의도를 명확히 전달하는 수단임을 체감했다.특히 메서드 하나, 이름 하나에도 설계자의 의도가 담긴다는 사실을 배우며, 추상은 곧 설계의 시작이라는 생각이 들었다. [코드 리팩토링을 통해 느낀 점] 이번 리팩토링에서는 validateOrder() 메서드의 복잡한 조건문을 단순화하고, 로직을 Order 객체 내부로 옮기는 방식으로 개선하였다.그 결과 코드가 훨씬 더 읽기 쉽고, 흐름이 명확해졌다.특히 isEmpty(), hasValidTotalPrice(), hasCustomerInfo()와 같은 메서드 이름만으로도 조건의 의미를 직관적으로 파악할 수 있어 가독성이 향상되었다.또한 early return을 통해 불필요한 중첩을 제거하면서, 핵심 로직이 눈에 잘 띄도록 구성할 수 있었다.그동안은 기능 구현에 집중하느라 네이밍이나 코드 구조에는 크게 신경 쓰지 않았는데, 이번 작업을 통해 ‘좋은 코드’란 읽는 사람이 쉽게 이해할 수 있는 코드라는 것을 실감하게 되었다.무엇보다 리팩토링을 하면서 ‘추상화는 구체에 기반해야 한다’는 원칙을 체감할 수 있었고, 실제로 메서드 하나하나가 그 역할을 명확히 하도록 만드는 것이 클린 코드의 핵심이라고 느꼈다.앞으로도 이름짓기와 추상화에 더 신경 쓰며, 읽기 쉬운 코드를 작성하는 연습을 계속해 나가려고 한다. [객체지향] 이번 주 학습을 통해 객체 지향 패러다임을 추상의 관점에서 바라보는 시야를 넓힐 수 있었다.단순히 "클래스를 나누고 메서드를 분리한다"는 수준이 아니라, 도메인을 추상화하고 각 객체에 책임과 역할을 분명히 부여하는 것이 진정한 객체 지향 설계라는 점을 체감했다.특히 상속보다는 조합을 우선하라는 원칙이 인상 깊었다. 상속은 부모-자식 간의 결합도를 높여 구조를 고정시키고 유연성을 떨어뜨릴 수 있기 때문에, 불필요한 상속보다는 조합과 인터페이스를 통해 확장 가능한 구조를 만드는 것이 더 현명하다는 것을 실제 코드 예제를 통해 이해할 수 있었다.또한 Value Object(VO)와 일급 컬렉션, Enum과 같은 객체 지향적 요소들이 단순한 코드 구조가 아니라 도메인을 명확하게 표현하고, 상태와 행위를 적절하게 추상화하는 데 매우 유용하다는 것을 배웠다. [회고를 통해 느낀 점] 한 주 동안 학습한 내용을 글로 정리하며 "내가 이해했다고 생각한 것 중에 정말 이해한 건 무엇이고, 아닌 건 무엇인가?"를 자문할 수 있었다. 정리하는 과정 자체가 다시 한번 개념을 재정립하는 데 큰 도움이 되었고, 앞으로도 꾸준히 기록하는 습관을 유지해야겠다고 다짐했다.이번 주는 코드를 '읽히게 만드는 법'을 배운 시간이었다. 추상화, 이름짓기, 리팩토링, SOLID… 모든 것은 더 좋은 코드를 위해 존재한다는 것을 느꼈고, 나만의 기준과 언어로 코드를 설명할 수 있는 힘을 더욱 키우고 싶다는 생각이 들었다.앞으로는 작성하는 모든 코드에 대해 "왜 이렇게 작성했는가?"를 스스로 설명할 수 있도록 영양가 있는 고민을 통해 근거 있는 개발을 할 수 있는 개발자가 되고 싶다.

[인프런 워밍업 클럽 4기] BE 스터디 Day 4 미션

Day4. SOLID와 코드 리팩토링 1. 코드 리팩토링 public boolean validateOrder(Order order) { if (order.isEmpty()) { log.info("주문 항목이 없습니다."); return false; } if (!order.hasValidTotalPrice()) { log.info("올바르지 않은 총 가격입니다."); return false; } if (!order.hasCustomerInfo()) { log.info("사용자 정보가 없습니다."); return false; } return true; }public class Order { private List items; private double totalPrice; private Customer customer; public boolean isEmpty() { return items == null || items.isEmpty(); } public boolean hasValidTotalPrice() { return totalPrice > 0; } public boolean hasCustomerInfo() { return customer != null && customer.isValid(); // isValid()는 예시 } } 2. SOLID에 대해 나만의 언어로 정리 S - 단일 책임 원칙 (SRP)한 클래스는 오직 하나의 책임만 가져야 한다.하나의 이유로만 변경되어야 한다.O - 개방/폐쇄 원칙 (OCP)기존 코드를 건드리지 않고, 새로운 기능을 추가할 수 있어야 한다.즉, 확장에는 열려 있고 변경에는 닫혀 있어야 한다.L - 리스코프 치환 원칙 (LSP)자식 클래스는 부모 클래스의 역할을 대체할 수 있어야 한다.부모가 기대한 기능을 자식도 지켜야 함.I - 인터페이스 분리 원칙 (ISP)큰 인터페이스 하나보단 작은 인터페이스 여러 개가 낫다. 사용하지 않는 기능에 대한 의존을 강요하지 말자. D - 의존 역전 원칙 (DIP)구체적인 것보다 추상에 의존하라. 즉, 상위 계층은 하위 계층의 구현에 의존하지 않아야 하고, 인터페이스나 추상 클래스에 의존해야 한다."SOLID는 변경에 강하고 유지보수에 강한 코드 구조를 위한 다섯 가지 설계 원칙이다. 잘게 나누고, 추상화하고, 예상 가능한 방식으로 확장할 수 있도록 만든다."

[인프런 워밍업 클럽 4기] BE 스터디 Day 2 미션

Day2 미션. 추상과 구체의 예시 생각해보기 추상 :음식을 먹는다. 구체 :손과 입으로 음식을 가져가고, 치아로 음식물을 분쇄한다. 침샘에서 나온 침이 음식과 섞이며 아밀레이스 효소가 탄수화물을 분해하기 시작한다.혀가 음식물을 뭉쳐 삼키기 좋게 만들고, 연하 작용을 통해 식도로 넘긴다. 위에서는 위산과 펩신이 단백질을 분해하며, 소화된 음식은 소장으로 이동하여 흡수된다.