우리는 다소 큰 JavaScript 코드베이스를 가지고 있으며 약 한 달 전에 CoffeeScript를 사용해보기를 원했습니다. 개발자 중 한 명이 http://js2coffee.org/를 사용하여 모듈 중 하나를 JS에서 CS로 마이그레이션하기 시작했습니다 . 이 도구는 다소 편리했으며 1000 줄의 자바 스크립트를 이식하는 데 2 ​​~ 3 시간이 걸렸습니다. 그 시점에서 우리가 관찰 한 몇 가지 관찰 :

1. 결과적인 CoffeeScript 코드는 꽤 읽을 수있었습니다.

2. 우리는 그것을 JavaScript로 다시 컴파일했으며 탐색 및 디버깅이 매우 쉬웠습니다. 우리가 그 모듈을 포팅하는 동안 우리 팀의 다른 개발자가 버그를 발견했습니다. 이 두 개발자는 이전 JavaScript 코드와 CS 컴파일러에서 나온 새로운 JavaScript 코드에서이 버그를 수정했습니다. 그들은 독립적으로 일했고 같은 시간 (15-20 분)이 걸렸습니다.

3. 포트라는 사실 때문에 결과 코드는 적절하거나 바람직한 커피 전용 기능을 사용하지 않았습니다. 우리가 처음부터 CoffeeScript로 작성한다면 코드는 더 관용적 일 것입니다. 그 때문에 우리는 기존 코드를 이식하지 않기로 결정했습니다.

4. 일반적으로 더 짧은 기능과 더 작은 물체의 가독성이 어느 정도 증가했습니다. 그러나 전혀 그렇지 않은 더 긴 방법의 경우. 가장 큰 폭의 절감 효과는 ->명시 return적이지만, 코드가 크게 짧거나 단순하지 않은 것 이외의 것입니다. 일부 구문 조각, 특히 객체 리터럴은 상당히 혼란스러워 보입니다. CS는 멤버 정의 주위에 중괄호를 생략하고 “모든 표현식” 과 암시 적으로 결합하여 return일부 코드를 읽기 어렵게 만들었습니다.

   JavaScript는 다음과 같습니다.

   var rabbitGenerator = {
       makeRabbit: function(rabbitName, growCarrots) {
           if (growCarrots) {
               carrots.growMore(10);
           } else {
               carrots.ensureSupply();
           }
           return {
               name: rabbitName, 
               height: 0,
               actions: {
                   jump: function (height) {
                       this.height += height;
                   },
                   eatCarrot: function () {
                       // etc
                   }
               }
           };
       },
       // more members
   }
   

   해당 CoffeeScript 코드는 다음과 같습니다.

   rabbitGenerator = 
     makeRabbit: (rabbitName, growCarrots) ->
       if growCarrots
         carrots.growMore 10
       else
         carrots.ensureSupply()
       name: rabbitName // (*)
       height: 0
       actions: 
         jump: (height) ->
           @height += height
   
         eatCarrot: ->
   

   이제는 return 문이 (*)줄 에서 시작한다는 것을 알기가 매우 어렵습니다 . 우리 프로젝트에서 우리는 객체 리터럴에 크게 의존합니다. 그것들을 함수 매개 변수로 전달하고 다른 함수에서 반환합니다. 대부분의 경우 이러한 객체는 서로 다른 유형의 멤버와 여러 수준의 중첩으로 매우 복잡한 경향이 있습니다. 우리의 경우 전반적인 느낌은 CoffeeScript 코드가 실제로 일반 JavaScript 코드보다 읽기가 어렵다는 것입니다.

