마틴 파울러, Martin Fowler 의 [Refactoring]

 > 리팩터링 바이블 내지는 고전으로 여겨지는 Refactoring 이라는 책의 저자이다.
마틴 파울러가 정의하는 많은 표현들이 현재까지도 사용되고 있으며 한글번역판도 나와있으며
난 아직 안봤지만 매우 좋은 책이다. -_-?

GoF, The Gang of Four

 > 마틴 파일러의 [Refactoring]이 리팩터링의 바이블이라면 디자인 패턴은 GoF 가 바로 그렇다.
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides 이 네명이 한 건축가가 건축물을 만드는데에 대해서 몇가지 패턴을 설명한 글을 토대로 객체지향개발에 적용하여
몇가지 패턴을 만들어 냈습니다. 그들을 기리는 말로 The Gang of Four 라고 합니다.
흔히 "GoF 의 디자인패턴인 무엇무엇" 이라고 표현합니다.

진흙 구덩이의 공, Big Ball of Mud

 > "고장나지 않는 것은 고치지 않는다." 라는 관행 때문에 그때 그때 발생하는 버그와 수정만 처리해버리고 말아버리기 때문에 시간이 갈수록 수정작업은 걷잡을 수 없이 커지며
그에 드는 시간은 기하급수적으로 커지며 돌이킬 수 없는 지경까지 이르는것을
진흙 구덩이의 공 즉, Big Ball of Mud 라고 표현한다.
Brian Foote 와 Joseph Yoder 에 의해 만들어진 표현이다.

캡슐화, Encapsulation, Encapsulate

 > 클래스가 자신의 역할을 외부에 영향을 받지 않도록 설계하는 것을 말한다.
예를 들면 XMLLoader 라는 클래스를 만들면 xml 을 로드하기 위해서 코드에서는 URLLoader 라던지 IOError 같은 것을 신경쓰지 않도록 만들어야 한다는 이야기다.
예를 들어
var loader:XMLLoader = new XMLLoader();
loader.addEvent(XMLLoaderEvent.COMPLETE, xmlLoadComplete);
loader.load("sample.xml");
와 같이 로드하라는 명령을 내리고 그 응답만 기다린후에 사용하면 되는것이다.
이렇게 자신이 하는 일을 클래스 내부로 숨겨서 밖에서 알지 못하고 영향을 받지 않도록 하는 것을 캡슐화, Encapsulation 이라고 한다.

추상, Abstract

 > 이 키워드 역시 플래시에서 많이 생소한 단어다.
플래시는 추상클래스나 추상메소드를 지원하지 않기 때문에
추상클래스를 사용하려면 "마치 추상클래스인것 처럼" 사용하는 수 밖에 없다.
때문에 그 활용도 때문에 비슷하게 구현하여 사용하긴 하지만
추상이라는 의미는 "실제적인 구현"이 아닌 "어떤 역할을 할것이다." 라고 정의해주는 역할을 말한다.
예를 들어 Sonata, Avante, Tico 라는 클래스가 있다고 하면
Car 라는 추상클래스를 만들어 accelate(), break(), openTrunk() 같은 기본적인 메소드를 만들어 놓을 수 있는 것이다.
왜 "추상"이라는 단어를 붙이냐면
추상클래스의 메소드를 추상메소드라고 하는데
추상메소드는 상속하여 구현하지 않고는 동작할 수 없기 때문이다.
왜냐면 "어떤 역할을 할것인지 정의만" 내려주지 실제로 어떻게 동작할지에 대한것은 코드에 포함되어 있지 않다.
코드상으로는
abstract class Car...
라고 하며 추상메소드는
abstract function accelate():void
라고 한다.

클라이언트, Client

 > 물론 고객을 뜻하기도 하지만 리팩터링이나 디자인 패턴에서는
주(主)가 되는 코드와 그 코드를 구성하는 객(客)으로 그 역할이 나뉜다.
이는 절대적인 관계가 아니라 상대적인 개념이며
아래 예를 통해서 살펴보자.

class Uploader extends Sprite...
public function upload():void
{
    this.uploader = new FileUploader();
    this.uploader.file = this.data;
    this.uploader.upload()
}

class FileUploader...
public function upload():void
{
    private var reference:FileReference;
    public function upload():void
    {
        this.reference.load(this.request);
    }
}

