8 нарушений потоков в приложении, которых следует избегать

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

Нарушение потоков

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

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

Итак.

Варианты нарушения потоков

Спрут

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

На мой взгляд — это худший вид нарушения, потому что устранять такую проблему очень тяжело. Возможно, это как раз тот случай, когда нужно написать приложение с нуля. Да, чем-то это напоминает Redux 🤔, например.

Шлюзы

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

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

Близнецы

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

Каскад

Мое «любимое» нарушение. Означает бессмысленную «инкапсуляцию» кода. Особенно опасно, когда это происходит каскадно. Т.е. когда вы могли бы использовать компонент сущности напрямую, но вам необходимо его импортировать из другого компонента, а тот, в свою очередь импортирует его из другого компонента, а тот может еще откуда-то его брать. С каждым новым каскадом ваше поле зрения сужается, в итоге вы будете как будто разглядывать код через тонкую соломинку.

Но это еще не все. Пока вы проследите весь путь до целевой логики — вы уже забудете где вы, кто вы и что здесь делаете. Особенно, если нейминг файлов низкокалорийный, например — index.

Это нарушение хорошо перекликается с нарушением Закона Деметры. Изучите его обязательно. После того как дочитаете статью, разумеется.

Турбулентность

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

Гайды никто не читает, разработчики будут смотреть в код и повторять так, как уже написано. Если варианты реализации разные и разработчиков несколько — легко представить, сколько всего «интересного» может произойти. Отправлять ссылки на гайды коллегам так же бессмысленно, как пытаться учить детей не своим примером. Подавайте пример коллегам в виде своего хорошо написанного кода.

Хаос

Это нарушение означает, когда в приложении нет простых ламинарных потоков, от точки входа до самых маленьких конечных компонентов. Данные пытаются вклиниться куда угодно откуда угодно. Да, снова Redux и не только — какой-либо компонент не уровня страницы может заниматься парсингом адресной строки, или даже обновлять ее!

Успешно управлять такой структурой невозможно.

Монстр

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

Еще про такое обычно говорят — «Стрелять из пушки по воробьям». В разработке есть так же термин для этого — оверинжиниринг.

Представьте, что для водоснабжения небольшой деревни построено огромное водохранилище. Потрачено куча усилий и денег, но целое водохранилище — это же круто!

На мой взгляд, индивидуальные колодцы — более разумное решение.

Не пишите и не привлекайте сложные решения для реализации задач. Например, если вам нужно сделать страницу, которая показывает список чего-то — не устанавливайте хитрую библиотеку, которая может все — просто используйте fetch.

Пробка

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

r => a.id === b.item_id

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

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

Энергетические связи

А теперь перейдем к самому интересному. В начале я отметил, что расскажу про энергетические потоки, как они работают и как я их чувствую.

Давайте поясню.

В качестве примера возьмем нарушение типа Пробка. Скверный нейминг блокирует равномерное течение вашей мысли, заставляя установить соответствие используемых имен с их значениями. Следовательно для преодоления барьера потребуется больше энергии от мозга — выдавить пробку (понять смысл переменной). Да, они маленькие, но их много, они берут количеством.

Рассмотрим еще пример — Монстр. Огромная сложная конструкция для решения простой задачи. Обычно саму задачу в этом случае можно понять (выполнить) только разобравшись в том, как устроена эта конструкция. Представляете, сколько энергии вы потратите на это?

Еще пример. Турбулентность. На распутывание замыслов разнородных решений уйдет много времени и энергии. Энергия будет расходоваться на «раскодировку» смыслов, чтобы понять, действительно ли требуются разные варианты решения или нет. А может есть какой-то еще скрытый смысл, и так далее. В итоге вы потратите много энергии, но не получите практически никакого результата.

Уловили смысл? Все остальные нарушения так же бесполезно тратят вашу энергию, просто разными способами. Вы физически устаете от работы с кодом, прям вот физически, т.к. мозг должен будет тратить больше энергии, а энергия в организме — общая, для всех систем. Кроме того повышается раздражительность — так организм реагирует на огромную потерю энергии, которая дала минимум результата.

А еще, при скверной кодовой базе проект будет скверно работать и развиваться, что неизбежно обернется потерей интереса к работе. Мотивация будет стремительно снижаться.

Негативные эмоции

Еще, классификация нарушений потоков не только отличается технически, но и вызывает различные эмоции.

Взгляните на эту таблицу:

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

Хайлайты

💥 Код напрямую работает с вашей энергетикой через эмоции. Хороший код — дает ощущение вдохновения и потока. Плохой код — усталость и стремительное снижение мотивации.

💥 Нарушения потоков бесполезно тратят вашу энергию разными способами.

💥 Нарушение — Эмоция:

1. Спрут → Расфокусировка
2. Шлюз → Напряжение
3. Близнец → Скука
4. Каскад → Блуждание
5. Турбулентность → Растерянность
6. Хаос → Взрыв мозга
7. Монстр → Когнитивная перегрузка
8. Пробка → Раздражение

—

В следующей статье цикла «Потоки» мы рассмотрим, как устранять все нарушения.

Берегите себя и своих коллег!