[워밍업 클럽 4기 백엔드] 2주차 발자국

리팩토링 과정이전까지는 코드가 작동하는 것에 포커스를 두고 개발하다가 나의 프로젝트를 모르는 사람이 나의 코드 일부분만 보더라도 이해할 수 있도록 하자는 목표로 최대한 코드의 역할도 분리해보고 코드를 작성한 후 이것보다 나은 방향을 없을까?에 대한 고민에 많은 시간을 투자해보는 시간을 가졌다. 읽기 쉬운 코드리팩토링을 하면서 다른 분들의 코드도 참고하다보니 동일한 코드를 리팩토링을 한다고해도 각자의 개성과 생각이 다르기 때문에 모두 결과가 다른 것을 보게되었다. 이후 리팩토링의 결과보다는 과정에 집중하자는 마인드를 가지게 되었다.강의 느낀점처음에는 이 많은 강의를 2개나 다 들을 수 있을까? 했지만 어느덧 하나의 강의가 끝나가니 뿌듯함이 생기는 것 같다 나머지 강의도 끝까지 따라갈 수 있도록 노력해야겠다. https://inf.run/BiPNS

[워밍업 클럽 4기 백엔드] 1주차 발자국

추상 → 구체 전개 방식‘휴식을 취한다’라는 추상적 문장을 실제 행동(커튼 걷기, 커피 내리기, 무음 모드 켜기 등)으로 풀어 써 보면서, 아이디어를 바로 실행 가능한 단계로 쪼개는 사고법을 익혔다. 요구사항 정의나 기능 설계에도 같은 원리가 적용될 수 있음을 깨달았다. 읽기 좋은 코드로의 리팩터링AS-IS 코드의 중첩 if – else를 Early Return로 바꿔 흐름을 일직선으로 만들고, 검증 로직을 도메인 메서드(isEmptyItems, isInvalidTotalPrice 등)로 숨겨 Tell, Don’t Ask 스타일을 연습했다. 빈 줄로 관심사를 구분하고, null 방어 로직을 최상단에 둬 예외를 선제적으로 처리하는 습관도 배웠다. SOLID 원칙 재해석‘하나씩만(단일 책임)’, ‘더하기만 가능(개방-폐쇄)’, ‘누가 해도 가능(리스코프 치환)’처럼 내 언어로 각 원칙을 요약해 보며, 설계 규칙을 머릿속에 직관적으로 각인시켰다. 특히 의존 역전 원칙을 ‘220V만 맞으면 어떤 플러그든’이라고 비유하면서, 상위 모듈은 추상에만 의존해야 유연해진다는 메시지를 체감했다. https://inf.run/AvGzg

워밍업 클럽 4기 - 백엔드 Day 4

읽기 좋은 코드로 리팩토링AS - ISpublic 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; } TO - BEpublic void checkOrder(Order order) { if (order.isEmptyItems()) throw new NoItemException("주문 항목이 없습니다."); if (order.isInvalidTotalPrice()) throw new IllegalPriceException("올바르지 않은 총 가격입니다."); if (order.isEmptyCustomerInfo()) throw new EmptyCustomerInfoException("사용자 정보가 없습니다."); } Early Return else 없이 조건에 맞지 않으면 곧바로 throw → 코드 흐름이 일직선으로 이어져 가독성 향상Reduce Thinking Depth 중첩된 if–else-if 구조를 모두 제거하고 검증 조건을 위에서 아래로 나열 각 검증 블록이 독립적으로 동작하므로 머릿속으로 추적해야 할 깊이가 줄어듦Add New Line to Separate 항목 검증, 가격 검증, 사용자 정보 검증 사이에 빈 줄을 넣어 관심사(검증 종류) 구분이 명확해짐Refactor Negative Phrase if (!(order.getTotalPrice() > 0)) → if (order.isInvalidTotalPrice()) 같은 긍정적 메서드명 사용 조건 자체의 의미가 더 선명해짐 Handle Exceptions More Carefully order == null 검사를 제일 앞에 추가해 예상치 못한 NullPointerException 방지 외부에서 checkOrder(null) 호출 대비Tell, Don’t Ask order.getItems().size() == 0 대신 order.isEmptyItems() order.getTotalPrice() > 0 대신 order.hasValidTotalPrice() 도메인 메서드로 추상화해 “명령(tell)” 식 호출로 바꿈 2. SOLID에 대하여 자기만의 언어로 정리해 봅시다. 단일책임원칙하나씩만 : 클래스는 한 가지 일만 맡아 수정 이유를 딱 하나로 제한한다. 개방폐쇄원칙더하기만 가능 : 코드 수정 없이 확장(새 기능 추가)만으로 변화에 대응할 수 있게 설계한다. 리스코프치환원칙누가 해도 가능 : 부모 대신 자식 객체를 넣어도 동일한 결과가 나와야 다형성이 안전하다. 인터페이스분리원칙꼭 필요한 것만 : 클라이언트가 쓰지 않는 메서드를 강요받지 않도록 작은 인터페이스로 나눈다. 의존역전원칙220v 이기만 하면 어떤 플러그든 가능 : 상위 로직은 구체 구현이 아닌 추상(인터페이스)에만 의존해, 구현 교체가 쉽다. https://inf.run/AvGzg

워밍업 클럽 4기 - 백엔드 Day 2 추상과 구체

추상 - 구체 예시추상 : 휴식을 취한다.구체 : 주말 낮 12시, 커튼을 걷고 기지개를 켠다.커피를 한 잔 내려서 소파에 앉는다.폰은 무음으로 두고 좋아하는 음악을 재생시켜 헤드폰을 사용해서 듣는다.눈을 감고 몸의 긴장을 푼다.주말마다 제가 휴식을 취하는 과정을 구체화해서 작성했습니다. https://inf.run/AvGzg