Recommended
Recommended
More Related Content
Featured
Featured (20)
x123.tk 리팩토링
- 3. •
- 4. • •
- 5. • • • • 구조가 완전하지 못한 코드에 대해 실시하 는것 • 버그를 찾기 쉬워짐 • 프로그래밍 속도가 빨라짐 • 설계개선, 가독성향상, 버그감소
- 6. • • •
- 8. • • • •
- 9. • • • • •
- 10. • • • •
- 11. • • •
- 12. • •
- 13. • • • • •
- 14. • • • •
- 15. • • • •
- 16. • • • 리팩토링은 코드를 깔끔하게 만다는 것 이 상의 순기능을 한다. • 리팩토링은 소프트웨어 개발 과정의 핵심 요소이다.
- 17. • • • • • • • • • • • • 직무유기 클래스 • 막연한 범용코드 • 임시필드 • 메시지 체인 • 과징 중개 메서드 • 지나친 관여 • 인터페이스가 다른 대용 클래스 • 미흡한 라이브러리 클래스 • 데이터 클래스 • 방치된 상속물 • 불필요한 주석 •
Editor's Notes
- 리팩토링은 무엇인가 * 겉으로 드러나는 기능은 그대로 둔 채, 알아보기 쉽고 수정하기 편하게 소프트웨어 내부를 수정하는 작업
- 리팩토링의 목적 소프트웨어를 더 이해하기 쉽고 수정하기 쉽게 만드는것 겉으로 드러아는 소프트웨어 기능에 영향을 주지 않는다.
- 리팩토링은 왜 해야 하나 소프트웨어 설계가 개선되니까 단기적인 목적으로 코드를 이해하지 않고 수정하면 코드 구조가 뒤죽박죽이 되어 그 코드를 파악하기 어려워 집니다. 리팩토링은 그렇게 구조가 산만해진 코드를 정리 하는 작업입니다. 이렇게 잘못된 코드들의 설계를 개선하는 주요 비법중 하나가 중복 코드를 제거 하는것 입니다. 중복코드 제거는 설계의 필수요건입니다. 소프트웨어를 이해하기가 더 쉬워지니까 나중에 수정하게될 다른 개발자에 대해 고려하지 않은 문제의 코드들이 있을때 리팩토링을 실시하면 코드는 더 파악하기 쉬워진다. 이렇게 리팩토링은 제대로 실행되지만 구조가 완전하지 못한 코드에 대해 실시하는것이 좋습니다. 버그를 찾기 쉬워지니까 (코드를 파악하기 쉬우면 버그 발견도 쉬워진다) 프로그래밍 속도가 빨라지니까 (설계 개선, 가독성 향상, 버그 감소 등은 코드의 질을 높여주는 요소있는데 이런 품질 향상요소를 생각하지 않을 때 잠깐 속도가 빠를수 있어도 새기능을 추가 하거나 버그 찾기에 많은 시간을 낭비할수도 있고 시스템을 이해하고 중복 코드를 찾아 수정 하는 시간이 길어질수도 있습니다.
- 리팩토링은 어떨 때 필요한가 리팩토링은 따로 시간을 정해서 하면 안되고 일상적으로 틈틈이 해야 한다. 작업을 시작할때 리팩토링을 실시하면 그 작업이 쉬워질수 있을때 같은 작업의 삼진 아웃때 어떤 작업을 할땐 그냥하고, 비슷한 작업을 두번째 해야 할땐 중복작업이라좀 망설여져도 일단 그냥하고 세번째 하게 되면 그때 리팩토링을 실시하는 것이다.
- 기능을 추가 할 때 새기능을 넣기전 코드를 이해하기 쉽게 만들면 코드를 다시 볼때를 대비할수도 있지만 코드를 깔끔하게 만드는 과정에서 더 깊이 이해하게 된다 설계가 지저분해서 어떤 기능을 추가하기 힘들 떄다 코드를 이런 식으로 설계했더라면 이 기능을 추가하기 쉬웠을 텐데 라고 생각 할떄 버그를 수정할 때 코드의 기능을 파악하려다 이해하기 힘들면 이해하기 쉽게 만들려고 리팩토링을 실시한다. 코드를 검수할 때 리팩토링을 하면 다른 사람이 개발한 코드를 검수하기도 쉬워진다.
- 리팩토링의 효용성 프로그램이 진닌 가치 현재의 기능 미래의 기능 과거의 판단이 현재를 기준으로 불합리하다는 사실을 발견했다면 그 판단을 수정해야 한다 그래야만 현재의 작업을 할수 있다
- 프로그램의 4가지의 수정하기 힘든 상황 코들를 알아보기 힘들 때 중복된 로직이 들어 있을 때 추가 기능을 넣어야 해서 실행 중인 코드를 변경해야 할 때 조건문 구조가 복잡할 때 프로그램은 코드를 알아보기 쉽고, 모든 로직이 한 곳에 있으며, 기존 기능을 건드릴 필요 없이 조건문 구조가 최대한 간결하게끔 작성해야 한다.
- 팀장에게 어떻게 말을 꺼내나. 기술 검수를 하면 버그가 줄고 그만큼 개발 속도가 빨라진다는 사실이 수많은 연구로 밝혀졋다 검수 주석을 코드에 넣는 방식으로 리팩토링을 유도한다 일정이 빠듯할 땐 리팩토링 애길 꺼내지 말고 몰래 실시하자. 새 기능을 추가해야 하는데 설계를 수정하기 힘들때는 먼저 리팩토링을 실시하고 나서 기능을 추가하는 것이 빠르다.
- 리팩토링 관련 문제들 데이터 베이스 데이터베이스 스키마와 강력히 결합되어 있어 데이터베이스 수정이 어려워진다 . 더이터베이스 이전문제(시간, 위험성)
- 인터페이스 변경 리팩토링 기법이 배포 인터페이스를 건드릴 경우 개발자는 적어도 그 인터페이스를 사용하는 부분이 인터페이스 변경에 맞춰 수정되기 전까지는 기존 인터페이스와 새 인터페이스를 모두 그대로 유지시켜야 한다 .
- 리팩토링을 어렵게 하는 설계를 수정하는 일 설계에 대한 결정이 나중에 바뀌었을 때, 수정하기 힘들 것 같은 민감한 부분일 때 프레임 워크 선택이라든지 연동 기술 선택 같은 특정 설계적 판단을 배제한채 리팩토링 공정은 어렵긴 해도 분명 가능하다 . 등 거의 모든 경우 리팩토링으로 해결 된다.
- 리팩토링하면 안 되는 상황 기존 코드가 지극히 지저분해서 리팩토링은 가능하지만 차라리 완전히 새로 작성하는게 더 쉬울 때 코드가 돌아가지 않는다면 그건 완전히 새로 작성하라는 신호다 . 일정이 임박했을 때 리팩토링은 삼가야 한다.
- 리팩토링과 설계 사전 설계 방식 개발하기전 설계를 고려하면 비용이 많이 드는 재작업을 하지 않아도 됨 사전 설계 없이 리팩토링만 하는 방법도 문제는 없지만 작업에서 가장 효율적인 방법은 아니다.
- 리팩토링의 유래 유능한 프로그래머들은 깔끔한 코드가 복잡하고 정신 없는 코드에 비해 나중에 수정하기 편하는 것을 경험을 통해 알고 있다 초반부터 깔끔한 코드를 작성하란 거의 불가능하드는 것도 알고 있다 리팩토링은 코드를 깔끔하게 만드는 것 이상의 순기능을 한다. 리팩토링은 소프트웨어 개발 과정의 핵심 요소
- 구린내들 중복 코드 똑같은 코드 구조가 두 군데 이상 있을 때는 그 부 분을 하나로 통일하띤 프로그램이 개선된다 장황한 메서드 기능을 한눈에 알 수 있는 메서드명을 시용하띤 그 메서드 안의 코드를 분 석히-지않이도된다. 방대한 클래스 기능이 지나치게 많은 클래스에는 보통 엄청난 수의 인스턴스 변수가 들어 있다. 클래스에 인 스턴스 변수가 너 무 많으면 중복 코드가 반드시 존재하게 마련이다. 과다한 매개변수 객체를 사용할 때는 메서드에 필요한 모든 데이터를 전달하는 게 아니라 그 모든 데이터를 가져올 수 있는 메서드만 전달하면 된다 수정의 산발 수정의 선발은 한 클래스가 다양힌 원인 때문에 다양한 방식으로 지주 수정될 때 일어난다. 기능의 산재 수정할 때마다 여러 클래스에서 수많은 자잘한 부분을 고쳐 야 한다띤 이 문제를 의심할 수 있다. 잘못된 소속 소속이 잘못된 메서드 는 더 많이 접근히는 클래스에 들어가는 것이 마땅하니 데이터 뭉치 몰려 있는 데이터 뭉치는 객체로 만들어야 한다. 강박적 기본 타입 사용 다른 언어에선 기본 타입으로 존재히는 문자열과 날짜가 자바에선 클래스로 존재한다. Switch문 switc h 문의 단점은 반드시 중복이 생긴다는 점이다 문제점을 해견할 수 있는 최상의 방법은 객체지향 개년 중 하나 인 다형성， 즉 재정의를 이용하는 것이다. 평행 상속 계층 클래스의 하위클래스를 만들 때마다 매번 다른 클래스의 하위클래스도 만들어야 한다. 서 로 다 른 두 상속 계층의 클래스명 접두어가 같으면 이 문제를 의심할 수 있다. 직무유기 클래스 하나의 클래스를 작성할 때미-다 유지관리와 이해하기 위한 비용이 추가된다. 따라서 비용만 큼의 기능을 수행하지 못하는 비효율적 클래스는 없애야 한다 막연한 범용코드 코드를 알아보고 유지보수하기가 더 어려워진다. 임시필드 어떤 객체 안에 인스턴스 변수가 특정 상햄l서만 할당되는 경우가 간혹 있다. 개발자는 객체 가 그 안에 들어 있는 모든 변수를 이용하리라 생각하기 마련이므로 이런 코드는 파ξ녕}기 힘 들다. 메시지 체인 메시 지 체인은 클라이언트가 한 객체에 제 2의 객체를 요청하면 제 2 의 객체가 제 3 의 객제를 요청하고， 제 3 의 객체가 제 4의 객체를 요청하는 식으로 연쇄적 요청이 발생하는 문제 점을 뭇 한다 과징 중개 메서드 어떤 클래스의 인터페이 스를 보니까 그 안의 절반도 넘 는 메서드가 기능을 다른 클래스에 위임하고 있다 지나친 관여 클래스끼리 관계가 지나치 게 밀접한 나머지 서로의 은밀한 부분을 알아내느라 과도한 시간을 낭비하게 될 때가 있다. 인터페이스가 다른 대용 클래스 기능은 같은데 시그너처가 다른 메서드에는 메서드명 변경 Hename MethαU25쪽을 실시해야 한다 미흡한 라이브러리 클래스 라이브러리 클래스를 원한 기능을 수행하게 수정하 는 것이 보통은 불가능하다는 것이다. 데이터 클래스 데이터 클래스는 펼드와 펼드 읽기 /쓰기 메서드만 들어 있는 클래스다. 그런 클래스는 오로지 데이터 보관만 담당하며， 거의 대부분의 구체적 데이터 조작은 다른 클래스가 수행한다 방치된 상속물 하위클래스는 부모 클래스의 메서드와 데이터를 상속받는다. 그런데 그렇게 상속받은 메서드 나 데이터가 하위클래스에서 더 이상 쓰이지 않거나 펼요 없을 땐 어떻게 될까? 그럴 경우 하 위클래스는상속물을 전부 받아그 중에서 필요한 것 외엔 방치해버리는문제가생긴다 불필요한 주석 엄청난 양의 주석이 달린 코드를 보 면 그 주석들이 해당 코드의 구린내를 가리기 위해 존재하는 경우가 상당히 많다 우선 리팩토링을 실시해서 온갖 구린내를 없애야 한다. 대체로 리팩토링을 마친 후에야 그 주석들이 불필요한 것이었다는 사실을 알게 된다.