Предыстория
Начинается новый проект, собрана смышленая команда человек так из 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) — это начинает пугать. Обилие выбора приводит к тому, что глаза постоянно метаются с одного синтаксиса на другой
В погоне за хайпом
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>
)
}
}
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 которых будет написано хипстерами на очередном псевдоязыке с огромным количеством синтаксического сахара. Как говорит моя девушка-врач: «Избыток сахара вызывает сахарный диабет»…
Комментарии (17)
aavezel
22.12.2017 15:42Как говорит моя девушка-врач: «Избыток сахара вызывает сахарный диабет»…
И вот такие врачи нас лечат… Сахар не вызывает сахарный диабет. Но сахар в крови является признаком сахарного диабета. Перепутана причина-следствие. Как, в общем, и в статье…
fimashagal
22.12.2017 16:13О, это же лучшая разновидность постов о том как всё плохо в javascript и что делать никто не знает, а за сим всё
Ashot
22.12.2017 22:54Причем описанное в посте к JS особого отношения-то не имеет.
По сути описаны проблемы в команде: не смогли договориться о style guide, не могут найти время на написание тестов и т.п.
ArsenAbakarov
22.12.2017 17:53код превращается в нечитаемую лапшу
ИМХО, такое ощущение сложилось об этой статье. Лапша какая-то.
staticlab
23.12.2017 02:03Программируя на javascript, мы теряем это преимущество…
В такие моменты особенно завидуешь разработчикам на других языках…Да хватит ныть. Не нравится — валите в другую технологию или вообще из профессии. На Хабре и так уже 100500 статей "Здравствуйте, я неосилятор Вебпака и Ес-Линта. Вы всё делаете неправильно. Покайтесь, ибо грядёт!" Если вы там у себя в команде не можете договориться и выработать свой стандарт кодирования, то чему вы хотите научить остальных?
Lure_of_Chaos
23.12.2017 20:21> чему вы хотите научить остальных?
Не писать подобные «статьи» на Хабр.
А на самом деле то, что язык (и платформа) позволяет делать многое и разными способами — это же прекрасно, свобода воли, и только сила воли нужна, чтобы остановить себя (и команду) на едином стиле.
Что еще лучше — язык развивается, развиваются инструменты.
Знаете, даже обилие хейтеров, таких, как ТС, свидетельствует, что все идет очень хорошо, ибо не критикуют только то, что никому не нужно…
yarkov
23.12.2017 04:11По-моему проблема разработчика на windows не должна касаться остальных. И если у него не выполняются хуки, то это лишь повод подумать и настроить все по-человечески. Ну и как сказали выше: что за команда, если 7 человек не смогли прийти к единому стилю?
И опять же кодревью при мердже. Можно ведь на этом этапе отсекать.VolCh
24.12.2017 14:44В какой степени среды разработки, тестирования и исполнения должны поддерживать разные версии разных ОС — проектное решение, в некоторых случаях — корпстандарт.
mark_ablov
23.12.2017 06:55Можно еще добавить pre-commit hooks, которые обязательно у какого-нибудь разработчика на Windows не будут корректно работать из-за особенностей path
Всё ок. Пользуюсь разными хуками, проблем пока не встречал. Правда пришлось малость пофиксить либу, которую использовал для установки хуков, но там буквально одна строчка для windows потребовалась.
RISENT
24.12.2017 11:16Критика — это хорошо, но конструктивное предложение решения проблемы — еще лучше.
Focushift
Сразу ставлю двойку за «фреймворк» React.
И проблема не в том что это «фреймворк», а в том что у этой библиотеки почти ничего нет, можно только фоточки и лайки нарисовать в соцсетях. Поэтому надо обвешиваться дополнительными либами и называть это все фреймворком.
skarppion101 Автор
Да, вы правы, описался. Под фреймворком я имел ввиду React в связке с другими библиотеками
pda0
Ну, вообще-то с разницей между библиотекой и фреймворком давно разобрались. :) Библиотека — расширяет возможности разработчика. А фреймворк — ограничивает. Так что дело не в дефолтной поставке, а в том, предписывает ли React определённые методы решения задач, вместо любых альтернатив или нет.
Поскольку сам я далёк от web-программирования (по крайней мере от фронтенда), то сами ответьте на этот вопрос и узнаете фреймворк он или нет.
VolCh
Интересное разделение. Я всегда различал по направлению потока вызовов:
— библиотеки ты вызываешь из своего кода
— фреймворки вызывают твой код