[AS3] 좋은 코드를 작성하기 위한 길

Programming/ActionScript 3.0 2008. 12. 27. 11:30
플래시는 에니메이션 저작툴이라는 디자인적인 탄생 배경을 탈피하고 많은 프로그래머들이 매력을 느끼는 컴퓨터 프로그래밍 언어로 발전하였다. 나는 어린 시절 장래 희망을 물어보면 컴퓨터 프로그래머라고 이야기하던 시절이 있었다.(그때는 5.25인치 디스크 한 장에 게임 하나가 들어가던 시절이었는데 아마도 게임을 하면서 스토리를 내 마음대로 바꾸고 싶었던 것 같다.)

하지만 그런 꿈은 삶의 역경 속에서 잊혀지고 나아가 컴퓨터 프로그래머라는 직업이 돈이 되는 직업은 아니라는 것을 알았을 무렵에는 이내 나의 꿈은 컴퓨터 프로그래머가 아니었다고 부정하였다. 결국 부정하던 장래희망의 굴레에 나를 몰아넣은 것은 플래시라고 할 수 있다. 내가 플래시를 처음 접했을 때는 이런 형태로 발전할지는 꿈에도 몰랐었으니 고로 나는 플래시에게 사기를 당한 것이다. ^^


나는 배우는 과정에 서있다. 항상 플래시의 발전을 따라가느라 정신 없이 허우적거리는 생활을 반복하고 있으니 아마도 내가 플래시라는 툴에서 손을 놓을 때까지 이러한 배움의 길은 끝이 없을 듯싶다.

배우는 과정에서 느꼈던 좋은 코드를 작성하는 방법에 대하여 이야기 해 볼까 한다. 본 내용은 일본 잡지에 실린 연재 코너의 내용을 ActionScript 버전으로 본인의 생각을 덧붙여 작성한 것임을 밝혀둔다.

좋은 코드란?
좋은 코드는 조직이나 프로젝트, 프로젝트 메니저에 따라서 그 정의가 다르게 해석될 수 있다. 하지만 보편적으로 좋은 코드로서 바람직한 방향은 있다.

정확하게 동작하는 것.
정확한 결과값을 도출하는 것은 신뢰할 수 있는 코드다.

빠르고 효율적으로 동작 하는 것.
결과 값을 도출하는 방법은 여러 가지가 있을 수 있다. 좋은 코드는 적절한 퍼포먼스로 동작한다.

방어적으로 버그를 생산하지 않는 것.
방어적 프로그래밍 방법론에 기초하여 정상적인 값이 들어 올 것이라고 가정하지 않고 부정확한 값이 와도 문제가 발생하지 않도록 방어적으로 코드를 작성한다. 이것은 처음에 열거한 정확하게 동작하는 것을 도와준다.

유지보수를 하기 쉬운 것.
프로젝트는 단기간에 수명을 다할 수도 있지만 우리가 상상하는 것보다도 길게 생명을 유지하는 것도 많다. 유지보수성을 높이는 것도 좋은 코드에 있어서 중요하다.

다른 사람이 봐도 이해하기 쉬운 것.
현재 작성한 코드를 미래에 자신이 보는 것과 현재 타인이 보는 것은 비슷하다고 볼 수 있다. 미래에 자신이 봐도 이해할 수 있는 코드는 좋은 코드라 할 수 있다.

쓸데없는 부분이 없는 것.
쓸데없는 코드를 작성하는 개발자는 없을 것이다. 다만 코드의 구현과정에서 기능 추가 및 다른 로직과의 연동 과정에서 불필요하게 파생하는 코드들은 지양할 필요가 있다.


좋은 코드를 작성하면 무엇이 좋은가?
좋은 코드는 프로젝트를 추진하고 성공적으로 이끌기 위한 기본적인 요소가 된다. 프로그래밍의 달인들은 심플하고, 유지보수성이 좋고 안정적인 코드를 빠른 속도로 작성한다. 테스트가 어려운 코드를 테스트가 가능하고 검증할 수 있는 코드로 변경함으로써 품질이나 생산성을 수백 배 높이기도 한다. 이것은 프로젝트의 성공에 있어서 큰 요소이다. 물론, 좋은 코드가 있으면 반드시 프로젝트가 성공하는 것은 아니다. 개발 프로세스나 메니지먼트, 커뮤니케이션등으로 좌우되는 경우가 더 많지만 이런 것들을 제외한다면 개발에 있어서 좋은 코드의 힘은 크다고 볼 수 있다.

프로그래머로서의 평가가 높아진다.
좋은 코드를 작성하는 프로그래머는 대체적으로 프로그래머로서 신뢰한다. 프로그래머로서의 평가가 조직으로서의 실제 평가나 이익에 결합될지는 소속하는 조직의 평가 제도나 프로그램 이외의 일도 포함하여 정해지는 것이 현실이다. 그렇다고 좋은 코드를 쓸 수 있는 것이 마이너스 평가로 이어지지는 않을 것이다.

일에 대한 만족감이나 자신감을 가질 수 있다.
두 번 다시 손대고 싶지 않은, 유지보수가 불가능한 코드를 써본 적이 있을 것이다. 이러한 낮은 퀄리티의 일을 해 놓으면 일에 대한 만족감을 얻을 수 없다. 반면 자신의 의지로 적절히 좋은 코드를 작성함으로써 품질이 높고 안정된 소프트웨어를 개발했을 때는 그에 대한 만족감도 높고 자신감을 갖고 일에 임할 수 있다. 앞으로 오랜 시간을 프로그래머로써 살아갈 것이라고 생각한다면 좋은 코드를 쓸 수 있는 레벨을 목표로 하는 것은 합리적인 일이다.

사실 좋은 코드를 작성하기 위해서는 하루아침에 이룰 수 없다. 그렇다면 좋은 코드를 작성하기 위해 구체적으로 무엇을 어떻게 해야 하는지를 살펴보자.

코드 리딩 - 읽어라, 코드를 읽고, 읽고, 또 읽어라.
음악이나 회화, 건축의 세계에서도 자신만의 발상으로 작품을 완성시키는 예술가는 없다. 다른 사람들의 작품을 보고 영향을 받거나 좋은 곳을 훔치거나 해서 자신의 작품을 만드는 것으로 작품을 낳아 왔다.

프로그래밍도 같다. 좋은 코드를 작성 하려면 좋은 코드이건 나쁜 코드이건 간에 다른 사람이 작성한 코드를 평소에 의식하고 읽는 것이 중요하다. 플래시는 특히 많은 오픈 소스가 인터넷에 열려 있기 때문에 다른 사람이 작성한 좋은 코드를 언제라도 부담 없이 읽을 수 있다. ActionScript 중급 정도의 실력자이지만 구조를 어떻게 만들어야 하는지 막막한 분은 특히 주목할 필요가 있다. 이런 단계에 머물러 있는 분이라면 코드리딩을 통해서 한 단계 발전한 자신을 발견할 수 있을 것이다.

코드리딩의 좋은 점은 알아도 코드를 읽는 방법을 모른다면 시작하기 힘든 일이다. 아래의 간단한 코드를 보면서 이야기 해보자.

package classes.data{

    import flash.events.Event;
    import classes.data.*;
    import classes.net.SimpleXMLLoader;
   
    public class DProvider extends SimpleXMLLoader{ // [1] 여기부터
           
        private var _xmlUrl:String;   
        private var _keywords:Array;
       
        public function DProvider(inUrl:String):void { // [2] 여기부터
            _xmlUrl = inUrl;
            addEventListener(Event.COMPLETE, onLoadedXmlHandler);
            loadXML(_xmlUrl);
        }    // [2] 여기까지

        private function onLoadedXmlHandler(e:Event):void { // [3] 여기부터
            var xml:XML = XML(data);
            _keywords = [];
           
            var len:int = xml.item.length();
            for (var i:int = 0; i < len; i++)
            {
                // [4] 여기부터
                _keywords.push(createKeyword(xml.item[i]));
            }
        }    // [3] 여기까지
       
        private function createKeyword(inKeywordNode:XML):KeywordBase
        {
            var keyword:KeywordBase;
            switch(int(inKeywordNode.level)) {
                case 1: keyword = new Keyword1(inKeywordNode);
                break;
                case 2: keyword = new Keyword2(inKeywordNode);
                break;
                case 3: keyword = new Keyword3(inKeywordNode);
                break;
                case 4: keyword = new Keyword4(inKeywordNode);
                break;
            }
            return keyword;
        } // [4] 여기까지
       
        public function get keywords():Array { return _keywords.concat(); } // [5]
    } // [1] 여기까지
}

