Есть ли жизнь без стандартов в JavaScript?
- суббота, 23 декабря 2017 г. в 03:14:08
https://habrahabr.ru/post/345326/
Начинается новый проект, собрана смышленая команда человек так из 7, намечен roadmap, согласованы сроки и бюджет ,- вроде бы все идет по плану, и счастью разработчиков нет предела. Так и слышны фразы: “Наконец-то не придется писать на (подставить angular 1, jquery, vanilla js) и можно будет использовать по-настоящему современные, модные и быстрые фреймворки! Вот в этом проекте все точно будет как надо: каждый метод будет задокументирован, 100% code coverage, CI интеграция, scrum с естимейтами, webpack, babel и стакан с реактовским смузи…” Все дружно хейтят старые глючные приложения, в которых никто толком не может разобраться, и восхваляют новое, которое, по их суждению, будет просто огонь. Знакомая ситуация, не правда ли? Но если вы хоть раз сталкивались с данным сценарием, то прекрасно и без меня знаете, что происходит через 3-4 месяца активной работы — да, современный дизайн, да, у нас react, да hot module replacement дико удобный и да, у нас flexbox и можно забыть о float left, но разве эти вещи делают продукт качественным? А как обстоят дела с документацией, тестами и прочим?
«Да там JSDoc некорректно работает с es7 декораторами. Запуск тестов в общем настроен, но сейчас у нас нет времени на их написание...» А от CI, в лучшем случае, используется только git hooks и автоматическая сборка. Но весь ужас лежит в папке /src/components… Зачастую, если в команде больше, чем один человек, код превращается в нечитаемую лапшу, так как у каждого разработчика есть свое уникальное видение “правильной” структуры и синтаксиса. Это ведет к тому, что код, написанный одним разработчиком, будет тяжел для поддерживания другим.
Можно сказать: «Но ты же можешь просто использовать фреймворк и следовать его гайдлайнам» — но в реальности картина обстоит еще хуже: фреймворки напротив поощряют возможность выбора. Разберем, как пример, один из самых популярных из них — React. У него это даже записано в плюсах! Несомненно, возможность легко заменить шаблонизатор или библиотеку для AJAX запросов — это хорошо и показывает гибкость архитектурного решения, но когда у нас есть возможность использовать старый es5 синтаксис, или JSX синтаксис, или же вообще компонент-функцию (functional stateless component) — это начинает пугать. Обилие выбора приводит к тому, что глаза постоянно метаются с одного синтаксиса на другой
Да, это один и тот же компонент. Он имеет документацию, компактен, и, вы не поверите, тесты тоже на месте, но проблема заключается совсем в другом… В других языках программирования, таких как Go или C# присутствует строгая последовательность частей кода. Например в C# вы всегда сможете встретить «using» в начале файла, во всех сторонних библиотеках и фреймворках. В Go всегда в начале присутствует название модуля и импорты. Разработчики на этих языках не меняют контекст и всегда работают с одной и той же структурой и синтаксисом. Программируя на javascript, мы теряем это преимущество… Многие из нас даже не видят проблему! Мы уже привыкли перестраиваться на typescript, чтобы расширить функционал библиотеки. Делать наследование с помощью lodash в другой. В третьей использовать старые «require» вместо «import». И при этом иметь основную часть кода в es6 и постепенно добавлять async/await потому что модно…
Несомненно можно использовать библиотеки для валидации кода (по сути то, что должна делать любая нормальная IDE), но для этого нужно скачать пару десятков мегабайт дополнительных npm пакетов, потратить кучу времени на чтение документации, грамотную конфигурацию, настройку и налаживания их работы. Можно еще добавить pre-commit hooks, которые обязательно у какого-нибудь разработчика на Windows не будут корректно работать из-за особенностей path. И, наконец, вишенка на торте — необходимость интеграции всего этого с webpack, к которому каждые полгода выпускают несовместимую версию. Да… В такие моменты особенно завидуешь разработчикам на других языках…
JavaScript набирает огромную популярность. Благодаря nodejs его уже добавляют в каждый второй умный чайник, микроволновку и холодильник. Вы можете купить умные стельки для обуви, SDK которых будет написано хипстерами на очередном псевдоязыке с огромным количеством синтаксического сахара. Как говорит моя девушка-врач: «Избыток сахара вызывает сахарный диабет»…
- Разработка веб-сайтов
- JavaScript
Предыстория
Начинается новый проект, собрана смышленая команда человек так из 7, намечен roadmap, согласованы сроки и бюджет ,- вроде бы все идет по плану, и счастью разработчиков нет предела. Так и слышны фразы: “Наконец-то не придется писать на (подставить angular 1, jquery, vanilla js) и можно будет использовать по-настоящему современные, модные и быстрые фреймворки! Вот в этом проекте все точно будет как надо: каждый метод будет задокументирован, 100% code coverage, CI интеграция, scrum с естимейтами, webpack, babel и стакан с реактовским смузи…” Все дружно хейтят старые глючные приложения, в которых никто толком не может разобраться, и восхваляют новое, которое, по их суждению, будет просто огонь. Знакомая ситуация, не правда ли? Но если вы хоть раз сталкивались с данным сценарием, то прекрасно и без меня знаете, что происходит через 3-4 месяца активной работы — да, современный дизайн, да, у нас react, да hot module replacement дико удобный и да, у нас flexbox и можно забыть о float left, но разве эти вещи делают продукт качественным? А как обстоят дела с документацией, тестами и прочим?
«Да там JSDoc некорректно работает с es7 декораторами. Запуск тестов в общем настроен, но сейчас у нас нет времени на их написание...» А от CI, в лучшем случае, используется только git hooks и автоматическая сборка. Но весь ужас лежит в папке /src/components… Зачастую, если в команде больше, чем один человек, код превращается в нечитаемую лапшу, так как у каждого разработчика есть свое уникальное видение “правильной” структуры и синтаксиса. Это ведет к тому, что код, написанный одним разработчиком, будет тяжел для поддерживания другим.
Но у нас же есть фреймворки
Можно сказать: «Но ты же можешь просто использовать фреймворк и следовать его гайдлайнам» — но в реальности картина обстоит еще хуже: фреймворки напротив поощряют возможность выбора. Разберем, как пример, один из самых популярных из них — React. У него это даже записано в плюсах! Несомненно, возможность легко заменить шаблонизатор или библиотеку для AJAX запросов — это хорошо и показывает гибкость архитектурного решения, но когда у нас есть возможность использовать старый es5 синтаксис, или JSX синтаксис, или же вообще компонент-функцию (functional stateless component) — это начинает пугать. Обилие выбора приводит к тому, что глаза постоянно метаются с одного синтаксиса на другой
В погоне за хайпом
Компонент 1
import React, {Component} from 'react'
import PropTypes from 'prop-types'
/**
* Person component is used to show the first name and last name of the user
*/
class PersonComponent extends Component {
static propTypes = {
item: PropTypes.object
};
static defaultProps = {
item: {}
};
render() {
return (
<div className="item">
<p>{this.props.item.firstName}</p>
<p>{this.props.item.lastName}</p>
</div>
)
}
}
Компонент 2
var createReactClass = require('create-react-class');
var PersonComponent = createReactClass({
/**
* Person component is used to show the first name and last name of the user
*/
render: function() {
return (
<div className="item">
<p>{this.props.item.firstName}</p>
<p>{this.props.item.lastName}</p>
</div>
)
}
});
PersonComponent.propTypes = {
item: PropTypes.object
};
PersonComponent.defaultProps = {
item: {}
};
Да, это один и тот же компонент. Он имеет документацию, компактен, и, вы не поверите, тесты тоже на месте, но проблема заключается совсем в другом… В других языках программирования, таких как Go или C# присутствует строгая последовательность частей кода. Например в C# вы всегда сможете встретить «using» в начале файла, во всех сторонних библиотеках и фреймворках. В Go всегда в начале присутствует название модуля и импорты. Разработчики на этих языках не меняют контекст и всегда работают с одной и той же структурой и синтаксисом. Программируя на javascript, мы теряем это преимущество… Многие из нас даже не видят проблему! Мы уже привыкли перестраиваться на typescript, чтобы расширить функционал библиотеки. Делать наследование с помощью lodash в другой. В третьей использовать старые «require» вместо «import». И при этом иметь основную часть кода в es6 и постепенно добавлять async/await потому что модно…
Но ведь можно что-то сделать, так ведь?
Несомненно можно использовать библиотеки для валидации кода (по сути то, что должна делать любая нормальная IDE), но для этого нужно скачать пару десятков мегабайт дополнительных npm пакетов, потратить кучу времени на чтение документации, грамотную конфигурацию, настройку и налаживания их работы. Можно еще добавить pre-commit hooks, которые обязательно у какого-нибудь разработчика на Windows не будут корректно работать из-за особенностей path. И, наконец, вишенка на торте — необходимость интеграции всего этого с webpack, к которому каждые полгода выпускают несовместимую версию. Да… В такие моменты особенно завидуешь разработчикам на других языках…
И в заключение
JavaScript набирает огромную популярность. Благодаря nodejs его уже добавляют в каждый второй умный чайник, микроволновку и холодильник. Вы можете купить умные стельки для обуви, SDK которых будет написано хипстерами на очередном псевдоязыке с огромным количеством синтаксического сахара. Как говорит моя девушка-врач: «Избыток сахара вызывает сахарный диабет»…