Uploader 는 upload 라는 메소드를 통해서 FileUploader 클래스의 upload() 를 실행시키고
FileUploader 내부에서는 FileReference 를 이용하여 업로드를 한다.

여기서 FileUploader 의 입장에서는 자신이 FileReference 를 참조하든 Loader 를 참조하든
Uploader 클래스에게 알리거나 연관될 필요가 없다.
때문에 FileUploader 에게 Clinet 는 Uploader 가 된다.
반대로 FileReference 입장에서는 FileUploader 가 클라이언트가 된다.

이런 주와 객의 입장을 설명할때 클라이언트 코드, 또는 클라이언트라고 표현한다.

짝 프로그래밍, pair-Programming

 > 두명의 개발자가 하나의 코드 또는 클래스를 더 나아가 소프트웨어를 만드는 것을 말한다.
이 용어가 중요한 것은 짝 프로그래밍을 하려면 디자인패턴에 대한 용어정의와
서비스 지향적인 개발방법이 명확하게 정의되어 있어야하며
서로간의 개발 수준이 비슷해야하고 고도의 협업력이 필요하기 때문이다.
즉, 무지 수준높은 프로그래밍이라는 이야기다^^

코드속의 나쁜 냄새, Bad Smells in Code

 > 마틴 파울러는 좋지 못한 설계나 수정에 대한 어려움이 예상되는 몇가지 징후들(냄새표)을 일컬어
코드속의 나쁜 냄새 즉, Bad Smells in Code 라고 표현하였다.
이 냄새표는 나중에 따로 다루도록 하겠다.

 * 사전적 정의가 아닌 Flash 개발자의 시각에서 바라본 해석입니다.

디자인 패턴, Design Patterns

 > 코드를 구조적이고 체계적으로 완성도 높게 개발하기 위하여 보다 효율적인 방법으로 프로그래밍을 하는 여러가지 방법들.

리팩터링, Refactoring

 > 기존의 코드를 이해도가 높고 수정, 보완에 효율적이도록 기능은 그대로인체 내부 구조를 변경하는 작업을 말한다.

XP, eXtreme Programming

 > 표현이 참 재미있는 용어다. 다양한 변경사항과 뛰어난 코드 가독성, 모든 메소드의 테스트가능화, 매우 높은 관리도를 지향하는 "극"적으로 뛰어난 효율성을 갖춘 프로그래밍을 일컫는다.

Agile 방법론

 > Agile 은 "기민한, 민첩한" 이라는 뜻이다. 이는 매우 복잡하고 극변하는 요구사항과 새로운 기능을 재빠르게 수용하고 적용할 수 있도록 개발하는 것을 말한다.
 디자인패턴을 효율적으로 사용하고 서비스지향적으로(SOA) 구조를 잡아 개발을 하게 되면
다양한 요구사항을 빠르고 안정적으로 적용할 수 있다라는 뜻으로 이해해도 된다.

서비스 지향 설계, SOAP, Service-Oriented Architecture Programming

 > 넓은 뜻으로는 서비스 지향 개념을 바탕으로 소프트웨어 시스템을 구축하려는 의도 자체를 의미한다.
하지만 좁은 뜻으로는 확장이 용이하고, 재사용이 가능하며 변화와 필요에 따라 능동적으로 변화를 취할 수 있는 소프트웨어 개발방법론이라고 하겠다.
매우 추상적이고 광범위한 의미이며 작게는 개발방법론, 크게는 IT의 흐름 전체를 정의할때 주료 사용되는 용어다.

상속하다. extends

 > 많이 쓰는 용어라 이게 왜 중요한가 하겠지만
한국에서는 상속하다 라는 의미가 반대로 사용되고 있다는 사실을 아는가?
class MovieClip extends Sprite
이 구문을 국내 개발자는 "Sprite 를 상속받아 MovieClip 을 만든다" 라고 표현한다.
이는 명백히 잘못된 표현이며 "MovieClip 은 Sprite 를 상속한다" 가 맞는 표현이다.
무슨 차이냐면 주객이 전도가 되었다는 뜻이다.
MovieClip 의 관점에서 Sprite 클래스를 상속하는것이다.
즉 MovieClip -> Sprite 로 표현하는게 맞는 뜻이다.
한국식 표현으로 계속 표현해오다가 UML 을 공부하면 무지하게 헷갈렸던 부분이다.
즉 "A 가 B 를 상속한다." 라는 표현은
A extends B 라는 뜻이다.
용어의 통일은 매우 중요한 일이다. 헷갈리지 말자.