위 클래스는 본인이 실무에서 작업했던 태그클라우드에서 사용했던 코드이다. 클래스의 기능은 xml데이터를 불러들여 level 노드 값에 따라서 해당 클래스들을 배열로 생성하여 제공한다.

위 클래스 외적으로 사용된 클래스는 다음과 같은 기능을 포함한다.
SimpleXMLLoader : 단순히 xml 데이터를 불러오는 기능을 한다. loadXML 메소드가 포함되어 있다.
KeywordBase : 키워드 무비클립의 기본이 되는 기능을 제공한다. (마우스 다운, 오버, 아웃등)
Keyword1 ~ Keyword4 : KeywordBase 를 상속하는 각 레벨에 따라 디자인이 서로 다른 클래스들

코드리딩을 할 때는 기본적으로 nest 단위로 읽어 내려가면 된다. 중간에 나타나는 다른 클래스들은 현재 블록을 전체적으로 훑어 보면서 유추하도록 하자. 중간에 다른 파일을 열어 읽게 되면 현재 읽고 있는 흐름을 놓칠 수 있기 때문이다.

50줄도 안 되는 코드지만 이 코드만 가지고도 작업된 클래스들의 절반 이상은 이해할 수 있다. 복잡한 기능을 하는 클래스는 아니기 때문에 읽으면서 구조적으로 어떻게 작성이 되었는지 알 수 있을 것이라 믿는다. 이런 훈련을 반복 하다 보면 현재 읽고 있는 클래스 이외의 다른 클래스들도 머리 속으로 그리는 과정을 얻게 된다. 이를 통해서 하나를 보면 열을 알게 되는 경지에 다다를 수 있을 것이다. ^^

구글에서 코드 검색엔진을 통해서 웹에 있는 원시 코드들을 검색할 수 있는 서비스를 제공하고 있다. 자신이 원하는 기능의 클래스명이나 메소드명으로 검색해서 코드리딩 연습을 하는 것도 좋은 방법이다. 또한 많이 알려진 클래스나 패키지들은 구조적으로 잘 설계된 것들이 많이 있다. 구조적인 관점에서는 그런 것들을 분석해 보는 것도 큰 도움이 된다.

http://www.google.com/codesearch
인터넷상에 공개되어있는 Subversion(repository)나 archive파일 등을 기계적으로 빠르게 검색 할 수 있다.

좋은 이름을 붙이자.
우리가 프로그래밍을 하고 있을 때 가장 막히는 부분은 변수명, 메소드명, 클래스명 이름을 붙이는 것이다. 그만큼 좋은 이름을 붙이는 것은 중요하다. 좋은 이름을 붙이는 것이 중요한 이유는 위에서 언급했던 코드리딩에서도 느낄 수 있듯이 관련 기능에 부합하는 좋은 이름을 붙이지 않으면 코드를 읽기가 어려워진다.(생각해보니 위에서 예로 든 코드에서도 어려움을 느낀 분들이 있을 것 같다 ^^;)

그렇다면 좋은 이름의 조건이 있을 법하다.

좋은 변수명, 메소드명, 클래스명은 이름이 그 코드의 내용을 올바르게 나타내고 있다. 그러한 이름은 이름을 보는 것만으로도 코멘트를 읽을 필요도 없이 그 역할을 이해할 수 있다. 좋은 이름은 코드의 이해를 돕지만 나쁜 이름은 읽는 사람을 혼란 시키고 착각을 낳아 버그 발생을 조장한다.

위 코드를 예로 들면 onLoadedXmlHandler 메소드 명을 onComplete로 했을 경우에 어떤 것이 Complete 되었다는 것인지 인지하기 어렵다. 위 클래스의 경우는 단순한 클래스이지만 클래스의 내용이 많고 complete 핸들러 함수를 여러 개 포함하고 있을 경우에는 메소드의 중복이 발생할 수도 있다.

public function get keywords():Array { return _keywords.concat(); }
의 경우에는 keyword에 복수를 뜻하는 s를 붙임으로써 전달 받는 keyword가 하나가 아니라 복수이며 배열이라는 것을 유추할 수 있다. 이 밖에도 아래와 같은 방법이 있다.

어두 이외의 모음을 삭제 (image ->img)
강한 소리를 남긴다. (server -> svr)
약어의 이용 (database -> db)

일관성이 있다.
좋은 이름은 코드 전체에서 일관된 흐름을 가져야 한다.

대칭성을 유지하는 것
begin <-> end
write <-> read
on <-> off

단어의 조합의 일관성
scoreAvg
scoreAverage
avgScore
위 이름은 하나의 클래스에서 중복 사용하지 않을 것.

관용어에 따라서
언어, 프로젝트, 회사나 팀 마다 명명에 관한 관용어(관습)가 있다. 예를 들면 Java의 경우는 메소드명은 소문자로 시작하는 것이 관습이며, C#은 대문자, C++은 멤버 변수에 prefix로 m_를 붙이는 것이 일반적이다. 관용어에 따른 명명은 누가 보더라도 알기 쉬운 이름이라고 이야기 할 수 있다.(ActionScript의 경우는 보통 자바와 언어적 문법이 비슷하기 때문에 자바와 같은 명명 관용어를 사용하는 경우가 많지만 개인적인 취향에 따라 다르게 사용하는 경우가 대부분이다.)

코딩 표준에 따라서
위와 같이 좋은 코드의 조건을 채우기 위해서도 코딩 표준이나 명명 규약을 정해 팀 멤버 전원이 맞추는 것이 중요하다. 작업자 1명이 단기적으로 작업하는 프로젝트에서는 본인이 원하는 규칙을 사용하면 되겠으나 조직의 힘을 바탕으로 얻을 수 있는 큰 프로젝트의 경우는 협업의 중요성이 대두되므로 이러한 코딩 표준을 맞추는 것이 장기적으로는 바람직하다고 볼 수 있다.

좋은 이름을 붙이기 위한 습관
항상 좋은 이름을 붙이는 것을 의식한다.
좋은 이름을 붙이려면 우선 의식적으로 노력을 해야 한다. 이것은 A라는 이름이 좋은가? 아니면 B라는 이름이 좋은가를 항상 신중하게 검토해 보고 적절한 이름을 결정하는 프로세스를 반복할 필요가 있다.

코드의 리딩이나 리뷰
자신이 모르는 완전히 새로운 이름을 만드는 것은 코드를 분별없게 만들 가능성이 크다. 본인이 작성한 코드를 스스로 리딩해 보거나 다른 사람에게 리뷰를 함으로써 사용할 수 있는 이름을 조금씩 늘려간다. (본인 같은 경우는 아는 단어의 수준이 메롱이기 때문에 코드작업을 할 때 항상 사전을 열어놓고 작업을 하는 습관이 있다. 이때도 주의할 것은 일회성으로 모르는 단어를 만들어 명명하는 것 보다는 그 단어를 충분히 숙지한 상태에서 이름으로 사용하는 것이 바람직하다 – 간혹 내가 만든 이름을 내가 이해하지 못하는 어처구니 없는 경우가 발생 하기도 한다. 메롱;;)

좋은 변수명
설명적인 변수명
변수에는 값이나 오브젝트가 대입된다. 변수명을 보는 것만으로도 무엇이 어떠한 역할을 하는지 명확한 것이 좋은 이름이라 할 수 있다.

