워밍업 클럽 3기 백엔드 code - 1주차 발자국

지원 계기개발자로서 업무를 시작하고 4년차가 된 지금 까지 나름 시간을 투자하여 꾸준히 성장하기 위해 노력해왔다.인프런을 비롯한 여러 플랫폼에서의 강의와 개인 프로젝트, 서적과 레퍼런스들을 참고하며 처음 개발을 시작했을 때 보다 확실하게 성장했다는 것을 자각할 수 있을 정도였지만, 어느센가 업무와 개인의 성장 사이에 괴리가 생기기 시작했고, 무엇보다 현재 직장에서 개발 파트가 혼자였기에, 함께 성장하기라는 갈증이 생기게 되었다.그렇게 지지부진한 일상을 보내면서 우연히 인프런의 워밍업 클럽을 알게 되었고 이 전 부터 배울 것이 많은 개발자라 생각되었던 우빈님의 코스를 선택하게 되었다. 마침 클린코드와 테스트는 항상 관심 깊은 분야였고, 고민하던 분야였기에 더욱 선택에 있어 고민이 없었던 것 같다.강의 수강그렇게 시작하고, 일주차를 보내며, 기대 이상의 동기부여와 성장의 즐거움을 느낄 수 있었다.사실 처음 신청하면서도 클린코드며 객체 지향과 같은 패러다임은 어느 정도 잘 알고 잘 지키며 개발하고 있다고 생각했었기에 "복습하는 마음으로 임하자."라고 생각했지만, 막상 시작된 강의는 다음과 같은 내용을 배울 수 있었고, 내가 얼마나 오만했는지 느끼게 해주었다. 추상클린 코드는 왜 필요한가?클린 코드를 위해 무엇이 필요하며, 어떤 일들을 할 수 있는가?추상화가 이런 것들을 어떻게 도울 수 있는가?논리, 사고의 흐름우리의 사고는 어떻게 동작하는가?이러한 사고의 흐름을 위해 어떤 논리를 사용해야 이해하기 쉬운가?객체 지향 패러다임객체 지향은 왜 필요한가?어떤 원칙들을 통해 객체 지향을 구현할 수 있는가?이러한 원칙들은 왜 필요한가?첫 주제인 추상부터 나의 구현 방식이 얼마나 얕았는가 되돌아보게 해주었다. 이후 진행되었던 논리와 객체 지향 역시 마찬가지였다. 다 안다고 생각했던 개념들이 "정말 다 알아?"라고 반문하는 것만 같았다.덕분에 개념적으로 더 깊이 들어갈 수 있었고, 보다 시스템에 대한 고민을 갖고 개발할 수 있는 사고의 흐름을 얻게된 것 같다. 미션미션을 수행하면서도 마찬가지였다. 단순히 주어진 과제를 해결하는 것이 아닌 이걸 왜 이렇게하지? 이 개념은 왜 필요하지? 등의 고민을 할 수 있었던 것 같다.특히 두 번째 미션 중 SOLID를 나의 언어로 설명하기는 강의를 듣고, 다시 레퍼런스와 자료를 찾아보며, 이 원칙들이 왜 시스템에 필요하고, 이렇게 사용하는지 되돌아보며, 그렇게 얻은 지식을 소화해내는 과정을 얻을 수 있어 인상적이었다.

워밍업 클럽 3기 BE 클린코드 - Day 4 미션

코드 리팩토링public boolean validateOrder(Order order) { try { checkOrderContainsItems(order); checkOrderHaveValidPrice(order); checkOrderContainCustomerInfo(order); return true; } catch(OrderException e) { log.error(e.getMessage()); return false; } } private void checkOrderContainsItems(Order order) { if (order.containsNoItems()) { throw new OrderException("주문 항목이 없습니다."); } } private void checkOrderContainCustomerInfo(Order order) { if (order.doesNotContainCustomerInfo()) { throw new OrderException("사용자 정보가 없습니다."); } } private void checkOrderHaveValidPrice(Order order) { if (order.priceIsInvalid()) { throw new OrderException("올바르지 않은 총 가격입니다."); } }SOLID단일책임 원칙객체는 하나의 책임만 담당해야 하며, 이를 달성하는 데만 집중해야 한다.여러 책임이 하나의 객체에 있을 경우 유지보수 시 책임간의 충돌이 일어날 수 있다.책임간의 충돌은 신뢰할 수 없는 기능, 더 나아가 불완전한 프로그램이 될 수 있다.즉 책임이 하나라는 것은 객체를 변경해야 하는 이유는 단 하나여야 한다는 것이다.개방/폐쇄 원칙확장에는 열려있고, 변경에는 닫혀있다는 것은 새로운 요구사항이 기존 코드에 대한 변경은 최소화 하고, 새로운 구현으로 확장해나간다는 것이다.리스코프 치환 원칙기본 객체의 기능을 파생 객체가 대체할 수 있어야 한다.이를 달성하기 위해서는 해당 객체의 의도를 파악하여야 한다.이러한 의도를 가장 명확하게 파악하고, 전달하는 방법은 테스트 코드인스턴스 분리 원칙클라이언트가 자신이 사용하지 않는 기능에 의존하지 말아야 한다.즉 자신이 사용하지 않는 기능을 구현해야 한다면 해당 인터페이스는 이 원칙을 어긴 것이다.이러한 원칙은 코드의 응집도를 높일 수 있으며, 코드의 재사용성도 높아진다.의존성 역전 원칙상위 모듈은 하위 모듈에 의존해서는 안되며, 상위 모듈과 하위 모듈은 모두 추상화에 의존해야 한다.상위 모듈은 추상화에 의존해야 하며, 하위 모듈은 추상화를 구현해야 한다.이러한 원칙을 통해 응집도를 높이고, 변경의 전파를 최소화할 수 있다. 결과적으로 SOLID 원칙을 지킨다는 것은 신뢰할 수 있는 프로그래밍을 위한 도구를 사용한다는 것으로 보인다.이를 통해 협업에서 신뢰할 수 있는 분업이 가능해지고, 결과적으로 안정적인 프로그램을 구축할 수 있다고 생각된다.참고: 자바/스프링 개발자를 위한 실용주의 프로그래밍, 김우근 - 위키북스