플래시로 개발하기 시작하면서 이태까지 경험하면서

실제로 책이나 블로그에서는 잘 가르쳐주지 않는 사실들을 가끔 깨달을 때가 있다.

그중에서도 내가 가장 크게 깨달았고

플래시 프로그래밍을 공부하는 분들께 도움이 되었으면 하는 바람에서

몇 가지 숨겨져있는 사실들을 이야기해보겠다.



1. 클래스는 대부분 재사용되지 않는다.

OOP가 플래시에서도 뜨거운 감자로써

기본 소양처럼 널리 공부되고 있다.

OOP의 원칙은 두 가지.

바로 재사용성과 확장성.

하지만 실제로 플래시 개발이 고도화되고 복잡해질수록

클래스가 재사용되는 일은 매우 드물다.

오히려 프레임웍으로 만들어 프레임웍 자체가 재사용되면 되었을까

프로젝트에서 만들어진 클래스의 대부분(특히 UI관련)을 재사용되지 않는다.

클래스를 만들때는 각종 OOP기법과 디자인 패턴을 적용하여

최대한 재사용되고 확장될 수 있도록 만들려고 애를 쓴다.

하지만 정작 새로운 프로젝트와 새로운 모듈을 만들때는

그 프로젝트만의 특성이 있기 때문에 결국 새로운 클래스를 만들게 된다.

재사용되는 클래스는 완전 프로젝트와 분리될 수 있는 각종로더나 문자열 관련 유틸, 숫자 연산같은

유틸성이 대부분이다.

프로젝트를 진행하면서 앞으로도 재사용될 수 있는 클래스를 바로 바로 만든다는 것은

경력 8, 9년차정도 되어야 가능한 일이라고 본다.

프로젝트를 진행하면서 클래스를 재사용하려고 너무 시간을 허비하는 것 보다

일단 어떻게든 돌아가게 개발하고 그것을 리팩토링하는게 5배이상 프로그래밍 실력 향상에 도움이 되리라 믿는다.

Do First, then Fix After.

먼저 어떻게든 돌아가는 프로그램을 짜고

마음에 안들거나 바꿔야하는 부분이 생기면 그때 바꾸는게 훨씬 효율적이며

결과적으로도 더 깔끔한 컴퍼넌트가 나오는 걸 경험할 수 있다.



2. 디자인 패턴은 약보다 독이 될 경우가 훨씬 더 많다.

미친 소리로 들릴 수도 있겠지만

디자인 패턴은 실제로 경력 4, 5년차 미만의 플래시 개발자의 경우

득보다 독이 되는 경우가 훨씬 많다.

디자인 패턴은 어떤 패턴 한 두개가 핵심이 되는게 아니라

아키텍쳐의 한 부분을 가지를 쳐내다보면 디자인 패턴으로 보이는것이지

디자인 패턴이 모여서 아키텍쳐가 되는게 절대 아니다.

디자인 패턴이라는 개념 자체가

굉장히 많은 프로그래밍 경험을 토대로

이런 이런 상황에서는 이런 이런 식으로 해서 쓰니까 좋"더라"라는

경험의 축적으로부터 나온 것이기 때문에

그 경험이 충분치 않은 개발자들에게 디자인 패턴은

초등학생에게 철학을 가르치는 것과 마찬가지다.

디자인 패턴을 공부하고나서 중독증상으로

자기 앞의 모든 코드를 모두 패턴이라는 이름하에서 코딩하려고 하는 디자인 패턴 초입자들은

대부분 자기가 원래 개발할 수 있는 시간보다

세배 네배, 심지어는 아예 개발을 못하고 멈춰버리는 수가 많다.

프로그래밍은 코드 자체가 의미있는게 아니다.

프로그래밍은 만들고자하는 것을 쉽게 만들어주는 도구이지

코드를 얼마나 이쁘게 짜는지가 프로그래밍이 아니라는 뜻이다.

까짓거 한글 변수면 어떻고, 4중 for문이면 뭐 어떻나...

for 문 좀 많이 썼다고 프로젝트가 망하는거 아니다.

디자인 패턴은 무의식중에 코드를 무지막지하게 써내려가다가

손끝에서 알아서 나올때 그게 유용한 디자인 패턴인 것이다.

이 모든 사설을 다 빼고 이렇게 한 문장으로 말할 수 있을것이다.

"디자인 패턴은 공부하지 않아도 경력이 쌓이면 알아서 익혀지게되는 것들이다."



3. Flash는 느리지 않다.

HTML5가 이끈 퍼포먼스에 대한 Flash 이슈들에 대해서 많이들 들어봤을 것이다.

"Flash is sucks"라는 말까지 듣는 상황이다.

플래시가 느리다는 대부분의 이유는 바로

대부분의 플래시는 Display 관련 처리가 많고

거기다가 엉망으로 짠 플래시들은 대부분 이미지를 대량으로 최적화 없이 싣고 있기 때문이다.

사실 enterFrame이나 single-thread 여서 느린것도 있다.