예를 들어
var n:int;                                                 // 무슨 수치?
var languages:Array = [“kr”, “en”];     // 무슨 언어?
var flg:Boolean = false;                      // 무슨 플래그?
var userAgent:UserAgent                  // 무슨 유저 에이전트?

위와 같은 변수명은 나중에 되돌아보면 변수의 역할을 알 수 없다. 아래와 같이 좀더 구체적이고 명확한 이름으로 해 두면 되돌아 보거나 다른 사람이 봐도 이해하기 쉬운 코드가 된다.

var orderCount:int;                                                // 오더수
var availableLanguages:Array = [“kr”, “en”];     // 이용 가능한 언어
var existsSameName:Boolean = false;           // 동성동명이 존재할까?(존재 true)
var unknownUserAgent:UserAgent                  // 미지의 유저 에이전트

다만 변수는 변수의 종류와 그 변수의 스코프(변수의 값을 참조할 수 있는 범위, 변수의 선언으로부터 시작되어 변수의 값을 참조할 수 없게 될 때까지의 범위)에 의해서 좋은 이름의 성질이 다르다. 스코프가 넓으면 다양한 곳으로부터 참조되므로 영향 범위가 크다고 할 수 있다. 따라서 보다 구체적인 이름이 요구된다. 종류별로 보면 아래와 같다.

필드 변수, 클래스 변수
필드 변수는 인스턴스 변수이다. 필드 변수, 클래스 변수는 로컬 변수등과 비교하면 변수의 스코프가 넓기 때문에 특히 그 변수의 의미를 올바르게 표현한 이름이 바람직하다.

메소드의 파라미터
파라미터명은 알기 쉽고 간결한 이름이 좋을 것이다. 파라미터명은 이용자가 API레퍼런스로 참조하거나 Eclipse, FlashDevelop등의 통합 개발 환경으로부터 변수명의 후보로서 이용되므로 극단적으로 짧은 이름을 붙이는 것은 피해야 한다.

로컬 변수
메소드 내에서 일시적으로 선언되는 변수이다. 스코프가 긴 것도 있지만 for문과 같이 짧은 것도 있다. 스코프가 긴 것은 필드 변수와 같이 변수의 의미를 올바르게 표현하는 구체적인 이름을 붙이는 것이 좋다. 스코프가 짧은 것은 아래와 같이 사용구분만 적당히 해주면 된다.

관용어에 따르는 또는 따르지 않는다.
배열의 내용을 순서대로 처리하는 루프 카운터 변수(i,j,k)등과 같이 잘 사용되는 관습적인 변수명은 그대로 관용어에 따르는 편이 알기 쉬운 코드가 된다.
// 루프 카운터의 변수명이 관습적이지 않고 너무 길다 [X]
for (var empCounter:int=0 ; empCounter < employes.size ; empCounter++) {
          var emp:Employee = employees[empCounter];
    ...
}

// 루프 카운터의 이름이 관습적으로 짧고, 가독성이 높다 [O]
for (var i:int=0 ; i<employes.size ; i++) {
         var emp:Employee = employees[i];
    ...
}


다만 예외적인 경우도 있다. 구체적인 이름을 변수명으로 하는 편이 알기 쉬운 경우는 그렇게 사용한다. 예를 들어 좌표계를 취급하는 경우에는 아래와 같이 사용하여 가독성을 높일 수 있다.
// i,j의 어느 쪽이 x좌표, y좌표인지를 모른다 [X]
for (var i:int=0 ; i<width ; i++) {
    for (var j:int=0 ; j<height ; j++) {
        var color:uint = getColor(i, j);
        ...
    }
}

// 변수명을 x,y로 했으므로 알기 쉽다 [O]
for (var x:int=0 ; x<width ; x++) {
    for (var y:int=0 ; y<height ; y++) {
        var color:uint = getColor(x, y);
        ...
    }
}

위 for문의 경우, 중첩되는 var y:int=0 변수 선언은 for문 밖에서 선언해 주는 것이 바람직하다. 중첩된 for문 안에서 x가 카운팅 될 때마다 메모리상에서는 y라는 변수의 어드레스를 매번 push해야 하는 불필요한 리소스 낭비가 발생하기 때문이다. (이 부분에 대한 논쟁 이슈가 있다. 이후에 이야기할 로컬 변수의 스코프 부분에서 로컬 변수의 스코프는 가능한 작게 한다는 변수의 의존성에 따른 대원칙에 위배되는 것이기 때문이다. 이것은 사용하는 상황에 따라 적절히 혼용하는 것이 좋을 것이다.)
var x:int;
var y:int;
for (x=0 ; x<width ; x++) {
    for (y=0 ; y<height ; y+) {
        var color:uint = getColor(x, y);
        ...
    }
}

변수명을 짧게 하는 편이 가독성이 향상되는 경우도 있다.
충분히 인지할 수 있는 범위인 경우로 루프내의 변수나 짧은 메소드 내의 변수처럼 일시적인 변수는 짧게 하는 편이 반대로 가독성이 향상되는 경우도 있다.
// 변수명 siteContactChangelog는 너무 길다 [X]
for (var i:int=0; i<siteContactChangelogs.length ; i++) {
    var siteContactChangelog:SiteContactChangelog = siteContactChangelog[i];
    siteNames[i] = siteContactChangelog.getSiteName();
    siteTitles[i] = siteContactChangelog.getSiteTitle();
    sitePicIds[i] = siteContactChangelog.getPicId();
    sitePicNames[i] = siteContactChangelog.getPicName();
}

// 변수명 log는 충분히 그 의미를 이해할 수 있기 때문에 가독성이 좋다.[O]
for (var i:int=0; i<siteContactChangelogs.length ; i++) {
    var log:SiteContactChangelog = siteContactChangelog[i];
    siteNames[i] = log.getSiteName();
    siteTitles[i] = log.getSiteTitle();
    sitePicIds[i] = log.getPicId();
    sitePicNames[i] = log.getPicName();
}

좋은 메소드명
좋은 메소드명은 이름으로부터 그 기능을 예상할 수 있다. 메소드는 처리를 담당함으로 메소드명은 동사+목적어 형태인 것이 많다. 아래는 자주 사용되는 메소드명의 예이다.
 메소드의 역할                                         메소드명
 값 취득에 관한 메소드                           getXXX
 값 세트에 관한 메소드                           setXXX
 생성에 관한 메소드                                create, build, make, generate
 초기화에 관한 메소드                            initialize, setupXXX
 파기에 관한 메소드                               destroy, dispose
 상태 확인에 관한 메소드                      contains, exists

인스턴스 메소드는 dataFormat.parse와 같이 오브젝트명으로 조합하므로 합쳐졌을 때는 중복 없게 의미가 통하는 이름으로 한다. 메소드와 클래스명도 이와 동일하다.
// parseDateString은 클래스명 DateFormat과
// date라는 이름이 중복되어 약간 장황
var dateFormat:DateFormat = new DateFormat("yyyy-MM-dd");
var startDate:Date = dateFormat.parseDateString("2008-04-01");

// 클래스명 DateFormat과 메소드명 parse로
// 무엇을 처리하는지 충분히 이해할 수 있음.
var dateFormat:DateFormat = new DateFormat("yyyy-MM-dd");
var startDate:Date = dateFormat.parse("2008-04-01");

좋은 클래스명
변수명이나 메소드명과 비교해서 클래스명은 가용 범위가 크기 때문에 적절하고 좋은 클래스명을 붙이는 것이 중요하다. 좋은 클래스명은 이름만으로 무엇을 실시하는 클래스인가를 알 수 있다.

클래스명이 잘 떠오르지 않을 때는 자신이 만들려고 하는 클래스의 역할을 제대로 정리 할 수 있는지 없는지를 판단해 보아야 한다. 1개의 클래스에 복수의 책무를 넣거나 역할이 애매한 기능은 없는지를 생각해보고 해당 클래스에서 해결하고자 하는 문제를 차분히 생각해보고 클래스명을 다시 선택할 필요가 있다.

