블로그
전체 22025. 06. 01.
1
Readable Code - 읽기 좋은 코드의 필요성에 대해
Readable Code를 지향해야 하는 이유 실제로 업무를 하다보면, 다양한 레거시 코드에 부딪힌다.일전에 한번이라도 코드 손을 봤던 도메인의 경우에는 비교적 쉽게 어디를 고쳐야 할 지 파악하기가 쉽다.하지만 새로 들여다 봐야 하는 도메인의 경우에는 모든 코드를 일일히 읽으며 어디가 문제인지, 어떻게 해결 해 나가야 할 지를 파악해야 한다. 10에 7개 정도는 다음과 같은 이유로 읽기 어려운 경우가 종종 있었다.Magic Number 남발추상화 레벨이 다른 코드 수없이 많은 if - else 분기 처리문많은 코드들의 경우 위 세개만 지켜져도 추후 내가 작성하지 않은 코드를 파악할 때, 훨씬 수월 할 것으로 예상된다.실제로 업무를 하며, 손을 대는 코드들의 경우 위의 문제 및 강의에서 배운 다양한 기법들을 적용해 나가고자 노력하고 있다.아직까지는 몸에 많이 배어있지 않아 어려운 감이 없지않아 있으나, 점차 더 좋은 코드를 짤 수 있기 위한 성장통이라고 생각하고 열심히 수련을 해 보고자 한다.
2025. 05. 30.
0
워밍업 클럽 4기 - 백엔드 Day 4 미션
코드 Refactoring이전 코드 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.getItems().isEmpty()) { log.info("주문 항목이 없습니다."); return false; } if (order.getTotalPrice() Early return을 적용하여 중첩이 깊어지는 사항을 제거하였습니다.order의 item 개수를 검증할 때, isEmpty() 메서드로 보다 이해하기 좋은 코드로 변경하였습니다. SOLID Single Responsibility Principal각 클래스는 하나의 책임만 가져야 하며, 변경 사유도 하나여야만 한다.Open Closed Principal확장에는 열려있어야 하고, 변경에는 닫혀 있어야 한다.기존 코드를 변경하지 않고도 기능을 추가할 수 있어야 한다.Liskov Substitution Principal부모 타입 객체를 자식 타입 객체로 치환해도 프로그램의 기능이 제대로 동작해야 한다.Interface Segregation Principal인터페이스는 구체적이고 최소한으로 작게 분리 되어야 한다.Dependency Inversion Principal고수준 모듈은 저수준 모듈에 의존하지 않고, 공통된 추상화에 의존해야 한다.