Всем доброго времени суток.

В данной статье я решил поделиться опытом, накопленным за многие годы работы во front-end`е. Как и все вы, я был молод и мечтал создать что-то бессмертное. Ах, как я был молод, и как же я был глуп. Ничего вечного не существует и всё рано или поздно умирает. Однако, можно создать то, что протянет гораздо дольше обычного и даже будет адаптироваться к изменениям какое-то время. Поэтому сегодня предлагаю поговорить о паттернах проектирования для front-end приложений, выборе технологий и о том, чего делать не стоит. В этой статье буду проводить много аналогий со строительной тематикой и причиной тому небезызвестная история: «Если бы программисты строили дома».

Из чего строить? 

Тут как бы все просто, но не всегда явно. Как говорится, давайте разбираться. Суперновые технологии с прорывными идеями сразу мимо. Вы меня спросите почему?  Так давайте пофантазируем на тему того, что вы взяли их в проект: через года полтора сам проект не получил поддержки сообщества, а его создатель забил на него. Вы остались с нерелевантным стеком, отсутствием возможности найти разработчиков для создания кода и дальнейшей поддержки проекта.  Нет обновлений, читай через два года у вас на руках старая коричневая субстанция. 

Посмотрим и на обратную сторону медали: беря сверхнадежное решение, которому много лет, вы обрекаете проект на скорый апдейт или умирание. Знавал я одну крупную компанию, которая использовала java 8. Мотивация звучала так: она надежна как швейцарский нож.  На минуточку, на дворе 2021 год и она устарела не только морально, но и технически (на момент написания, актуальной версией является java 17). 

Исходя из рассказанного делаем вывод, что выбирать следует нечто среднее: не новинку и не проверенный олдскул. Оптимальным выбором станет инструмент, имеющий 3-5 релизов, в зависимости от их частоты. Это смоук-тест на то, что создатель не забросил свое творение, старается его развивать и совершенствовать.  Если стек хорош, то за время выпуска релизов он обзаведется нормальной документацией, а быть может и комьюнити.  Как следствие, вам смогут помочь с вопросами. 

Будучи front-end`ами мы располагаем значительным многообразием стандартов и синтаксического сахара. Предлагаю брать за основу актуальный на сегодня ES, добавляя поверх TS.  Стандарт TS поможет с типизацией, спасающей от глупых ошибок, и с сокращением времени поиска по коду, если возникнет потребность. А сейчас на минуту отвлечёмся и займёмся поимкой поклонников Dart, пока они не завели любимую песню: «будущее уже наступило». Эти речи слышу с 2015 года, а реальность до сих пор отличается, и будет отличаться пока один из основных средств разработки фронта не переедет на него.

С фундаментом определились, кирпич выбрали, очередь за раствором.  Ох, какая ж тут конкуренция: тот самый случай, когда чем меньше, тем лучше! Чем больше зависимостей, тем больше рисков деградации “инструмента”, а также конфликтов, которые будут порождены. Хотя если без этого обойтись невозможно, рекомендую использовать те же правила выбора зависимостей, что и для Фреймворка.

Вангую: сейчас спросите про всякие обертки, типа ionic и ему подобных. Сразу скажу, что считаю это решением: “херак-херак и в продакшен”. Они работают медленнее, чем нативные приложения, и на выходе дают гораздо больше косяков, связанных с особенностью окружения.  На длительной дистанции это почти 100% выстрел в собственную ногу, поэтому категорически против.

Как строить? 

История зафиксировала множество случаев, когда, используя лучшие материалы, инженерные просчеты пустили все труды по причинному месту. Front-end не исключение: мало брать лучшее, надо еще уметь этим пользоваться.  

Всегда начинайте с понимания концепции приложения:

·         что оно будет делать?

·         для чего оно создаётся?

·         кто будет им пользоваться?

·         в каких условиях его будут использовать?

Чем больше вы соберете вводной информации, тем лучше. Вижу немой вопрос в ваших глазах: “Зачем?!”. Это из ряда: «Я разработчик, у меня есть ТЗ, по которому и работаю». На деле не совсем так, достаточно сравнить две ситуации: вы делаете документооборот исключительно для внутренних нужд банка, и, вы разрабатываете коробочное решение для массового рынка. Если есть возражения, предлагаю обсудить в комментариях.

Когда разберётесь с тем, для кого вы это делаете, и с какой целью, предлагаю заняться сбором информации для таблицы критериев с весовыми коэффициентными значениями.  Рассказываю, что в себя включает: перечень функционала, который должен быть, технические требования к проекту и коэффициент (насколько они важны для проекта). Действия простые, а на выходе получаете черновой вариант дорожной карты.  На основании этого эскиза, Вы уже сможете делать итоговый чертеж своего будущего Зиккурата.