클래스명의 어휘 설계 능력
이름 명명에 관하여 자신이 모르는 표현, 개념은 쉽게 생각하기 어렵다. 보다 나은 표현을 선택하려면 여러 가지 코드나 서적을 읽거나 실제로 코드를 쓰고 시험하는 것이 중요하다. 그 경험을 통해서 이름에 관한 어휘가 조금씩 늘어난다. 본인 같은 경우는 영어권의 개발자가 작성한 기능과 메소드명을 보면서 의미해석을 한다. 사실 프로그래밍 과정에서 이름을 짓는 것은 생활에서 보편적으로 사용하지 않는 단어들도 많이 존재한다. 하지만 그만큼 자주 사용되는 단어들은 한정되어 있기 때문에 틈나는 대로 기억을 되살려 사용해 보는 것이 중요하다.

좋은 패키지명
ActionScript의 패키지명은 클래스나 자원의 논리적인 그룹을 만들어 계층 구조를 나타낸다 이것은 주로 이름의 충돌을 막기 위해서 사용된다. 패키지명은 그룹의 논리적인 내용을 나타내는 간결한 명사를 선택한다.

간혹 클래스를 만들지 않고 라이브러리에서 특정 무비클립을 동적으로 참조하기 위하여 Linkage에 클래스명만 기입하여 사용하는 경우가 있다. 이럴 경우 클래스가 플래시 컨텐츠전역에 오픈 되기 때문에 팀의 협업에 있어서 클래스명의 충돌을 야기할 수 있다. 이럴 경우 해당 클래스가 없더라도 관련된 패키지명을 명시함으로써 그러한 충돌을 줄일 수 있다. 

처음부터 좋은 이름을 사용할 수 있는 사람은 없다. 좋은 이름에 대해서 의식적으로 사용하려고 노력하는 것이 중요하다. 누구라도 알기 쉽고, 이해하기 쉬운 코드라고 하는 것은 항상 의식하고 노력하다 보면 점차적으로 좋은 이름을 지을 수 있는 요령이 생길 수 있을 것이다.


스코프를 의식한 프로그래밍
사실 모든 프로그래밍에서 스코프는 존재한다. 의식적으로 스코프를 컨트롤 할 수 있으면 보다 좋은 프로그래밍 스타일에 가까워질 것이다. 이번에는 스코프에 대한 이야기를 해보자.

우선 스코프는 Wikipedia에 다음과 같이 정의되어 있다.
프로그래밍에서 스코프란, 어느 변수나 함수가 특정 이름으로 참조되는 범위, 어느 범위의 밖에 있는 변수 등은 통상 그 이름만으로는 참조할 수 없다. 이때 이러한 변수는 스코프 밖에 있어 보이지 않는다 라고 말한다.

스코프는 변수, 메소드, 클래스등이 보이는 범위다. 그렇다면 보인다는 의미는 무슨 뜻일까? 보인다라는 것은 프로그래밍상에 있다는 것이다. 변수이면 변수명을 지정해 값을 읽고 쓰기가 가능하고 메소드는 호출해 사용할 수 있는 범위에 있는 것이다.

사용할 수 있다라는 것은 바꾸어 말하면 그것에 의존한다라고 이야기할 수 있다. 하나의 코드를 변경하고 싶을 뿐인데 수십 곳을 수정할 필요가 있을 수 있다. 이것은 변경하고자 하는 코드가 여러 곳에 의존하고 있으면 이와 같은 변경이 다른 부분에 영향을 준다.

스코프 == 보이는 범위 == 사용할 수 있는 범위 == 의존하는 범위

변수나 메소드의 스코프를 작게 하는 것으로 보이는 범위가 작아져 사용할 수 있는 범위, 의존하는 범위도 작게 할 수 있다. 스코프를 작게 하는 것으로 보다 의존성이 적어 변경이 용이한 프로그램을 작성 할 수 있는 것이다.

기억해 두는 것을 줄이자.
의존이 작아지는 것 이외에도 스코프를 작게 하는 것으로부터 도움이 되는 것이 있다. 프로그래밍은 본질적으로 복잡한 것이다. 복잡함에 대한 대책으로서 문제 영역을 가능한 작고, 이해 가능한 상태로 취급하는 것이 중요하다. 스코프를 의식적으로 작게 하는 것으로 프로그래머가 기억해 두지 않으면 안 되는 것, 주의하지 않으면 안 되는 범위는 작아져서 쉽게 이해할 수 있게 된다. 이것이 스코프를 작게 하는 것의 본질이라고 할 수 있다.

로컬 변수의 스코프
로컬 변수란 메소드 내에서 선언된 일시적인 변수다. Java나 Ruby의 로컬변수는 선언된 장소로부터 스코프가 시작되어 선언된 블록이 끝나면 스코프가 종료된다. ActionScript 2.0 에서도 순차적으로 메모리 할당이 이루어 졌기 때문에 메소드 내에서 상위에 선언된 변수와 하위에서 선언된 변수가 서로 다른 영역 범위의 스코프를 갖기 때문에 컴파일 시에 충돌이 발생하지 않았다.(Java, Ruby와 동일)

반면 ActionScript 3.0에서의 로컬변수는 스코프의 시작은 컴파일러가 블록에 접근했을 때 블록 내의 위치와는 상관없이 미리 메모리 주소가 할당된다. 이는 컴파일 시에 메모리 할당이 한꺼번에 선행되어 스코프가 동일하기 때문에 변수명 중복 에러 메시지를 출력하는 것이다.

하지만 일반적인 프로그래밍 언어에서는 변수의 의존도를 최소화하여 프로그램의 변경이 쉽게 하기 위하여 [로컬변수의 스코프는 가능한 작게 한다.] 라는 것이 대원칙이다.

필드 변수의 스코프
필드 변수는 인스턴스 변수다. 필드 변수의 스코프는 private / public 등과 같은 키워드를 통해서 정해진다. ActionScript의 경우 필드 변수에 대한 가시성은 스코프가 작은 순서로 4개가 지원된다.
private    : 오브젝트 내에서만 변수에 액세스 할 수 있다.
internal    : 같은 패키지 내에서 액세스 할 수 있다.
protected : 오브젝트 내 그리고 하위 클래스로부터 액세스 할 수 있다.
public : 오브젝트 밖에서 액세스 할 수 있다.

필드 변수는 모두 private가 기본 전략이다. 필드 변수에 외부나 하위 클래스로부터 액세스 하고 싶은 경우에는 set/get 등 액세스용 메소드를 따로 만들어 공개하는 것이 캡슐화에 도움을 준다. 하지만 기본 전략이 바람직하다고는 하지만 상속에 따른 장황함을 배제하기 위해서 protected나 public 접근자를 사용하는 경우도 발생한다.

인스턴스 메소드의 스코프
인스턴스 메소드는 인스턴스에 속하는 메소드를 말한다. ActionScript에서 메소드의 스코프 가시성도 필드 변수와 같이 4개이다. 메소드의 접근 제한은 최소인 private로부터 시작하여 점차적으로 internal -> protected -> public으로 나아가는 것이 바람직하다.

메소드 파라미터의 정보량
스코프에서 조금 벗어난 이야기이지만 메소드의 인수로 건네주는 정보량을 어느 정도로 하는 것도 의존성이라는 관점에서 보면 중요한 선택이다.

예를 들면 아래의 두 코드는 사원 정보를 취득하는 메소드이지만 1번은 인수가 사원ID이고 2번은 인수가 사원 오브젝트이다. 이 두 개의 코드 중에 어느 쪽이 좋은 코드라고 할 수 있을까?
// [1] 인수가 사원ID인 경우
public function getEmployee(inEmpId:int):Employee {
    return empDao.findById(inEmpId);
}

// [2] 인수가 사원 오브젝트의 경우
public function getEmployee(inEmp:Employee):Employee {
    return empDao.findById(inEmp.getId());
}

일반적으로 1번이 인수의 정보량이 적기 때문에 의존이 적고 좋은 코드라고 할 수 있다. 반면 2번은 사원 오브젝트가 가지는 모든 정보로 액세스가 가능하기 때문에 의존이 커지게 된다. 필요한 것은 사원의 ID이므로 그것에만 의존하여 코드를 작성하는 것이 바람직하다.