하지만 "대부분"의 경우에는 이미지를 무지막지하게 쓰거나 벡터나 동영상들을

최적화 없이 마구 돌리기 때문이다.

실제로 Flash는 virtual machine 위에서 돌아가기 때문에

기본 연산이나 반복문, 바이너리 처리는 굉장히 빠른편이다.

물론 C나 Java에 비할바는 아니겠지만

적어도 Flash is Sucks라는 말을 들을 정도까진 아니다.

HTML이나 Javascript는 아예 비교할 가치도 없을 뿐더러 ShockWave나 Unity(3D기능 빼고 ㅋ)에 비해서

결코 뒤지는 퍼포먼스가 아니라는 이야기다.

int 대신 Number를 쓰면 메모리 많이 먹는다고 걱정하거나

클래스가 너무 많아서 고민이라거나

이미 로드된 swf를 사용하지 않으면 어떻게 unload 해야할지 발을 동동구르거나

하는 걱정들은 솔직히 프로젝트에 아무 영향 없을 때가 훨씬 많다. (사실 대부분이다.)

for 문이나 메모리 때문에 플래시 개발이 막히는 경우는 거의 없다.

게임이나 모바일, 미디어 관련 프로젝트에는 중요하겠지만

게임도 대부분의 미니게임에서는 메모리나 for 문 한두개, 클래스 1, 200개 정도로 문제가 되진 않는다.

Flash는 여러분의 생각보다 충분히 빠르며

이 역시도 마찬가지로 일단

Do First, then Fix After, 일단 만들어보고 문제가 된다면 그때 고쳐도 충분하다.



4. Frame Script는 의외로 좋다.

ActionScript 3.0이 나오고 나서

Frame Script가 죄악시되는데

Frame Script는 fla안에 코드가 있어서

UI와 개발이 분리되는 개발환경일 때 코드가 일원화 되어 있지 않다는 문제가 있을 뿐이지

Frame Script가 느리거나 절대 쓰면 안되는 그런 죄악은 아니다.

프로그래밍이라는 의미자체가

반복작업을 줄여주고 인간의 사고를 최대한 효율적으로 기계어로 풀어내는 것일진데

UI에 붙어있는 짧은 코드 한줄은

클래스 수십개를 능가하는 효율을 발휘할 때가 있다.

가령 예를 들자면

마지막 프레임에 넣어놓은 stop() 구문을 굳이 따로 개발한다면

어떻게 개발할건가?

솔직히 난 Frame Script를 쓰지 않고는 잘 방법이 떠오르지 않는다.

this.addFrameScript( stop, this.totalFrames - 1 ); 이거 말고는 생각이 나지 않는다.

적절히, 다른 클래스들에게 영향을 끼치지 않는 한에서는

Frame Script는 개발 편의성 측면에서 한 점의 화룡정점이 될 수 있다는 것을 잊지 않았으면 한다.



5. Event 구조는 매우 안좋은 기능이다.

특히 Display List에서 Dispatch - Listen 구조는

정말 최악중에 최악이다.

Event의 장점은 단 하나다.

SRP - Single Responsibility Principle

바로 클래스를 캡슐화하는데 있어서 내부의 상황을 바깥으로 알리는데 드러내지 않고 구현할 수 있기 때문이다.

하지만 Display List에서의 이벤트는 너무 느리다.

특히 child 구조가 복잡해질수록 event의 전달과정은 느리기 짝이 없다.

그중에서도 가장 나쁜 이벤트 방식은

내부에서 이벤트를 받아다가 다른 이벤트를 새로 작성해서 바깥으로 보내는 경우다.

btn.addEventListener( "click", clickListener );

function clickListener( $e: MouseEvent ): void
{
    this.dispatchEvent( new Event( "merong" ) );
}

Display List에서 마우스 이벤트는 전달되는 과정이 생각보다 매우 복잡해서

메모리 뿐만 아니라 속도도 매우 느리다.

이는 작은 프로젝트에선 모르다가 이벤트를 맹신하고 마음놓고 쓰기 시작하면서부터 경험할 수 있는데

이를 경험하고 나서 부터는 반드시 필요한 때가 아니면

주로 callback 방식으로 바꿔서 쓰고 있다.

Event는 클래스를 캡슐화하는데 있어서 탁월한 기능이 있지만

Display List 구조에서는 생각보다 굉장히 느리다는 단점이 있다는 것을 반드시 기억해야한다.



블로그에 포스팅하면서 처음쓰는 네거티브한 내용의 글인것 같은데

그만큼 너무 부풀어 있는 거품을 좀 걷어내어야 할 필요성을 느꼈고

실제로 크고 작은 개발을 해보면서 느낀 바를 옮겨적어보았다.

옳다 그렇다의 이분법적인 이야기를 하려하기보다는

책이나 포스팅에서 너무 이론적인 접근만 하는

공부보다 실제 개발을 할 때 도움이 되었으면 하는 이야기들이라고 생각했다.

혹시 다른 생각을 가진 분이 계시면 꼭 댓글을 달아주었으면 한다.

:D

+ Recent posts