구현하다. implements

 > 아무렇지도 않게 통념적으로 쓰이는 말이지만 추상적인 interface 를 implement 하여 클래스를 만드는 작업을 표현할때는 "구현하다" 라는 표현이 가장 적당하다.
때문에 이 용어를 정의하지 않고는 class A implement B 를 표현하기가 매우 난감하다.
구현이라는 의미 자체가 아직 실체화되지 않은 것을 실체화하는 작업을 뜻하기 때문이다.
그래서 야꼬는 구현하다라는 용어를 정의하여 쓰기를 권한다.

UML, Unified Modeling Language

 > 플래시는 아직 레퍼런스가 많지 않아 아직 UML이 널리쓰이지는 않고 있다.
이미 C나 Java 진영에서는 거의 기초소양 수준으로 쓰이고 있다.
Three Amigo라는 애칭으로 불리는 Grady Booch, James Rumbaugh, Ivar Jacobson 이 세명이 창시자이며
UML 은 객체와 객체와의 관계, 프로세스의 흐름, 클래스들관의 상속관계나 의존관계등과 같은 Model의 연관관계를 표현하기 위해 만들어진 표준 언어다.
여기서 중요한것은 UML 이 Language 라는 것이다.
즉, 정해진 언어이기 때문에 배우지 않으면 이해할 수 없다는 뜻이다.
도형이나 선, 모양이 다 각기 뜻을 가지고 있으며 무엇을 보여주는 그림인지에 따라 그 의미와 표현이 달라지기 때문에 반드시 공부를 해야한다.
UML 은 현재 2.1까지 나와있는 상태며
Flash 에서 사용할 수 있는 UML 툴은 내가 알기로는 Enterprize Architect 밖에 없는걸로 안다.
(이거 제대로 물건이다 -_ㅡ^ 초강츄)

요즘 한창 Refactoring 과 Design Patterns 을 공부하고 있다.

듣기는 많이 듣지만

사실 리팩터링과 디자인패턴이라는게 살갑게 와닿지 않았던게 사실이다.

뭐 예를 들어 "Barney 공식" 이라하면 어떤 소스고 어떻게 하는지 와닿지만

"컴포즈 메소드", "팩터리 패턴" 이라고 들으면 뜬구름인 마냥 대충 알겠지만

머릿속에 코드가 떠오를 정도로 와닿지는 않았다.

하지만 지금 읽는 책이 "Refactoring to Patterns" 인데 살갑게 와닿는 내용이 많다.

그래서 공유하고자 이렇게 키보드에 손을 얹었다^^

매우매우 원시적이며 이해하기 쉬운 살에 닿는 방식으로 설명하겠다.



우선 가장 기초적으로 리팩터링이란것이 무엇인지 알아보자.

Re-factoring 은 이미 진행되고 있는 프로젝트 중간에 투입되어 선임자의 코드를 이어 받는 경우와 이미 완료된 프로젝트를 수정 또는 보완하는 작업을 통상적으로 일컫는다.

간단하게 말해서 이미 잘 돌아가고 있는 코드를 분해해야 한다는 의미다.

극단적으로 간단한 예를 들어보자.

 - 원본 소스

소스 보기

 - Compose Method 패턴을 이용한 리팩토링

소스 보기

리팩터링의 동기, 즉 리팩터링을 하게되는 계기는 진행중이 프로젝트에 투입되거나

수정, 보완의 목적으로 기존의 코드는 변경하는것을 말한다.



리팩터링의 궁극적인 목표는 코드를 보다 이해하기 쉽게하고

예상 가능한 변동사항에 대비할 수 있도록 코드를 변경하는것이다.

첫번째 소스처럼 코드가 되어 있다면 CustomData.value 라는 파라미터가

String 에서 int 로 변경되었다면 저 조건문이 쓰인곳을 모조리 찾아가 바꿔야하는

난처한 상황에 부딪힌다.

하지만 Compose Method 패턴을 이용해

null 임을 체크해주는 checkNull 메소드를 제공함으로써

value 의 값이 널인지 아닌지 체크하는 부분은 checkNull 메소드부분만 변경하면 되는것이다.

이것이 바로 리팩터링을 하는 궁극적인 목표인것이다.