메소드를 이용하는 측면에서 사원 ID만으로 메소드를 이용할 수 있는 것과 사원 오브젝트가 필요한 것은 전혀 다르다. 더욱이 2번 메소드 내에서 구체적인 처리는 사원 오브젝트의 사원 ID만을 사용해 사원 정보를 검색하고 있다. 이것이 문서화 되어 있지 않을 경우, 코드를 읽지 않으면 그 사실을 알지 못한다. 인수에 불필요한 정보가 포함되어 있으면 사원 ID가 포함된 사원 오브젝트를 건네주어야 한다는 암묵적인 요구가 발생하기 쉽다.

위와 같은 문제 때문에 메소드의 인수는 필요 최저한의 정보를 가지는 것이 의존성이 적고 좋은 코드라고 말할 수 있다.

다만 인수가 너무 많아지는 경우는 인수를 오브젝트로 변경하는 편이 좋다. 기준으로서 인수의 개수가 5개를 넘는 메소드는 인수를 오브젝트로 변경하는 것을 검토할 필요가 있다.

static 메소드
static메소드(클래스 메소드)는 클래스에 속하는 메소드이다. ActionScript에서는 static 키워드를 붙여서 선언한다. static 메소드의 가시성은 인스턴스 메소드의 가시성과 같다. 반면 다른 점은 static 메소드는 필드 변수에 액세스 할 수 없다. static 메소드는 메모리에 미리 할당이 되는 반면 인스턴스 변수는 오브젝트가 인스턴스화 된 시점에서 메모리 할당이 되기 때문에 static 메소드 내에서 인스턴스 변수를 참조할 방법이 없는 것이다.

필드 변수에서 보면 인스턴스 메소드를 static 메소드로 변경했을 경우, 자신이 영향을 주는 메소드가 줄어 들게 되어 결과적으로 스코프는 작아진다. 필드 변수에 액세스 할 필요가 없고, 오버라이드가 필요하지 않는 메소드는 static 메소드로 하는 편이 좋은 경우가 많다. 물론 무조건 static으로 하는 것이 좋은 것은 아니다. 인스턴스가 생성되지 않은 시점에서 메모리에 할당이 되기 때문에 사용하지 않는 클래스의 static 메소드가 메모리에 상주하는 메모리 차원에서의 단점도 있다.
// 인스턴스 메소드의 경우
private var count:int;                                                           ┓
...                                                                                           |
private function regexGroup(inRegex:String):String { |변수 count의 스코프
    // 필드에 액세스 가능                                                     |
    return "(" + regex + ")";                                                   |
}                                                                                             |
...                                                                                            ┛

//static 메소드로 변경했을 경우
private int count;                                                                  ┓
...                                                                                            ┛변수 count의 스코프
static private function regexGroup(inRegex:String):String {
    // 필드에 액세스 불가
    return "(" + regex + ")";
}
...     ―변수 count의 스코프


코드의 분할
몇 천행이 넘는 메소드로 너무 많은 기능을 포함하고 있거나 메소드를 너무 세세하게 분할하여 흐름을 파악하기 어려운 코드는 좋은 코드라 할 수 없다. 좋은 코드가 되기 위해서는 가독성이 좋고, 유지보수성이 우수한 것이라고 위에서 언급했다. 메소드를 적절한 단위로 분할하는 것은 좋은 코드를 만드는 것에 중요한 역할을 한다.

코드를 분할하면 무엇이 좋은가?

가독성의 향상
메소드 코드의 길이가 100줄을 넘으면 처리의 흐름을 읽는데 어려움이 있다. 반면 30행 이하이면 내용을 이해하는 것이 용이하다.

유지보수성의 향상
분할에 의해 변수의 스코프가 작아지거나 처리 기능이 본래 있어야 할 클래스나 메소드로 이동하는 것으로 의존관계가 정리되어 유지보수성이 향상된다.

재이용성 향상
코드를 분할하면 코드의 중복이 줄어들어 이용 가능한 부품으로서의 메소드나 클래스를 만들 수 있다. 이것은 OOP 언어에서 좋은 방법이다.

캡슐화를 지킬 수 있다.
객체 지향에서는 캡슐화라는 개념이 있다. 메소드나 클래스의 상속에 의한 구체적인 구현이나 오브젝트 상태를 몰라도 메소드를 호출하는 것만으로도 각각의 오브젝트가 처리를 이행해 주는 것이다.

클래스의 관점에서도 비슷한 이득을 얻을 수 있다. ActionScript는 타 언어보다 MVC 페턴을 예로 들면 view에 해당하는 클래스가 Model에 비해 상대적으로 비대하다. 따라서 구조 작업에 있어서 이러한 view 그룹을 어떻게 분할하느냐에 따라서 유지보수성의 성패를 좌우한다고도 볼 수 있다.

위에서 좋은 코드를 위한 방법에 관하여 이야기를 했다. 연재에 실린 내용과 그것을 ActionScript에 맞게 수정하는 관계로 문장이 다소 매끄럽지 않는 점이 있을 것이다. 그런 부분은  이해해 주길 바란다.

사실 플래시는 타 언어에 비해서 버그가 발생할 가능성이 크다. 그 이유는 플래시의 강점인 모션을 항상 고민해야 하는 작업이기 때문이다. 일반적인 언어에서는 어떤 오브젝트가 나타나고 사라지는 사이에 시간이라는 개념을 포함할 필요성을 인식하지 못하지만 플래시는 모션에 따라 그 사이에 시간이 존재할 수 있다. 모션이 있는 사이에 예측하지 않은 사용자 반응이 있을 경우에는 버그가 발생할 수 있다. 플래시 개발자는 항상 이런 부분까지 예상하고 방어적 프로그래밍을 해야 한다.

위에서 이야기한 좋은 코드를 작성하는 것은 플래시의 작업에 많은 도움을 주지만 그런 것이 플래시 개발의 모든 약점을 보완해 주지는 못한다. 때로는 일반적인 좋은 코드로서의 방향에 영향을 주지 않는 범위 내에서 플래시의 장점을 극대화 할 수 있는 방법을 고민 해야 하는 것이다.

간혹 좋은 코드를 작성하는 방법을 물어보시는 분들이 있다. 물론 그것이 모르는 부분을 빨리 이해할 수 있는 좋은 방법일 수 있지만 쉽게 얻은 지식은 지식으로 머물러 지혜로 발전하지 못하는 경우가 많다. 더구나 본인 또한 그 방법을 찾고자 고민하고 배워가는 입장이기 때문에 도움을 주지 못하는 경우도 있다.

또한 플래시의 발전은 지식에 목말라 스스로 지혜를 얻으려 노력했던 선배들의 도움으로 커왔다고 나는 믿고 있기 때문이기도 하다. 위에서 이야기 한 내용은 본인 또한 노력하는 부분이고 이 포스트를 읽는 분들도 지혜를 얻기 위해 노력하다보면 좋은 코드를 생산할 수 있을 것이라 믿는다.



    

설정

트랙백

