[인프런 워밍업 클럽 백엔드 스터디 2기] 2주차 발자국

강의 내용Section 6 : 코드 다듬기주석의 양면성에 대해 배우면서 불필요한 주석을 줄이고 좋은 주석을 작성하는 방법을 배울 수 있었다.변수와 메서드의 나열 순서에 대하여 2가지 방법을 배웠는데 확실히 public 메서드와 private 메서드를 따로 분리하여 나열하는 것이 가독성이 좋아보였다.패키지를 의미 단위로 나누는 방법을 배웠는데, 먼저 코드를 작성하기 전에 필요하다고 느낄 수 있었다.버그를 찾아내고 더 효율적인 stack을 활용하는 방법을 알 수 있었다.SonarLine를 설치했는데 확실히 리팩토링 하는데 도움이 되는 것 같다. Section 7 : 리팩토링 연습스터디 카페 이용권 선택 시스템을 리팩토링하는 과정이다. 미션리팩토링 포인트에 맞추어 스터디 카페 이용권 선택 시스템을 리팩토링하는 미션이다. 회고이번 주차에서는 과제가 생각보다 어려웠다. 이전 강의들을 들으면서 확실히 이해한 부분은 많았는데 막상 실제로 사용해보려니 막막했다. 응용이 생각보다 힘들었다. 포인트에 맞춰서 차근차근 리팩토링했지만 어려운 부분이 많았다. 이후 강의를 통해 다시 한 번 리팩토링 해보았고 여러 번 강의를 돌려 보다가 회고 쓰는 것을 까먹고 늦게 작성했다.. 다음엔 아슬아슬하게 일요일이 아닌 금, 토 중에 작성해야겠다.

[인프런 워밍업 클럽 백엔드 스터디 2기] 1주차 발자국

강의 수강추상과 구체구체적인 이름 짓기 팁과 메서드의 추상화 방법을 알 수 있어서 좋았습니다.추상화 레벨이라는 것을 처음 알게 되었고 추상화 정도에 따라 코드를 분리시키는 것을 이해하기 쉽게 알려 주셨습니다. 논리, 사고의 흐름early return을 배우면서 항상 else가 꼭 필요한가에 대한 의문을 해소할 수 있었습니다.부정문을 써진 코드를 볼 떄마다 복잡하다고 생각했었는데 이를 메서드로 해결하는 방법을 배울 수 있었습니다.Optional을 사용하면서 메서드들의 의미를 자세히 알진 못했는데 덕분에 자세히 알 수 있었습니다. 객체 지향 패러다임평소에 getter를 남발해오던 것이 잘못되었다는 것을 깨달았고 항상 모호하게 생각했던 SOLID 원칙의 개념을 확실하게 잡을 수 있었습니다. 객체 지향 적용하기VO와 Entity의 차이를 알 수 있었고, 기존에 사용해보지 않았던 Enum의 사용법을 배울 수 있었습니다. 학습 회고칭찬하고 싶은 점꾸준히 강의를 들으며 정리를 했다는 점 아쉬웠던 점체력이 따라가지 못해서 다음 날의 강의까지 보지 못 했다.정리를 조금 더 구체적으로 하지 못 했다. 보완해야할 점코드를 따라 치면서 어느 순간 이해를 못 하는 부분이 존재했다.정리한 부분을 보면서 다시 코드를 복기하면서 이해해야할 것 같다. 미션 변경 전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.hasNoItems()) { log.info("주문 항목이 없습니다."); return false; } if (order.wrongTotalPrice()) { log.info("올바르지 않은 총 가격입니다."); return false; } if (order.hasNotCustomerInfo()) { log.info("사용자 정보가 없습니다."); return false; } return true; }해당 코드가 주문이 유효한지 판단하는 코드라고 생각하였다.우선 의미 단위로 코드를 파악하였고 그 과정은 다음과 같다. 1. 주문항목이 존재하는지 판단하는 부분이다.getter를 사용하는 부분을 hasNoItems() 메서드로 변경하고 항목이 존재하지 않는다면 false를 리턴하도록 리팩토링한다.그 뒤 else 부분은 필요 없으므로 else는 제거한다.2. 총 가격이 유효한지 판단하는 부분이다.사용자 정보 유효성을 판단하는 if문까지 같이 있기 때문에 우선 이 부분을 분리하고getter를 사용하는 부분을 wrongTotalPrice() 메서드로 변경한다. 그 뒤의 else if와 else 또한 필요 없으므로 제거한다.3. 사용자 정보가 유효한지 판단하는 부분이다.두 번째에서 분리한 if문을 !가 사용되고 있는데 이것을 부정의 의미를 가진 hasNotCoustomerInfo() 메서드로 변경한다.마지막으로 이 3개의 if문들을 의미 단위로 공백을 준 뒤, 마지막에 if문에 걸리는 것이 없는 경우 true를 리턴 할 수 있도록 return true를 한다.회고이번 미션을 진행하면서 강의에서 배웠던 것을 그대로 적용해보면서 내것으로 만들 수 있었던거 같다.리팩토링을 전에는 해보지 않았지만 걸음마를 뗐다고 할 수 있을 것 같다.

