Как стать продуктивным в Coffeescript?

Question

Я хочу улучшить свой стиль кодирования Coffeescript. Когда я программирую в Scala, я могу написать модуль через час или два, запустить его и иметь только несколько мелких ошибок, которые я могу быстро определить и исправить.

В Coffeescript я трачу примерно то же самое время, но в конечном итоге получаю ошеломляющее количество мелких ошибок, которые были бы пойманы статическими проверяющими типами, и мне приходится собирать, перезагружать браузер, проходить через некоторый код, добавить некоторые точки останова и т. д. Это беспричинный опыт и занимает значительно больше времени.

Труднее абстрагироваться и инкапсулировать функциональность из-за отсутствия интерфейсов и многих других функций OO.

Существуют ли шаблоны проектирования, которые заменяют инкапсуляцию/абстракцию, обычно предоставляемую OO? Или есть руководство/руководство о том, как думать в более удобном режиме (или как решать проблемы с использованием прототипического подхода)?

Что вы сделали, чтобы стать более продуктивным в Coffeescript (или Javascript - возможно, даже на любых динамически типизированных языках)?

Answer 1

Если вы исходите из статически типизированного, ориентированного на класс языка, такого как Java или Scala, изучение JavaScript/CoffeeScript будет проблемой. Компилятор не помогает вам почти так же, а это означает, что вам нужно минут, чтобы обнаружить небольшие ошибки вместо секунд.

Если это ваше основное узкое место, то я бы предложил использовать более простую методику кодирования. Используйте библиотеку, например, QUnit, чтобы написать небольшие тесты для каждой функциональности, которую вы разрабатываете. Используемый правильно, этот стиль дает вам те же преимущества, что и статический компилятор без ущерба для гибкости динамического языка.

Answer 2

Не переходите прямо к Журналу кофе. Изучите основные понятия из прототипа и Javascript OO. IMMO Вы можете учиться одновременно, но вы получите гораздо больше, если сначала получите Vanilla Javascript. Основываясь на моем личном опыте, синтаксический сахар Coffee Script для классов может быть ловушкой, если вы не понимаете прототипические наследования (легко застрять на ошибке).

Отладка Coffee Script до сих пор не полностью решена с точки зрения инструментов, единственный способ, которым я знаю, это сделать, это написать тесты (боль, когда вы только начинаете), или посмотреть на сгенерированный код (на по крайней мере, для более неясных ошибок).

Answer 3

Это было странно для меня; в моем случае, исходя из фона C/C++.

Что для меня щелкнуло, так это то, что вы можете значительно сократить время итерации с помощью нескольких настроек вашей рабочей среды. Идея состоит в том, чтобы уменьшить его достаточно, чтобы вы могли писать код в небольших кусках и очень часто тестировать свой код.

Об отсутствии проверки времени компиляции: Вы привыкнете к этому. Подобно значительным пробелам, отсутствие проверки типа времени компиляции просто тает через несколько недель. Трудно сказать, как именно, но, по крайней мере, я могу сказать вам, что это произошло для меня.

О недостатке интерфейсов: Это сложный вопрос. Было бы неплохо получить дополнительную помощь в более крупных системах, чтобы напомнить вам о внедрении целых интерфейсов. Если вы обнаружите, что вы действительно теряете много времени, вы можете написать свои собственные проверки времени выполнения и вставить их там, где это необходимо. Например. если вы зарегистрируете свои объекты с помощью центрального менеджера, это будет подходящее время для обеспечения того, чтобы объекты соответствовали роли, которую они представляют.

В общем, хорошо иметь в виду, что у вас есть способности приличного отражения.

Об отсутствии инкапсуляции: Учитывая, что coffeescript реализует очень хорошую оболочку класса для прототипа, я предполагаю, что вы имеете в виду отсутствие частных переменных? На самом деле существует несколько способов скрыть детали от клиентов, если вы чувствуете необходимость, и я это делаю; как правило, чтобы остановить себя от стрельбы по ноге в будущем. Ключ, как правило, заключается в том, чтобы сбежать от предметов в закрытых помещениях.

Также обратите внимание на Object.__defineGetter__/Object.defineProperty? В этих ситуациях может помочь многозадачность и сеттер.

О снижении итерационный время:

Я с помощью встроенного в файл сторожа в кофе, чтобы компилировать скрипты на изменения. В сочетании с возможностью TextMate сохранять все открытые файлы при потере фокуса это означало, что тестирование было связано с переключением с textmate на chrome/firefox и обновлением. Довольно быстро.

В проекте node.js, однако, я настроил свои представления только для компиляции и обслуживания на лету, поэтому даже наблюдатель файлов лишний. Они кэшируются в выпуске, но в режиме отладки они всегда перезагружаются с диска, перекомпилируются и, сталкиваясь с ошибками, я просто обслуживаю их. Итак, теперь каждые несколько минут я переключаюсь в браузер, нажимаю обновление и либо вижу, что работает тест, либо ошибки компилятора.