댓글

  • ° 북극곰 ° 2008.12.27 15:39 신고 ADDR 수정/삭제 답글

    플래시를 전혀 모르는 사람이지만 대충봐도 대단한 글이네요 ~! 혹 플래시 배울일이 있으면 참고하겠습니다 ~! 수고많이 하셨어요 ~!!

    • jasu 2009.01.01 02:15 신고 수정/삭제

      안녕하세요 말씀 감사합니다. ^^

  • douglas9 2008.12.29 18:23 ADDR 수정/삭제 답글

    좋은 글 잘 읽고 가요^^

    • jasu 2009.01.01 02:16 신고 수정/삭제

      네네 저도 다시 한번 정리하는 차원에서 작성한 글입니다. ^^

  • neewoo 2008.12.29 21:01 ADDR 수정/삭제 답글

    좋은 내용 잘읽었습니다. 개인적으로 도움이 많이 되는글이네요

    • jasu 2009.01.01 02:16 신고 수정/삭제

      도움이 되었다니 기분 좋은 일입니다. ^^ 새해 복 많이 받으세요

  • BK2008 2008.12.30 10:21 ADDR 수정/삭제 답글

    자수형님~ 익히 알았지만... 형님은 말을 참 논리있게 잘 하세요~
    좋은 내용이었습니다. 잘 보고 이 글에 힘입어 공부하러갑니다.^^

    • jasu 2009.01.01 02:19 신고 수정/삭제

      부군~ ^^ 글 내용은 잡지에 실린 내용과 내 개인적인 생각을 짬뽕해 놓은 거니 하향 조정해도 될듯하네 ^^ 건강하고 새해 복 많이 받길~

  • 쿠나 2008.12.30 20:37 ADDR 수정/삭제 답글

    장문이군요. 좋은 코드를 쓰지 않으면 절대로 좋은 프로그램이 만들어지기는 어렵다는 것을 다시 한번 보고 갑니다 ㅎㅎ.

    • jasu 2009.01.01 02:20 신고 수정/삭제

      공부를 통해서 아는 것만으로는 이 업계에서 살아남기 힘들다고 하더군요 ^^ 저도 그래서 노력 중입니다.

  • 야매코더 2008.12.30 23:26 ADDR 수정/삭제 답글

    잘봤습니다.
    유익하고 공감이 많이 가는 내용이었는데요 ,.
    저는 클래스간의 관계나 변수들이 햇갈려서 앞으로 UML 을 그려 가며^^(상그럽지만 ..)
    할려고 하는데요 ,.어찌 생각하시는지 /> ? ㅋ
    (지금 시상식 보고 있어서 ㅡ,.- 덧글에 인터뷰를 하고 있을뿐이고 ,.ㅋㅋ)

    • jasu 2009.01.01 02:21 신고 수정/삭제

      머리속에 있는 것을 좀더 구체화 하는 훈련을 하는 것도 체계가 있고 단계를 따라 진행하면 좀더 효율적으로 머리속 자원을 쓸 수 있다는 생각이 드네요 다만 그 훈련 자체가 노력이 필요한 부분이니 작은 것부터 꾸준히 진행하세요 ^^

  • bluesoo 2009.01.12 10:25 ADDR 수정/삭제 답글

    정말 좋은 정보 감사합니다. ^^
    프로그래밍 공부에 대한 저의 갈증이 많이 해소된것같네요. 참고해서 저도 더 좋은 코드 만들도록 노력할게요

    • jasu 2009.01.12 15:17 신고 수정/삭제

      저도 이런 정보를 접하다보면 읽는 당시에는 아 그렇구나 그렇게 해야지 하면서도 막상 실 작업에서는 망각하는 경우가 많은 것 같아서 반성중입니다. 도움이 되셨나니 기분 좋은 일입니다. ^^

  • 최강쥐으니 2009.01.15 17:30 ADDR 수정/삭제 답글

    와~~유익한 정보 ^^
    멋지구먼~~~-0-b

    • jasu 2009.01.16 14:20 신고 수정/삭제

      무유익은 본인이 받아들여야 성립한다는 ^^
      술사~ ^^

  • lovedev 2009.01.21 20:32 ADDR 수정/삭제 답글

    정말 공감가는 내용입니다.. 저랑 생각이 어쩜..이렇게..
    잘 읽고 가요 ^^

  • 검쉰 2009.01.25 20:31 신고 ADDR 수정/삭제 답글

    좋은 글입니다. ;)

    • jasu 2009.01.28 12:50 신고 수정/삭제

      새해 좋은 일 가득하세요~

  • 지돌스타 2009.01.27 11:31 ADDR 수정/삭제 답글

    잘읽었습니다. ^^

    • jasu 2009.01.28 12:50 신고 수정/삭제

      저도 가끔 지돌스타님의 글에서 도움 많이 받아요 감사합니다.

  • kakiyata 2009.02.09 17:28 ADDR 수정/삭제 답글

    저한테 꼭 필요한 내용!! 그죠? ㅎㅎ

    • jasu 2010.02.12 11:22 신고 수정/삭제

      쿠쿠 본인도 시간이 지나면서 환경과 타협을 하게 된다는..

  • 삶의향기 2010.02.08 15:38 ADDR 수정/삭제 답글

    저같은 경우는 항상 생각을 하면서 작성을 하지만 이후 돌아보면 손이 갈곳이 많더군요.^^;;

    끊임 없이 닦고 조이고..

    좋은 글 잘 읽었습니다.

    • jasu 2010.02.12 11:25 신고 수정/삭제

      반복적인 작업이더라도 효율적인 방법을 찾게 되는 것 같습니다. 처음부터 너무 완벽하면 그 또한 인간답지 않겠죠. ^^

[AS3] Pen 클래스 테스트

Programming/ActionScript 3.0 2007. 9. 14. 12:52
Pen 클래스를 이용해서 드로잉 테스트겸 만들어 봤다. Graphics 객체는 드로잉을 하면 할수록 CPU를 많이 잡아먹는디 Graphics 객체 안에서 어떤 일이 벌어지길에 이런 현상이 발생하는지 모르겠다... 그리는 과정에서 비트맵데이타로 처리해버리면 될거 같은디 귀찮스러워서 그냥 올려 놓는다. 테스트 하시는 분들은 너무 많이 그리지 마셔용...쿠쿠











 
 
    

설정

트랙백

댓글

  • moonkoon 2007.09.17 02:38 ADDR 수정/삭제 답글

    질문 드려도 될지 모르지만^^; 제가 이 문제를 풀어보려 매우 고생을 했는데; 솔직히 풀지 못했습니다 ㅠ_ㅠ;;; 아직 부족해서 그런건 알겠지만 너무 하고 싶은데 답답해서 아주 난리를 치고 있네여 ㅋ

    힌트좀 주세요 -_-;

    • jasu 2007.09.17 09:17 신고 수정/삭제

      어떤 문제인지...위 코드를 말씀 하시는 것이라면 위 코드는 Pen 클래스를 테스트 하기 위한 Container 역할을 하는 클래스입니다. Pen 클래스가 올라가 있지 않아서 위 클래스 만으로는 위와 같은 결과물을 만들 수는 없어요... Pen 클래스는 완전한 것이 아니라서 추후에 손을 대볼 생각입니다.

[AS3] 웹페이지에 코드를 이쁘게 보여주는 AScodeViewer

Project/Programming 2007. 9. 13. 06:43

AScodeViewer 1.0 Beta

개인적으로 플래시 코드를 웹상에 올릴 때 하이라이트를 적용하여 편하게 보기 위해서 만들었다. 만들다 보니 플래시 코드뿐만 아니라 다른 코드의 경우도 xml 파일을 수정하는 것으로 적용할 수 있다.

기능적인 요소
기능적인 요소로는 swf에 외부 변수값(코드파일url, 라이라이트 xml, 스타일 xml, selectable) 값을 전달하여 불러들인 xml과 코드, 그리고 코드를 선택 및 복사가 가능하도록 할 것인지를 지정하는 sable 값을 전달하게 된다. 이로서 AScodeViewer.swf 파일에서 코드 하이라이트 및 스타일이 적용된 AScodeViewer를 볼 수 있다.

외부 변수 값을 전달할 때 주의할 점은 크로스도메인 정책에 따라 도메인이 다른 url 경로에 있는 코드나 xml를 불러올 수 없다는 것이다. AScodeViewer.swf 파일이 있는 위치와 같은 도메인 상에 있는 파일을 불러들여야 한다.


사용성에 따른 기능적인 요소로는 오른쪽 하단에 보면 FullScreen mode로 전환할 수 있는 버튼이 있다. 클릭을 할 경우 전체 풀사이즈 화면으로 코드를 볼 수 있는 기능이다.

사용 방법
AScodeViewer을 사용하는 방법은 아래 제공하는 파일을 다운 받아서 사용하고자 하는 계정에 업로드를 하고 아래와 같이 코드를 웹페이지 html상에 넣어주면 된다.