인프런 스터디 미션 4

1. 아래 코드와 설명을 보고, [섹션 3. 논리, 사고의 흐름]에서 이야기하는 내용을 중심으로 읽기 좋은 코드로 리팩토링해 봅시다.✔ 사용자가 생성한 '주문'이 유효한지를 검증하는 메서드.✔ Order는 주문 객체이고, 필요하다면 Order에 추가적인 메서드를 만들어도 된다. (Order 내부의 구현을 구체적으로 할 필요는 없다.)✔ 필요하다면 메서드를 추출할 수 있다.변경 전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; }해당 코드는 주문이 유효한지 판단하는 코드인 것 같다.의미 단위로 보면1. 주문항목이 존재하는지 판단하는 부분이다.getter를 사용하는 부분을 hasNoItems() 메서드로 변경하고 항목이 존재하지 않는다면 false를 리턴하도록 리팩토링한다.그 뒤 else 부분은 필요 없으므로 else는 제거한다.2. 총 가격이 유효한지 판단하는 부분이다.사용자 정보 유효성을 판단하는 if문까지 같이 있기 때문에 우선 이 부분을 분리하고getter를 사용하는 부분을 wrongTotalPrice() 메서드로 변경한다. 그 뒤의 else if와 else 또한 필요 없으므로 제거한다.3. 사용자 정보가 유효한지 판단하는 부분이다.두 번째에서 분리한 if문을 !가 사용되고 있는데 이것을 부정의 의미를 가진 hasNotCoustomerInfo() 메서드로 변경한다.마지막으로 이 3개의 if문들을 의미 단위로 공백을 준 뒤, 마지막에 if문에 걸리는 것이 없는 경우 true를 리턴 할 수 있도록 return true를 한다.변경 후public boolean validateOrder(Order order) { if (order.hasNoItems()) { log.info("주문 항목이 없습니다."); return false; } if (order.wrongTotalPrice()) { log.info("올바르지 않은 총 가격입니다."); return false; } if (order.hasNotCustomerInfo()) { log.info("사용자 정보가 없습니다."); return false; } return true; } 2. SOLID에 대하여 자기만의 언어로 정리해 봅시다.SRP : Single Responsiblity Principle단일 책임 원칙 말 그대로 책임을 하나만 갖는다는 것이다. 하나의 책임은 하나의 역할을 갖는다는 의미와 같다.ex) 옛날 레노버 키보드를 보면 빨콩이라고 키보드에서 마우스 역할을 하는 트랙 포인터가 달려 있다. 현재는 키보드와 마우스를 따로 분리한 것이 더 효율적이다.OCP : Open-Closed-Principle개방-폐쇄 원칙으로 확장에는 열려 있고 변경에는 닫혀 있다.ex) 기능의 확장은 한 클래스 내의 메서드 추가로 가능하지만 기능의 변경은 클래스 내에 존재하는 메서드의 내용을 변경하는 일이기 때문에 기존의 코드가 변경된다.LSP : Liskov Substitution Principle리스코프 교체 원칙으로 상속 구조에서 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 치환할 수 있다.ex) 부모 클래스 내에 잡기, 때리기, 뛰기 3개의 기능을 하는 메서드가 있을 때 어떤 한 자식 클래스에서 잡기, 때리기, 눕기라는 부모 클래스와는 다른 메서드가 존재할 경우 예외가 발생할 수 있다.ISP : Interface Segregation Principle인터페이스 분리원칙으로 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하면 안 된다.ex) 어떤 인터페이스를 구현한 구현체가 2개가 있다. 그런데 한 구현체에서는 인터페이스 내의 기능들을 모두 사용하지만, 나머지 한 구현체는 인터페이스 내의 기능 중 단 한 가지 기능만을 사용한다. 이를 해결하기 위해 인터페이스를 필요한 기능 단위로 분리한 뒤 구현체에 필요한 인터페이스들을 상속시켜주면 된다.DIP : Dependency Inversion Principle의존성 역전 원칙으로 상위 모듈은 하위 모듈에 의존하면 안 되며, 둘 다 추상화에만 의존해야 한다.하위 모듈이 변경되어도 상위 모듈에는 영향이 가지 않는다.ex) 스마트폰이라는 상위 모듈이 존재할 때 스마트폰은 어플이라는 인터페이스를 통해 다양한 기능의 어플들을 사용할 수 있다.지도 어플, 금융 어플, 게임 어플 등의 하위 모듈은 어플이라는 인터페이스를 통해 구체화된다.