공부 기록63 [리팩토링 1판] 마지막 챕터 마무리 챕터 Chapter 13. 리팩토링, 재사용, 현실성 리팩토링은 프로그램 구조를 수정해서 설계를 더 이해하기 쉽게 만든다. 프레임워크를 개발하고 재사용 가능한 구성 요소를 뺴낸다. 프로그램 구조를 단순화한다. 나중에 손쉽게 기능을 추가할 수 있게 하는 방편이다. 이처럼 리팩토링을 실시하면 과거에 시간과 비용을 투자해 만든 코드를 활용하고, 중복 코드를 줄이며, 프로그램을 간소화할 수 있다. 리팩토링 왜 안할까? 위의 장점에도 불구하고 왜 리팩토링을 하지 않을까? 리팩토링 방법을 몰라서 리팩토링의 장점은 오랜 시간이 흘러야 가시화될테고, 그때가 되면 프로젝트 팀원도 아닐텐데 공연히 리팩토링에 힘 뺄 필요 없어서 코드를 리팩토링하는 일을 추가적인 부담인데다, 월급은 새 기능을 추가하라고 주는거지 리팩.. 2024. 4. 12. [리팩토링 1판] Chapter 12. 복합 리팩토링 Chapter 12. 복합 리팩토링 리팩토링은 개발 작업을 지연시키려고 하는 게 아니라 어떤 목적이 있어서 하는 것이다. 시스템이 제품화 단계에 들어간 상태에서 기능을 추가해야 할 때, 2개월간 코드를 정리해야 해서 작업을 중단해야 한다고 팀장을 설득하기란 무리다. 따라서 리팩토링은 주변 정리부터 매일 조금씩 해나가야 한다. 리팩토링은 기능을 추가할 때나 버그를 수정할 때 실시하자. 리팩포링은 시작했을 때 끝을 봐야하는건 아니다. 실제 작업을 수행하는데 필요한 만큼 하자. 필요하다면 나중에 언제든지 되돌릴 수 있다. 복잡 리팩토링은 단순 리팩토링 기법과 달리 개발팀 전원의 합의 하에 실시해야 한다. 팀 전원은 복합 리팩토링 중 하나가 현재 진행 중임을 알고 그에 따라 움직여야 한다. 이는 사공이 많아 배.. 2024. 4. 11. [리팩토링 1판] Chapter 11. 일반화 처리 Chapter 11. 일반화 처리 일반화는 주로 상속 계층구조나 상속 계층의 위나 아래로, 즉 상위클래스나 하위클래스로 메서드를 옮기는 기법이다. 하나씩 어떤 것이 있는지 살펴보자. 필드 상향 두 하위클래스에 같은 필드가 들어 있을 때 필드를 상위클래스로 옮기자. public class Employee { static class Salesman extends Employee { String name; } static class Engineer extends Employee { String name; } } 리팩토링 후 public class Employee { String name; static class Salesman extends Employee { } static class Engineer ext.. 2024. 4. 9. [리팩토링 1판] Chapter 10. 메서드 호출 단순화 Chapter 10. 메서드 호출 단순화 객체에서 가장 중요한 것은 인터페이스다. 이해와 사용이 쉬운 인터페이스를 작성하는 기술이야 말로 좋은 객체지향 소프트웨어 개발에 꼭 필요하다. 인터페이스를 더 쉽게 만드는 리팩토링 가장 간단하면서도 중요한 것은 메서드명을 변경하는 일이다. 매개변수 자체는 인터페이스를 다루는데 상당한 역할을 한다. ... 좋은 인터페이스는 보여줘야 할 만큼만 딱 보여준다. 공개할 필요가 없는 것들을 감추는 것만으로 인터페이스를 개선할 수 있다. 메서드명 변경 메서드명을 봐도 기능을 알 수 없을 땐 메서드명을 직관적인 이름으로 바꾸자. public class Sample1 { public int getInvcdtlmt() { return 0; } } 리팩토링 후 public clas.. 2024. 4. 6. [리팩토링 1판] Chapter 09. 조건문 간결화 Chapter 09. 조건문 간결화 조건문은 복잡해질 가능성이 높은 만큼, 리팩토링 기법이 다양하다. 그 중 핵심적인 기법은 조건문을 여러 개로 나누는 조건문 쪼개기다. 이 기법은 세부 기능에서 스위칭 로직을 분리하므로 중요하다. 조건문 쪼개기 복잡한 조건문이 있을 땐 if, else-if, else 부분을 각각 메서드로 뺴자. public class Sample1 { public void methodA() { if (data.before(SUMMER_START) || date.after(SUMMER_END)) { charge = quantity + winterRate + winterServiceCharge; } else { charge = quantity + summerRate; } } } 리팩토링 후.. 2024. 4. 4. [리팩토링 1판] Chapter 08. 데이터 체계화 Chapter 08. 데이터 체계화 이번 장은 내용이 좀 많다. 다 아는 내용일 수도 있지만 "아, 이런 것들이 있었지 혹은 있었구나."라고 복습 차원에서 한번 훓어보는 것이 좋다. 다만, 외우려고 하지 말자. 이 장에서 다루는 리팩토링 기법은 데이터 연동을 더 간편하게 해준다. 많은 이들이 필드 자체 캡슐화는 불필요하다고 생각한다. 객체가 내부의 데이터에 직접 접근하게 해야할지, 아니면 getter/setter 메서드를 통해 접근하게 해야 할지에 대한 문제는 오랫동안 좋은 논란거리였다. 이 책이 2002년에 출판된 책인데.. 사실상 요즘은 거의 패턴이 정해져 있다. 위 고민들은 안하게 되고 당연하게 필드는 캡슐화한다. 필드 자체 캡슐화 필드에 직접 접근하던 중 그 필드로의 결합에 문제가 생길 땐 그 필.. 2024. 4. 3. 이전 1 2 3 4 5 6 ··· 11 다음
