비공정

- 두 번째로 Node.js 프로젝트에 투입되었다. 나는 스칼라를 훨씬 더 좋아하지만, 현재 회사 상황으로는 함께 작업 할 스칼라 개발자는 커녕 자바 개발자도 구하기 힘든 실정이라 포기. 그런 면에서 Node.js는 접근성이 무척 뛰어난 것 같다. 기존 유경험자 외에도 필요하면 클라이언트 개발자까지 동원할 수 있다는 면에서는 그저 GG.
- 5.0 버전으로 다시 다루게 된 WebStorm은, 확실히 자바스크립트 계의 이클립스 -아마도 IntelliJ를 들지 않은 것에 화낼 사람도 있겠지만- 라고 할 만 하다. 요즘 홍보하는 Live Edit같은 기능이야 일반 에디터로도 자동 저장 + nodemon 정도면 어느정도 가능할 듯 싶지만, 이전까지 자바스크립트로 가능하리라고 생각한 적 없었던 각종 Code Inspection이나 리팩터링 기능 들은 젯브레인에서 얼마나 많은 삽질을 거쳤을 지 상상이 안될 정도. 물론 이것은 CommonJS나 JSDoc등 여러 제반 여건(?)의 발전에 힘입은 바도 크지만.
- 하지만 앞서 말한 것들은 사실 자바스크립트로도 되다니! 에서 놀라는 수준이지 완벽한 것은 아니어서, 자바 개발자로서는 거슬리는 부분이 한둘이 아니다. 대표기능인 RequireJS의 모듈과 JSDoc의 각종 어노테이션을 이용한 코드 검증은 헤메거나 오동작하기 일쑤여서, 시간이 지나면 점점 무시하거나 기능을 최소한 경고 기능을 꺼버리게 만든다.
- 이를테면 자바스크립트의 경우 메서드 오버로딩이 없는데, 반면에 인자의 null 여부를 체크하거나 리플렉션(arguments 배열)을 이용한 방식으로 메서드 오버로딩을 구현한 경우는 많이 있다. 예컨대 다음처럼 메서드 오버로딩을 구현한 경우

foo(obj, str)
foo(obj, str, bool)

주석에서 1,2,3의 타입을 차례대로 열거하고 3을 optional로 처리하면 이해하기도 쉽고 웹스톰도 잘 인식한다. 하지만

foo(obj, str)
foo(str, bool)

이런 형태의 메서드일 경우 문서 작성도 애매하고 웹스톰도 헤멘다. 대표적인 경우가 express의 app.configure. (3.0.4)
- GLOBAL 객체에 할당한 전역변수도 웹스톰이 이해하지 못하지만 이건 단순히 미구현에 가깝고, 전역변수를 만들어내는 것 자체는 별로 좋은 아이디어도 아닌 것 같아서 패스.
- 함수에 jsdoc 스타일로 문서를 작성하는 건 좋은 습관이니 괜찮지만, IDE에게 뭔가를 이해시키기 위해 변수에다가 @type 같은 걸 선언하고 있으면 그냥 (강타입 언어인) 스칼라를 쓰지 뭐하는 짓인가 싶다; 물론 이건 그냥 무시하면 되고, 안쓰면 거슬리는 건 확실한 걸 좋아하는 자바 개발자의 습성일 가능성이 크다.
- 라이브러리를 우려하면, Node.js 커뮤니티는 빠르게 성장하고 있고 라이브러리는 폭발적으로 많아지고 있다는 이야기를 듣는다. 물론 맞는 얘기지만, 개별 라이브러리의 완성도는 아직 갈 길이 멀다. 이를테면 로깅을 생각해 보자. log4j를 쓰던 입장에서 winston을 만난 첫 소감은 '올레!'지만, 그 다음에 이 라이브러리에 로그 파일을 날짜별로 생성해주는 기본적인 기능이 없다는 걸 확인하고서(0.6.2) 충격과 공포에 빠지게 된다... (logrotate 같은 외부 도움을 받으면 되긴 하지만...)
- 무엇보다 가장 미치게 만드는 건 중구난방인 API 문서 형식이다. 어떤 라이브러리는 README.md가 전부고, 어느 라이브러리는 위키를 뒤지고, 어느 라이브러리는 부트스트랩을 써서 만든 웹사이트에 복잡하게 걸어둔 탓에 원하는 부분을 즉각 찾기도 쉽지 않고, 그나마 내가 본 대부분 라이브러리가 최신 버전의 사항은 문서 반영이 늦는데다, 자바스크립트가 약타입 언어인 탓에 소스 까보는 것도 쉬운 일은 아니고... 제발 형식만 좀 어떻게 통일해줬으면 좋겠다.