<object width="700" height="400" >
<param name="bgcolor" value="#242424" />
<param name="allowFullScreen" value="true" />
<param name="FlashVars" value="code=TintColor.as&format=as3.xml&style=style_dark.xml&sable=true" />
<param name="movie" value="AScodeViewer.swf" />
<embed src=" AScodeViewer.swf"  flashvars="code=TintColor.as&format=as3.xml&style=style_dark.xml&sable=true" type="application/x-shockwave-flash" allowFullScreen="true" width="700" height="400" bgcolor="#242424" /></embed>
</object>

위에서 보이는 바와 같이 FlashVar에 해당하는 부분의 변수들에 각각의 파일 및 설정 값을 넣어주면 된다. 위 코드의 경우는 swf파일이 있는 같은 폴더 안에 code, format, style 에 해당하는 파일들이 있는 것으로 가정한 것이다.

하이라이트 및 스킨 적용 방법
코드 하이라이트는 플래시 스크립트 에디터로 많이 사용하고 있는 FlashDevelop 프로그램의 language폴더에 있는 xml 데이터를 그대로 사용하였다. FlashDevelop 프로그램을 사용하는 분은 아래 경로에서 사용하고 있는 하이라이트 xml 파일을 취득할 수 있다.

C:\Program Files\FlashDevelop\FirstRun\Settings\Languages

위 경로에서 보면 AS3.xml, AS2.xml, Jscript.xml 등을 볼 수 있는데 AScodeViewer 1.0 Beta에서 지원하는 xml 형태는 AS3.xml, AS2.xml, Jscript.xml, HaXe.xml 이다. 다른 C++ 이나 Java 등의 코드 하이라이트를 사용할 경우에는 위 4개의 파일 중에 아무 파일이나 열어서 해당 언어에서 사용하는 하이라이트 단어들을 등록하고 다른 이름으로 저장하여 사용하면 된다.

AScodeViewer의 스킨 적용은 제공하는 Style_dark.xml 파일이나 style_light.xml 파일을 열어서 해당 부분의 RGB 색상을 변경하여 스킨을 바꿀 수 있다. 아래 이미지를 보면 style.xml 파일에서 지정할 수 있는 부분들을 표시해 놓았다.

사용자 삽입 이미지


아래는 파일로 제공하는 두 가지 스킨을 적용한 예이다. Style_dark.xml 이나 style_light.xml 파일을 수정하여 원하는 색상을 만들어 낼 수 있기 때문에 적용하는 페이지상의 디자인에 맞게 수정하여 사용하면 된다.
왼쪽은 style_dark.xml을 적용한 예이고 오른쪽은 style_light.xml을 적용한 예이다. 왼쪽의 경우 코드 선택이 안되도록 sable = false 값을 적용하였다.


아래 파일을 다운로드 하여 위에서 설명한 대로 원하는 페이지에 적용하면 된다. 블로그 서비스에서는 “외부 멀티미디”어 등에서 youtube 동영상을 임베드 하는 형태로 적용하면 된다. 주의할 점은 위에서 언급한 바와 같이 AScodeViewer.swf 파일이 있는 곳과 불러오는 파일들의 도메인이 같아야 한다는 것이다(같은 도메인 내의 폴더 구분은 상관없다.)

앞으로 버전업의 경우도 FlashDevelop의 기능을 적용할 생각이다. 시간이 허락하는 대로 업데이트 버전을 올려 놓도록 하겠다. 사용하다가 문제점이 있거나 버그 발견 시에는 아래에 댓글로 남겨주시면 많은 도움이 될 것 같다.


AScodeViewer1_0Beta.zip

    

설정

트랙백

