2011년 5월 26일 목요일

Prefactoring

Prefactoring
Refactoring 외부로 노출되는 기능은 변경하지 않고 코드의 내부 구조를 개선하려고 코드를 바꾸는 기법이다. Prefactoring 다른 사람의 경험뿐만 아니라 개발자가 소프트웨어를 개발하면서 얻은 통찰력까지 활용한다.

Prefactoring 극단적인 기법
1.     극단적인 추상화
2.     극단적인 관심상항 분리 : 서로 다른 클래스와 메서드, 그리고 변수들 간의 책임을 나누는 작업
3.     극단적인 가독성 : 고객이나 소비자가 코드를 읽을 있을 정도
Item 1 : 시스템 내의 개념들을 분명하게 정의한 이름을 만들어라
동일한 이름을 갖는 개념은 혼란을 야기할 있다. 개념을 개의 이름으로 구분함으로써 요구 사항이 이해하기 쉬워진다.
Item 2 : 결합된 것을 분할하는 것보다 분할된 것을 결합하기가 쉽다.
개의 독립적인 개념을 갖고 있는지 아니면 하나의 개념을 갖고 있는지를 판단하기가 어렵다면 이름을 사용한다. 중에 언제든지 이름을 동의어로 선언할 있다.
Item 3 : 생각할 대상을 줄이기 위해서 데이터를 클럼핑하라
클럼핑은 여러 특성들을 하나의 이름을 갖는 개념으로 결합하는 것이다. 이때 특성들은 전체적으로 유기적이 형태를 띠어야 한다. 결합은 하나의 이름으로 서로 다른 개념을 나타내는 것이다.  클럼핑은 데이터 집합을 효율적으로 기술하기 위한 추상화 기법이다.
Item 4 : 추상화를 하려면 끝까지 추상화하라
기본 제공 데이터 타입을 사용해 데이터 항목을 기술하지 마라. 추상화된 데이터 타입을 사용하면 타입이 어떻게 표현되는지가 아닌 타입으로 무엇을 처리할 있는지에 집중할 있다.
Item 5 : 상수가 코드에 포함되지 않도록 하라
모든 값에 대해서 기호 이름을 사용하라. 상수를 Xml구성파일이나, 데이터베이스 또는 다른 형태의 저장소를 사용하라.
Item 6 : 프로토타입은 천마디 말과 같다.
화면과 같은 인터페이스에 대한 그림이 단순한 설명보다 훨씬 강력하다.
Item 7 : 그림에 대해서 생각하라
대부분의 성공적인 시스템은 아키텍처에 대한 하나의 비전을 갖고 있다. 비전은 그룹의 합의나 신임을 얻고 있는 누군가로부터 만들어진다. 시스템 내의 설계에 대한 결정은 반드시 아키텍처와 일치해야 한다. 그림은 시스템의 전반적인 아키텍처와 사업 목표를 포함한다.
Item 8 : 인터페이스 계약 만들기. 명확하게 정의된 인터페이스를 설계한 인터페이스들에 대한 계약을 강요하라.
호출된 메서드는 선행조건(메서드가 작업을 수행하기 위해서 메서드가 호출될 당시 반드시이어야 하는 조건) 대한 대부분의 정보를 포함한다. 만약 성능에 영향을 끼치지 않는다면, 호출된 메서드가 모든 선행조건들을 검사한 , 조건을 만족하지 않을 에러 알림 메커니즘을 통해서 보고한다.
Item 9 : 코드로 의사소통을 하라. 작성한 코드는 목적과 의도를 말할 있어야 한다.
코드는 반드시 목적과 의도를 말할 있어야 한다. 다소 과장된 표현이긴 하지만, 적어도 어느 수준에서는 코드를 책처럼 읽을 있어야 한다. 고객은 코드를 보고 코드가 자신이 요구 사항에 표현한 논리를 따르고 있는지 이해할 있어야 한다.
Item 10 : 의미 있는 메시지를 사용자에게 보고하라. 에러 메시지는 내부적인 에러가 무엇인지가 아닌 사용자가 에러에 대해서 무엇을 잇는가에 대한 상황에 맞게 보고 돼야 한다.
이탈과 에러 때문에 사용자에게 보고할 메시지는 반드시 사용자에게 의미가 있어야 한다. 에러를 저지하거나 수정할 잇는 방법에 관한 충분한 정보를 제공해야 한다.
Item 11 : 크게 계획하고 지역적으로 개발하라 점증적인 구현은 전체적인 계획에 맞아야 한다.
Item 12 : 테스트 없다면 요구하지도 말라. 모든 기능테스트 요구사항은 그것이 공식적으로 또는 비공식적으로 기술되었는지에 상관없이 반드시 해당 요구 사항에 대한 테스트를 생성할 있어야 한다. 만약 어떤 요구 사항을 테스트할 없다면, 요구 사항을 만족하는지도 확인할 방법이 없다.
Item 13 : 테스트에 대한 계획을 수립하라. 미리 테스트전략을 세우면 나은 설계를 만들 있다.
Item 14 : 지나치게 클래스로 작성하지 말라. 개념들을 데이터가 아닌 기능에 따라 서로 다른 클래스로 구분하라.
Item 15 : 객체의 3 가지 법치
1.     객체는 메서드가 설명하고 있는 바를 수행해야 한다.
주어진 메서드는 자신이 수행하는 바를 설명하는 이름을 갖는다., 메서드가 이름만 보고도 무슨 일을 하는지 있어야 한다.
2.     객체는 해를 입히지 않아야 한다.
객체는 본분을 지키는 한도에서 필요 이상으로 리소스를 소유해 해를 입혀서는 안된다.
3.     객체는 요청된 연산을 수행할 없는 경우 사용자에게 이를 알려야 한다.
객체는 아무 없이 실패하지 않아야 한다. 만약 호출자가 부적절한 매개 변수를 전달했거나 필요한 리소스를 사용할 없다면 객체는 반드시 연산을 완료할 없음을 알려야 한다.
Item 16 : 용도에 따라서 메서드를 클래스에 추가하라. 만약 메서드가 인스턴스(인스턴스화 객체) 데이터를 필요로 하지 않는다면, 메서드는 해당 클래스의 멤버가 돼서는 안된다. 반대로 만약 메서드가 필요로 하는 모든 데이터가 인스턴스 데이터라면, 메서드는 해당 클래스 멤버가 돼야 한다.
Item 17 : 상속이 아닌 인터페이스를 생각하라. 인터페이스는 클래스간의 관계를 유연하게 만들어 준다.
Item 18 : 구현과 정책을 분리하라. ‘어떻게무엇 분리하면 읽기 쉽고 유지 보수가 쉬워진다. 일을 잘하는 객체를 만들기 위해서는 구현(일을 어떻게 것인지) 포함하고 있는 메서드와 정책(무엇을 것인지) 포함하는 메서드들을 분리해야 한다. 정책 메서드는 어떻한 일을 하기 위한 로직과 근거를 포함한다. 반면 구현 메서드는 세부 사항을 포함한다.
Item 19 : 함수를 오버로드하는 것이 자칫 부담이 있다. 고유한 이름을 사용하면 함수를 설명할 있다.
Item 20 : 관심 사항을 분리해 관심의 크기를 줄일 있다. 메서드와 클래스를 간소화하기 위해서 여러 메서드와 클래스들 간의 책임을 구분하라.
입력이 어떻게 처리되고 검증되는지, 어떻게 보고 되거나 표시되는지에 대한 관심을 구분하면 프로그램을 유지보수하기 쉬워진다.
Item 21 : 테스팅을 위해서 유연성 있게 구현하라. 테스트를 쉽게 하려면 설계할 유연성에 대한 계획을 세워라, 테스트 전용 메서드는 모두 테스트 인터페이스에 포함시킨다.
Item 22 : 연관 클래스로 결합을 없애라. 연관 클래스들은 연관된 클래스들의 결합을 없앤다. 연관 클래스들은 관계와 관련된 데이터뿐만 아니라 객체들이 참조하는 특성들을 포함한다. 연결된 객체들은 전형적으로 서로 다른 클래스들을 나타낸다. 연관 클래스를 사용하면 연결된 클래스의 결합을 없앨 있다.

댓글 없음:

댓글 쓰기

ETL 솔루션 환경

ETL 솔루션 환경 하둡은 대용량 데이터를 값싸고 빠르게 분석할 수 있는 길을 만들어줬다. 통계분석 엔진인 “R”역시 하둡 못지 않게 관심을 받고 있다. 빅데이터 역시 데이터라는 점을 볼때 분산처리와 분석 그 이전에 데이터 품질 등 데이...