5. CoffeeScript를 디버깅하는 것이 우리가 예상했던 것보다 쉬운 것으로 판명되었지만 편집 경험이 상당히 저하되었습니다. 이 언어에 적합한 편집기 / IDE를 찾을 수 없습니다. 우리는 프로젝트의 클라이언트 측 코드를 위해 편집기 / IDE를 표준화하지 않았으며 실제로는 서로 다른 도구를 사용합니다. 실제로 팀의 모든 사람들은 CoffeeScript로 전환 할 때 도구의 지원이 다소 부족하다는 데 동의합니다. IDE와 편집기 플러그인은 매우 초기 형태이며 어떤 경우에는 적절한 구문 강조 또는 들여 쓰기 지원을 제공 할 수 없습니다. 코드 스 니펫이나 리팩토링에 대해 이야기하지 않습니다. WebStorm, Eclipse, NetBeans, VisualStudio, Notepad ++ 및 SublimeText2를 사용합니다.

6. 도구에 관해서는 CoffeScript 컴파일러 자체가 Node JS 패키지로 제공된다고 언급해야합니다. 우리는 기본 Java / .NET 상점이므로 모든 사람들이 Windows 박스에서 개발하고 있습니다. 최근까지 노드에는 Windows 지원이 거의 없었습니다. 우리는 CoffeeScript 컴파일러를 Windows에서 실행할 수 없었기 때문에 당분간은 <script type="text/coffeescript">태그와 브라우저 기반 on-the-fly 컴파일러를 사용 하기로 결정했습니다 .

   컴파일러는 매우 빠르며 시작 시간을 크게 늘리지 않습니다. 단점은 결과 JavaScript가 eval얻어지고 브라우저 개발자 도구 (특히 IE8)에 중단 점을 넣기가 조금 어렵다는 것입니다. 디버깅에 어려움이 있다면 위에서 설명한 것과 동일한 마이그레이션 도구를 사용하여 CoffeeScript 코드를 사전 컴파일하지만 여전히 편리하지는 않습니다.

7. 자동 var삽입 또는 this팻 화살표 연산자 ( =>) 를 사용한 반투명 관리 와 같은 CoffeeScript의 다른 약속은 우리가 원하는만큼 많은 이익을주지 않는 것으로 나타났습니다. 우리는 이미 빌드 프로세스의 일부로 JSLint를 사용 ES3 x ES5-Strict하고 언어의 하위 세트로 코드를 작성합니다 . 어쨌든, Coffee가 동일한 종류의 “깨끗한” 코드를 생성한다는 사실 은 좋은 것 입니다. 모든 서버 측 프레임 워크가 유효한 HTML5 및 CSS3 마크 업을 생성하기를 바랍니다!

   CoffeeScript가 var키워드를 넣어서 많은 시간을 절약한다고 말하고 싶지는 않습니다 . 누락 된 var들은 JSLint에 의해 쉽게 잡히고 쉽게 고칠 수 있습니다. 또한 일단 수정하면 좋은 JavaScript를 자동으로 작성하기 시작 합니다. 따라서 커피가 이와 관련하여 실제로 그렇게 도움이된다고 말하지는 않을 것 입니다.

우리는 약 1 주일 동안 CoffeeScript를 평가했습니다. 모든 팀원들이 코드를 작성하고 서로의 경험을 공유했습니다. 우리는 새로운 코드를 작성하고 우리가 적합하다고 생각했을 때 기존 코드를 이식했습니다. 언어에 대한 우리의 감정이 섞여있었습니다.

일반적으로 개발 속도를 높이 지 않았지만 속도를 늦추지 않았다고 말할 수 있습니다. 타이핑 감소와 오류 표면 감소로 인한 일부 속도 향상은 다른 영역 (주로 도구 지원)의 속도 저하로 인해 상쇄되었습니다. 일주일 후 우리는 CoffeeScript의 사용을 의무화하지 않기로 결정했지만 우리는 그것을 금지하지 않을 것 입니다. 자유로운 선택이 주어지면, 적어도 지금은 아무도 그것을 사용하지 않습니다. 때때로 새로운 기능을 프로토 타이핑 한 다음 프로젝트의 나머지 부분과 통합하기 전에 코드를 JavaScript로 변환하여 더 빨리 시작하지만 아직 그 방법을 시도하지는 않았습니다.

답변