Библиотека сайта rus-linux.net
Processing.js
Глава 17 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: Processing.js
Автор: Mike Kamermans
Перевод: А.Панин
17.5. Выученные уроки
Наиболее важный выученный нами в ходе разработки библиотеки Processing.js урок заключается в том, что при портировании языка программирования важным является то, что в результате приложения работают корректно, а не то, идентичен ли используемый вашим портом код оригиналу. Несмотря на то, что синтаксис языков Java и JavaScript чрезвычайно похож и преобразование кода на языке Java в код на языке JavaScript достаточно просто, обычно следует обращать внимание на то, что можно сделать средствами самого языка JavaScript для получения того же функционального результата. Использование преимущества отсутствия типизации данных путем повторного использования переменных, использование определенных встроенных функций, которые быстры в JavaScript, но медленны в Java или пренебрежение шаблонами программирования, которые быстры в Java, но медленны в JavaScript, может привести к тому, что ваш код будет радикально отличаться, но работать абсолютно так же. Вам часто приходилось слышать от людей предостережения об изобретении колеса, но эти слова относятся только к тем случаям, когда используется один и тот же язык программирования. При портировании же следует изобретать столько колес, сколько понадобится для достижения требуемой производительности.
Другой важный урок заключается в том, что следует всегда завершать выполнение функций так рано, как это возможно и максимально сократить количество ветвлений. Блок if/then с последующим оператором возврата значения функции return может работать (иногда значительно) быстрее в случае использования вместо него конструкции if-return/return, причем в ней оператор возврата значения будет использоваться как условная ссылка. Хотя концептуально верным решением и является полное установление состояния функции перед возвратом результата выполнения этой функции, это также означает, что есть вероятность выполнения кода, который никак не относится к возвращаемому значению. Не теряйте циклы ЦП; возвращайте результат выполнения функции сразу после того, как у вас в распоряжении находится вся необходимая информация.
Третий урок касается тестирования вашего кода. В начале разработки библиотеки Processing.js мы воспользовались преимуществом наличии очень качественной документации, описывающей то, как язык программирования Processing "должен" работать, а также большого набора тестов, большая часть из которых в то время "неудачно выполнялась по известным причинам". Это обстоятельство позволило нам сделать две вещи: 1) разрабатывать код для прохождения тестов и 2) создавать тесты перед разработкой кода. В ходе обычного процесса разработки, когда разрабатывается код вместе с соответствующими тестами, на самом деле создаются предвзятые тесты. Вместо проверки того, выполняет ли ваш код необходимые действия в соответствии со спецификацией, вы проверяете только то, не содержит ли ваш код ошибок. При разработке библиотеки Processing.js мы начали создавать тесты, основываясь не на том, какие требования предъявляются к определенной функции или набору функций, а на документации для них. Обладая этими непредвзятыми тестами, мы можем разрабатывать функционально завершенный код вместо просто корректного, но, возможно, не функционирующего кода.
Последний урок является также наиболее общим: применяйте правила гибкой методологии разработки также и к отдельным исправлениям. Ни для кого не будет полезно, если вы начнете разработку и в течении трех дней не будете взаимодействовать с окружающими людьми, прорабатывая идеальное решение. Вместо этого приведите ваше решение в форме кода в работоспособное состояние, причем не обязательно для всех тестовых случаев, и попросите составить отчеты об использовании. Работая в одиночку и применяя набор тестов для устранения ошибок, вы не получаете гарантии того, что будет создан качественный и завершенный код. Никакое количество тестов не поможет вам узнать о том, что вы забыли разработать тесты для определенных частных случаев или о том, что существует лучший алгоритм по сравнению с тем, что вы выбрали, или даже о том, что вам необходимо поменять местами объявления для улучшения подготовки кода к JIT-компиляции. Рассматривайте исправления как релизы: представляйте общественности исправления как можно раньше, обновляйте их как можно чаще и превращайте отчеты об использовании программного компонента в усовершенствования.
Вернуться к началу статьи.