댓글

  • 지돌스타 2007.09.13 09:53 ADDR 수정/삭제 답글

    이야~ 아이디어 정말 훌륭하군요~

    • jasu 2007.09.13 15:28 신고 수정/삭제

      감사합니다. ^^ 외국분이 2005년도 경에 작업했던 것이 모티브가 되었습니다.

  • 공씨 2007.09.13 10:12 ADDR 수정/삭제 답글

    >ㅁ< 형님 브라보~ 멋져요~

    • jasu 2007.09.13 15:29 신고 수정/삭제

      고마우이...쿠쿠 사용해보고 문제 있으면 알려주라

  • 뚜기~ 2007.09.13 14:04 ADDR 수정/삭제 답글

    ^-^ 멋지네요~ ㅋ

    • jasu 2007.09.13 15:30 신고 수정/삭제

      감사합니다. ^^ 유용한 자료가 되었으면 좋겠네요

  • 금봉이 2007.09.13 14:53 신고 ADDR 수정/삭제 답글

    너무 멋집니다.. ^^
    제가 SQL파일에 적용하던 중에 커맨트안에 '가 들어가니까 이후 문장이 다 스트링값의 색으로 변경되어 버리더라고요. /* This lock is global, so we can't tell */ 라는 커맨트에서 can't의 '이후가 다 스트링으로 인식해버리더라고요.. can not으로 바꿔버려 해결했지만... 다음 버젼에는 가능하면 수정해 주시면 감사하겠습니다. 혹시 제가 잘못했을지도 모르니 테스트한번 해보시와요.
    멋진 tip을 올려 주셔서 감사드립니당~!

    • jasu 2007.09.13 15:32 신고 수정/삭제

      감사합니다. 확인해 본 결과 ActionScript 코드나 여타 언어에서는 문제가 발생하지 않았는데 sql 코드에서는 언어 구조에서 약간 오류가 있었던 것 같네요 확인하고 수정하였으며 다시 파일을 업로드 하였습니다. 불편하시더라도 다시 다운로드 하셔서 swf 파일만 대체해서 사용하세요...

  • 사노이 2007.09.13 16:01 ADDR 수정/삭제 답글

    멋집니다^^ 언제나 말보다는 행동으로,결과물로 보여주시는게 정말 존경스럽습니다.
    저도 많이 노력해야겠네요^^

    • jasu 2007.09.13 17:30 신고 수정/삭제

      제가 말수가 좀 없어서 오해를 하신거 아닌가 하는 생각이 드네요^^ 아무튼 말씀 고맙습니다.

  • 금봉이 2007.09.13 16:41 신고 ADDR 수정/삭제 답글

    와우~! 빠른 응답속도를 보이시는 JASU님께 다시 한번 존경을 표합니다... ^^;
    고맙습니다.

    • jasu 2007.09.13 17:32 신고 수정/삭제

      ^^ 네... 유용하게 사용하세요...감사합니다.

  • 열이아빠 2007.09.14 08:31 신고 ADDR 수정/삭제 답글

    하루사이에 벌써 버전업까지 되었네요.
    멋진 기능 감사합니다.

    • jasu 2007.09.14 13:15 신고 수정/삭제

      버전업은 아니고 금봉이님께서 sql 코드를 넣었을 때 위와 같은 문제가 있어서 살짝 수정해서 몰래 엎어치기 해놨어요..쿠쿠 감사합니다.

  • fan 2007.10.07 07:08 ADDR 수정/삭제 답글

    너무 좋은데.. as 2.0 버전으로도 만들어주시면 더 좋겠습니다^^

    • jasu 2007.10.07 12:29 신고 수정/삭제

      안녕하세요.. flashDevelop 프로그램폴더에 있는 as2.xml 파일을 사용하시면 as2 버전 highligiht 기능을 사용할 수 있습니다. ^^

  • fan 2007.10.07 18:57 ADDR 수정/삭제 답글

    as2 버전 하이라이트가 아니구요.. AScodeViewe를 as2버전으로 제작하는것을 말씀드린겁니다^^
    다른무비에서의 로딩이 가능하도록 말이죠..^^

    • jasu 2007.10.08 10:01 신고 수정/삭제

      ^^; 요즘은 2.0보다 3.0이 친근한 것 같네요... fan님께서3.0을 접해보시는 것도 나쁘지는 않을 것 같습니다. 2.0으로 다시 제작하기에는 의미가 없는 것 같아서 어려울 것 같네요..^^ 아무튼 감사드립니다.

  • 동강 2007.11.10 04:58 ADDR 수정/삭제 답글

    와우 자기 소스 자료 관리 할때 유용하게 쓰일꺼 같아요, 잘 쓸께요.

    • jasu 2007.11.12 02:47 신고 수정/삭제

      좀더 편하게 만들고 싶었는데 그놈에 크로스도메인 때문에 소스 코드 업로드로 인해서 불편함이 있네요 서버에서 서비스를 한다면 좀더 편해지지 않을까 싶긴 하지만...;;

  • 원강민 2008.03.25 10:03 신고 ADDR 수정/삭제 답글

    http://airdev.tistory.com/226
    AIR로 SWF를 생성해주는 어플을 만들었습니다..트랙백 안걸려서 덧글로^^

    • jasu 2008.03.25 16:21 신고 수정/삭제

      오.. 편하겠네요 ^^ 스킨을 수정 가능한 기능을 추가하면 좋겠네요 ^^

  • 리베하얀 2008.05.09 13:33 ADDR 수정/삭제 답글

    정말 좋네요~
    한번 사용해야 겠습니다
    늘 좋은 정보만 얻고 가네요~

  • seo4234@hanmail.net 2009.02.05 17:18 ADDR 수정/삭제 답글

    한글이 깨져서 나오는건 왜 그런걸 까요?

    • jasu 2009.02.07 12:31 신고 수정/삭제

      제가 한글입력을 안해봤네요 잠시만요

    • jasu 2009.02.07 12:31 신고 수정/삭제

      위 게시물에 한글을 입력 해 봤는데 제대로 나오는것 같네요 아무래도 플래시 소스에서의 문제 보다는 적용한 코드 소스 파일의 인코딩에서 문제가 발생 하는 것 같습니다. 적용한 코드를 메모장으로 열어서 다른 이름으로 저장시 UTF-8로 저장해 보세요

    • seo4234@hanmail.net 2009.02.15 16:05 수정/삭제

      좋은 답변 감사합니다. 다시 한번 해보도록 할게요.

  • Flask 2009.07.03 12:46 신고 ADDR 수정/삭제 답글

    폰트는 바꿀수 없나요? // 그런데 저는 적용이 쉽지 않네요,,,, 티스토리 쓰는데 그냥 컬러값이 #242424인 박스(700x400)만 나오고 '동영상이 로드되지 않음'이라고만 떠요,,ㅠㅠ

    정말 사용하고 싶은데 어떻게 하면 될까요,,,(다운로드 받은 파일과 as파일을 스킨에 업로드 한뒤 html 코드를 html 에디터에 넣은뒤 as파일 이름만 바꿔서 저장했습니다..)

    • jasu 2009.07.05 22:55 신고 수정/삭제

      안녕하세요
      댓글이 좀 늦었네요 폰트는 사용하시는 style xml 데이터 아래에 보시면 폰트 관련 default 설정 노드가 있습니다. Courier New 부분은 원하시는 폰트명으로 바꾸시면 됩니다. 윈도우 설치시 기본으로 들어있는 시스템폰트를 이용하셔야 정상적으로 적용됩니다.

      동영상이 로드되지 않음 이라고 표시되는 것은 swf의 경로가 잘못되어 해당 경로에서 swf파일을 찾을 수 없을 때 방생합니다. swf파일 경로가 제대로 되어 있는지 확인이 필요합니다. 감사합니다.

    • Flask 2009.07.06 12:52 신고 수정/삭제

      답변 감사합니다,,ㅎ
      그런데요, 억지로 swf파일의 경로를 적어줘서 해두었는데 계속 동그라미만 돌아가네요,,,아마 다른 파일들(xml)을 읽어들이지 못하는것 같은데요,,,

      제가 한 방법이 맞는지 말씀해주세요,,ㅠ

      1. 다운로드 받은 파일을 압축을 풀고 티스토리 어드민에 들어간다음, 스킨 바꾸기에서 파일업로드를 눌러 파일들을 업로드 한다. 추가로 내가 작성한 TA.as파일도 업로드 한다. ( 자동으로 경로가 images/파일명 으로 되더군요,, )

      2. 자수님 블로그에 적혀있는 태그를 복사한뒤 글쓰기에서 html에디터로 들어간다음 붙여넣고 TintColor.as -> TA.as(제가 업로드 한것)로 바꿔준다.

      3. 글작성을 완료하고 확인한다 (-> 동영상이 로드되지 않음. 그래서 swf파일을 글에 업로드 한뒤 그 경로를 적어주니 swf파일은 로드되지만, 동그라미만 돌아감,,,)

      아 이거 제가 바보같아서 정말 죄송하네요,,,

    • jasu 2009.07.06 17:05 신고 수정/삭제

      안녕하세요
      제가 설명을 명확하게 해놓지 않은 것 같습니다.
      다른 문제는 없어 보입니다. 다만 FlashVars로 swf 파일에 전달하는 변수들의 값들을 모두 http://를 포함한 절대경로로 지정해 주시면 될것 같습니다. 플래시에서 파일 경로를 탐색할 때 swf가 임베드되어 있는 html파일의 위치에 따라 상대경로를 지정합니다. 샘플에서 작성해 놓은 것은 로컬에서 모든 파일이 한 폴더에 있을 때 가정으로 설명해 놓은 것이니 모든 파일 경로는 http://를 포함하는 절대경로를 지정해 보세요
      감사합니다.

    • Flask 2009.07.07 15:22 신고 수정/삭제

      우...와..... 드디어 성공했어요,,,,ㅠㅠ

      스킨에 업로드된 파일의 겅로를 찾아줘서 적어주면 되는군요! (제 경우는 http://cfs.tistory.com/custom/blog/24/246210/skin/images/ 이거 네요,,,ㅎㅎ)

      아, 정말 잘되요!! 정말 좋은 기능이에욧!! ^^

      답변 정말 감사드립니다!

      // 배경에 줄이 있으면 어떨까요? 그냥 선 말고 한줄씩 격줄로, 드래그 된 모양으로 줄구분이요;;ㅎ,,,,

    • jasu 2009.07.16 20:29 신고 수정/삭제

      라인으로 구분지어 놓으면 보기 편할거 같기는 하네요 ^^ 감사합니다.

  • -_-;; 2009.10.07 19:26 ADDR 수정/삭제 답글

    이런 아예 안되네요... 그냥 검은 화면만나오고..

    • jasu 2009.10.07 21:03 신고 수정/삭제

      안녕하세요~
      플래시가 나오지 않을 경우는 아마도 경로문제일 것 같습니다. swf 파일 경로와 xml, as파일 경로가 제대로 적용되어 있는지 확인해 보시는 것이 좋을 것 같습니다. 안되는 페이지 경로를 보내주시면 확인해 보도록 할께요 감사합니다.

  • -_-;; 2009.10.16 20:26 ADDR 수정/삭제 답글

    그래도 검은 박스만 뜨는데요;;
    스킨에 업로드된 파일 경로를 어떻게 알아내는지...
    주소표시줄 있는거 복사해도 안되는데요;;....-_ㅡ;;

    • jasu 2009.10.18 01:38 신고 수정/삭제

      일단 올리신 임베드 소스와 as파일 경로, xml파일 경로 등을 올려주세요 제가 확인해 보고 문제가 있는 부분을 알려드릴께요

  • 천우철 2010.10.15 10:26 ADDR 수정/삭제 답글

    자수님 안녕하세요 처음뵙겠습니다 ^^
    자료 잘 받아서 블로그에 처음 적용해보았습니다. 너무 이쁘고 쓰기 간편하네요.
    잘쓰겠습니다 공부도 열심히 하겠습니다.
    수고하십시요 ^^

    • jasu 2010.10.18 18:00 신고 수정/삭제

      안녕하세요 ^^ 네 하도 오래전에 올려놓은 스킨이라 현재 티스토리 환경과 잘 맞을지는 모르겠네요. 감사합니다.