AcitionScript 프로그래밍의 문제점

일단 2.0 기준 — 내가 해본게 그것 뿐이니.

하지만 세 포스팅을 연속으로 이런 글을 써야하니 좀 처량하고나 =,=

자동화된 테스트 기능의 부재

컴파일하고 바로 실행하기가 힘들다. 특히 서버 통신이 필요한 경우, 셋업도 복잡하고 짜가 객체도 못쓰고 불편한 점이 많다. ASUnit이란걸 방금 소개받긴했는데, 회사가서 다시 테스트를 해보던가해야. …그러고보니 트러스티 설정도 안해봤다 o <-<

복잡한 개발환경

서버에서 파일을 다운로드 받아 실행하는 Flash의 개념상 다음과 같은데 필요하다.

• 웹서버 … 잘하면 DB 서버까지
• 플래쉬 파일
• Socket 정책 서버

미성숙한 개발도구들

Java…의 뒤를 따라가고싶은거같은데(응용 분야야 좀 다르지만), 그러기엔 개발 환경의 성숙도가 너무 낮다. 

Flex3를 커맨드라인에서 해보려고 했지만 java 2쓰던 시절의 수준도 못되더라. 바로 포기하고 eclipse 플러그인의 체험판을 받아야 했다. 사실 문제점을 열거하자면 끝도 없겠지만, as 파일 하나에는 하나의 클래스만 넣을 수 있는 것이라거나 AS 2.0에는 protected 키워드도 없는 문제라거나.

전에 언급했던 this 포인터가 엄하게 치환되는 문제라거나 등등, C/C++/Java의 메인 스트림 응용에서 바로 넘어가기엔 벽이 되는 개념들이 많다. 이건 습관의 문젠가…

커맨드라인 도구의 부재

Flash CS3는 개발환경이라기 보단 디자인 환경이라 모든 작업을 IDE에서 해야한다. 

프로그램 컴파일, 실행, 디버깅 모두 IDE에서…

덕분에 커맨드라인 기반의 자동화된 빌드/테스트/리포트 루프는 돌지 못한다. 이거 때문에 인간이 일일이 빌드/테스트/검사하는 작업을 하면서 날아간 시간이 얼마나 될 것 같냐 -_-

뭔가 곁다리 일로 시작한게 거의 한달이나 끌게 되었지만, 그 동안 겪었던 문제 중에 제일 큰게 개발 환경이 안갖져서 시간이 걸린 것. 테스트 하나하려고 해도 새 class를 만들거나, 기존 메소드에 끝도 없이 집어넣던가…

개별 AS 을 validation하는 것도 mtasc를 발견하고나서야 제대로 되고 있고, ((확장 문법을 통합 array타입 추론이라거나; 좀더 강한 타입 규칙같은게 있더라)) 자동 빌드역시 mtasc 도입 이후부터 제대로 되고 있다.

뭐 이걸 도입한 최대 이유는 툴 라이센스 문제긴한데… Visual C# express 툴같은건 제공해줘야하지 않을까 -_-a 뭐 저기에도 test-suite 같은 기능은 없긴한데. ((eclipse플러그인에서 제공해줄지 모르지만 그래바야 AS 3.0밖에 못쓰는 Flex 3.0은 좀)) 내일은 일단 ASUnit 확인해보고, 적용하던가 버려지던가. 그리고 예정대로면 이게 마지막 사용일이 되야…