Хотите удивлю? Даже имея чертеж, вы не выстроите свою твердыню. Вам, как минимум, потребуются технологии и методики. В нашем случае это prettier, линтер, и прочие правила стандартизации работы бригады. Помните, состав команды меняется, а документация остаётся, и ей обязательно следовать так же, как и технике безопасности. Они обе написаны кровью. 

Имея документацию на руках, первым делом следует её изучить. Да-да, даже если вы сами её написали. Прочтите с точки зрения человека, который видит её впервые. Если вы хоть раз видели план любого дома, то наверняка обратили внимание на раздел со служебной информацией. В нём содержатся данные где должен находиться сан. узел, проводка и прочее. Тот же принцип работает во front-end: вы должны понимать, что где находится и как взаимодействует.

Все видели на просторах интернета фото с унитазом на кухне? Если Вы не преследуете схожих целей, стоит в самом начале всё логически разнести по отдельным модулям.  Сперва создайте слой абстракции для работы с API, выставлением кук и прочей служебной бизнес логики. Представьте себе, что это подсобное помещение в частном доме и вынесите туда все коммуникации: управление светом, котельной, водой и прочим. 

Раковину используют, чтобы мыть посуду, никто не предпримет попытки уснуть в ней целиком (ваш кот не в счёт). Вот и компоненты на фронте должны быть максимально “глупыми”: заточенными под что-то одно. Если это модалка, то она должна показывать, что в неё что-то передали, и всё. Никаких проверок и дополнительных условий. В вашем арсенале есть сервисы, вот их и используйте.

В строительстве используют термин проверка качества. Например, сперва отливается 5-10 кубиков размером 15*15 см из каждого миксера, который приехал на заливку фундамента. Если в каком-то кубике появится трещина, всегда остаётся возможность определить и проверить бетон, привезённый конкретной фурой. В нашей профессии действует тот же принцип: нам тоже нужны тесты, для поддержания качества кода. Как вы знаете тесты могут быть не только на работоспособность, но и на производительность. 

Чего делать не стоит?

Главное, не старайтесь сделать что-то универсальное. Это касается как приложения, так и компонентов.

Истина вполне себе прописная: совмещение кухни и гостиной допустимы, а вот кухни и уборной - уже дурной тон. Вам требуется вывести в компоненте два разных шаблона вывода текста? Это допустимо. Если же Вы засовываете в компонент проверки или что-то ещё, то такие действия начинают дурно пахнуть. Вы доведёте ситуацию до того, что компонент будет перегружен и, как итог, пропадёт возможность его использовать, так как потребуется целая петиция, которая заставить его работать.  Лучше создайте отдельный компонент, который будет реализовывать заданный сценарий, чем скрещивайте ежа с носорогом. При наличии документации большое количество компонентов некритично, а вот непонимание кода и взаимодействия с компонентом да.

Не пренебрегайте правилами и не делайте исключений. Единожды сказав: «И так сойдет», оглянуться не успеете как доведёте проект до смерти, повторением таких исключений. 

Прежде чем что-то делать, задайте как можно больше вопросов: зачем; что это нам даст; как это следует реализовать?  Существует забавная практика «5W», в своё время её придумала компания Toyota. Принцип прост: чтобы обнаружить проблему, следует пять раз задать вопрос «Почему?». Если пять раз получить ответ на вопрос «Почему?», то причина проблемы и метод ее решения станут очевидны. Решение (или «Как?») обозначается как 1H. Таким образом, пять «Почему?» равны одному «Как?» (5W = 1H).  Придерживаясь такого алгоритма, вы поймете проблему.

Итоги

Подводя итог, предлагаю придерживаться здравого скептицизма. Если к вам пришел бизнес со словами: «У нас ж*па!», не спешите её исправлять. Возможно, проблема не в коде, а в его восприятии. На эту тему есть забавный анекдот:

«Сидят два железнодорожника - молодой и бывалый. Идёт им команда передвинуть вагоны на такой-то путь. Молодой подрывается. Бывалый ему:

- Сиди!

Дальше сидят, снова идёт им команда, передвинуть вагоны на другой путь. Молодой опять подрывается. Бывалый ему:

- Сиди!

Так сидели, было ещё несколько команд и последняя поставить вагоны туда же, где они стоят.

Бывалый говорит молодому:

- Вот видишь, что значит опыт!»

Так же зачастую и в жизни.  При создании приложения нет ничего вечного, вы можете только сделать его более устойчивым к изменению внешних факторов. Своим опытом как это сделать я поделился выше, остались вопросы: пишите в комментариях. И помните: самый глупый вопрос – тот, который не был задан. 

P.S. 

Мой опыт может отличаться от вашего. Не устану повторять: сначала думаем, потом делаем.  Помните: фронт должен быть ленив, он должен делать только то, что приводит к положительному результату. Цель этой статьи не заниматься вашим поучением, а лишь поделиться тем опытом, который у меня накопился.