BackEnd/Refactoring13 [Refactoring] 데이터 클래스 (Data Class), 유산 포기 (Refused Bequest), 주석 (Comments), 중첩 조건문을 보호 구문으로 바꾸기 (Replace Nested Conditional with Guard Clauses) 백기선 님의 리팩터링 강의를 들으며 요약한 내용입니다. 18. 데이터 클래스 ▶ 데이터 클래스 : public 필드 또는 필드에 대한 게터와 세터만 있는 클래스 - 코드가 적절한 위치에 있지 않기 때문에 이러한 냄새가 생길 수 있다. - 예외적으로“단계 쪼개기”에서 중간 데이터를 표현하는데 사용할 레코드는 불변 객체로 데이터를 전달하는 용도로 사용할 수 있다. public 필드를 가지고 있다면 “레코드 캡슐화하기 (Encapsulate Record)”를 사용해 getter/setter를 통해서 접근하 도록 고칠 수 있다. (여기서 말하는 "레코드"는, public 필드로 구성된 데이터 클래스를 말한다) 변경되지 않아야 할 필드에는“세터 제거하기 (Remove Setting Method)”를 적용할 수 있.. BackEnd/Refactoring 2023. 1. 8. [Refactoring] 중재자 (Middle Man), 내부자 거래(Insider Trading), 거대한 클래스 (Large Class) 백기선 님의 리팩터링 강의를 들으며 요약한 내용입니다. 15. 중재자 캡슐화는 내부의 구체적인 정보를 최대한 감출 수 있기 때문에 자주 사용된다. 그러나, 어떤 클래스의 메소드가 대부분 다른 클래스로 메소드 호출을 위임하고 있다면 중재자를 제거하고 클라이언트가 해당 클래스를 직접 사용하도록 코드를 개선할 수 있다. 15 - 1) 중재자 제거하기 필요한 캡슐화의 정도는 상황에 따라서 달라질수가 있다. 흔히 말하는 Law of Demeter를 지나치게 따르기 보다는 상황에 맞게 활용하도록 하자! 예를 들어 원래는 Person에 getManager()를 통해 한번에 manager를 얻어올 수 있었다. public class Person { private Department department; private .. BackEnd/Refactoring 2023. 1. 8. [Refactoring] 성의없는 요소 (Lazy Element), 추측성 일반화 (Speculative Generality), 임시 필드 (Temporary Field) 백기선 님의 리팩터링 강의를 들으며 요약한 내용입니다. 12. 성의없는 요소 프로그래밍을 하면서 여러 변수, 메서드, 클래스를 만들게 된다. 만들 당시에는 의미를 명확하게 하기 위해서, 또는 중복을 제거하기 위해서 사용했겠지만... 그렇게 예상하고 만들어 놓은 요소들이 기대에 부응하지 못하는 경우가 있는데 그런 경우에 해당 요소들을 제거해야 한다! 함수 인라인, 클래스 인라인, 계층 합치기 를 통하여 리팩토링 할 수 있다. 13. 추측성 일반화 나중에 이러 저러한 기능이 생길 것으로 예상하여, 여러 경우에 필요로 할만한 기능을 만들어 놨지만 “그런 일은 없었고...”결국에 쓰이지 않는 코드가 발생한 경우. XP의 YAGNI (You aren’t gonna need it) 원칙을 따르자. => 지금 당장 .. BackEnd/Refactoring 2023. 1. 7. [Refactoring] 데이터 뭉치 (Data Clumps), 기본형 집착 (Primitive Obsession) 백기선 님의 리팩터링 강의를 들으며 요약한 내용입니다. 10. 데이터 뭉치 ▶ 항상 뭉쳐 다이는 데이터는 한 곳으로 모아두는 것이 좋다. 1) 여러 클래스에 존재하는 비슷한 필드 목록 2) 여러 함수에 전달하는 매개변수 목록 관련 리팩토링 기술 관련된 리팩토링 기술로는, “클래스 추출하기 (Extract Class)”를 사용해 여러 필드를 하나의 객체나 클래스로 모을 수 있다. “매개변수 객체 만들기 (Introduce Parameter Object)” 또는 “객체 통째로 넘기기 (Preserve Whole Object)”를 사용해 메소드 매개변수를 개선할 수 있다. 11. 기본형 집착 보통 애플리케이션을 개발할 때 도메인에 필요한 기본 타입을 만들기보다는 프로그래밍 언어가 제공하는 기본타입을 사용하는 .. BackEnd/Refactoring 2023. 1. 6. [Refactoring] 산탄총 수술 (Shotgun Surgery), 기능 편애 (Feature Envy) 백기선 님의 리팩터링 강의를 들으며 요약한 내용입니다. 8. 산탄총 수술 왜 그냥 Gun도 아닛고 Shotgun일까? 샷건은 여러 파편이 퍼져 나간다는점을 상기하면 납득이 간다. 이전에 살펴본 뒤엉킨 변경의 경우 여러 이유로 하나의 Class를 계속해서 손봐야 하는 경우이다. 이번 산탄총 수술의 경우 새로운 방식을 도입하려면 여러 곳을 수정해야 한다. 8 - 1) 필드 옮기기 처음에는 타당해 보였던 설계적인 의사 결정도 프로그램이 다루고 있는 도메인과 데이터 구조에 대해 더 많이 익혀나가면서, 틀린 의사 결정으로 바뀌는 경우도 있다. 필드 또한 처음 만들때는 적절해 보였을 수 있지만, 어느순간 부터 다른 데이터와 항상 함께 전달된다거나, 어떤 레코드를 변경할때 다른 곳에 있는 필드를 변경해야 하는 경우 .. BackEnd/Refactoring 2023. 1. 6. [Refactoring] 뒤엉킨 변경 (Divergent Change) 백기선 님의 리팩터링 강의를 들으며 요약한 내용입니다. 7. 뒤엉킨 변경 소프트웨어는 변경에 유연하게(soft) 대처할 수 있어야 한다. 어떤 한 모듈이 (함수 또는 클래스가) 여러가지 이유로 다양하게 변경되어야 하는 상황에서 이러한 모듈이 책임에 따라 잘 분리되어 있다면 변경에 대처하기가 쉽다. 예) 새로운 결제 방식을 도입하거나, DB를 변경할 때 동일한 클래스에 여러 메소드를 수정해야 하는 경우. 서로 다른 문제는 서로 다른 모듈에서 해결해야 한다. 모듈의 책임이 분리되어 있을수록 해당 문맥을 더 잘 이해할 수 있으며 다른 문제는 신경쓰지 않아도 된다. 7 - 1) 단계 쪼개기 다음과 같이 priceOrder라는 매우 다양한 역할을 하고 있는 메서드가 있다. public class PriceOrde.. BackEnd/Refactoring 2023. 1. 4. [Refactoring] 가변 데이터 (Mutable Data) 백기선 님의 리팩터링 강의를 들으며 요약한 내용입니다. 6. 가변 데이터 함수형 프로그래밍에서는 데이터를 변경할 때 복사본을 전달한다. 하지만 Java와 같은 언어에서는 데이터의 변경을 허용한다. Call By Value를 생각해보면 주소값을 전달하기에 변경여파가 크다. 따라서 데이터가 변경될 시 발생할 수 있는 여파를 관리할 방법을 적용해야 한다. 6 - 1) 변수 쪼개기 어떤 변수에 할당이 여러번 되고 있다 생각해 보자. 과연 적합한 상황일까? 다음 Rectangle 코드를 살펴보자! ▶ Rectangle public class Rectangle { private double perimeter; private double area; public void updateGeometry(double heig.. BackEnd/Refactoring 2023. 1. 3. [Refactoring] 전역 데이터 (Global Data) 백기선 님의 리팩터링 강의를 들으며 요약한 내용입니다. 5. 전역 데이터 " data-ke-type="html"> HTML 삽입 미리보기할 수 없는 소스 전역 데이터(Java의 Public static 변수)는 아무 곳 에서나 변경될 수 있기 때문에 문제가 된다. 어떤 코드로 인하여 어디서 변경된것 인지? 한눈에 파악하기가 매우 어렵다. 이는 Class의 필드에서 또한 같은 문제가 발생할 수 있다. 이를 해결하는 한가지 방법으로, 변수를 캡슐화하여 사용하면 접근을 제어할 수 있고 어디서 사용하는지 파악하기 쉽다. 1. 변수 캡슐화하기 (Encapsulate Variable) 데이터를 변경할 경우 이를 사용하는 모든 곳에 수정을 한 번에 다 해주어야 한다. 이에 반해, 메서드는 기존 메서드를 그대로 둔 상.. BackEnd/Refactoring 2022. 2. 24. [Refactoring] 긴 매개변수 목록 (Long Parameter List) 백기선 님의 리팩터링 강의를 들으며 요약한 내용입니다. 4. 긴 매개변수 목록 " data-ke-type="html"> HTML 삽입 미리보기할 수 없는 소스 어떤 함수에 매개변수가 많을수록 함수의 역할을 이해하기 어려워 진다. 과연 그 함수는 한가지 일만 하고있는것이 맞는가? 불필요한 매개변수는 없는가? 하나의 레코드로 뭉칠수 있는 매개변수 목록은 없는가? 어떤 매개변수를 다른 매개변수를 통해 알아낼 수 있다면 => “매개변수를 질의 함수로 바꾸기 (Replace Parameter with Query)”를 사용할 수 있다. 기존 자료구조에서 세부적인 데이터를 가져와서 여러 매개변수로 넘기는 대신, “객체 통째로 넘기기 (Preserve Whole Object)”를 사용할 수 있다. 일부 매개변수들이 대.. BackEnd/Refactoring 2022. 2. 23. [Refactoring] 긴 함수 (Long Function) 백기선 님의 리팩터링 강의를 들으며 요약한 내용입니다. 3. 긴 함수 " data-ke-type="html"> HTML 삽입 미리보기할 수 없는 소스 긴함수와 잛은 함수의 기준은 몇줄일까? 이는 사람마다 다를 수 있다. 다만, 코드를 읽어 나갈때 "의도"가 한눈에 전달이 된다면 짧은 코드이고, "구현"에 해당하는 부분이 많아 한줄 한줄 읽어 나가야 한다면 긴 코드라고 할 수 있다. "과거에는" 작은 함수를 여러번 호출하면 더 많은 서브루틴의 호출로 인해 오버헤드가 있었지만, 요즘의 하드웨어는 너무나 성능이 좋기 때문에 고려하지 않아도 좋다. 사용해볼 리팩토링 기술 들로는~ 99%는 함수 추출하기로 해결 가능하다. 함수로 분리하면서 해당 함수로 전달해야 할 매개변수가 많아진다면 다음과 같은 리팩토링을 고려.. BackEnd/Refactoring 2022. 2. 22. [Refactoring] 중복 코드 (Duplicated Code) 백기선 님의 리팩터링 강의를 들으며 요약한 내용입니다. 2. 중복코드 " data-ke-type="html"> HTML 삽입 미리보기할 수 없는 소스 중복되는 코드는 제거하여 코드의 가독성을 높혀야 한다. 동일한 코드를 여러곳에서 사용하는 경우 => 함수로 추출하기 (Extract Function) 코드가 어느정도는 비슷하게 생겼지만, 완전하게 같지는 않은경우 => 코드 정리하기 (Slide Statements) Slide Statements는 말 그대로 문단의 위치를 조종하는 것 이다. 여러 하위클래스에 동일한 코드가 있다면 => 메서드 올리기 (Pull Up Method) 위와 같은 방식으로 중복 코드를 제거 할때는 동일한 코드 부분 모두를 변경해주어야 한다. 일부분 만 변경해주면 나중에 버그가 발생.. BackEnd/Refactoring 2022. 2. 20. [Refactoring] 이해하기 힘든 이름 (Mysterius Name) 백기선 님의 리팩터링 강의를 들으며 요약한 내용입니다. 1. 이해하기 힘든 이름 " data-ke-type="html"> HTML 삽입 미리보기할 수 없는 소스 깔끔한 코드에서 가장 중요한 것 중 하나가 바로 “좋은 이름”이다. 함수, 변수, 클래스, 모듈의 이름 등 모두 어떤 역할을 하는지 어떻게 쓰이는지 직관적으로 이해할 수 있어야 한다. 다음과 같은 방식으로 이름을 리팩터링 할 수 있다. 함수 선언 변경하기 (Change Function Declaration) 변수 이름 바꾸기 (Rename Variable) 필드 이름 바꾸기 (Rename Field) 1. 함수 선언 변경하기 함수의 선언 변경에는 함수 이름 변경하기, 메서드 이름 변경하기, 매개변수 추가하기, 매개변수 제거하기, 시그니처 변경하기.. BackEnd/Refactoring 2022. 2. 19. 이전 1 2 다음
