Магия

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

Есть два хороших маркера понятности системы:
+ Отсутствие внутреннего состояния. Если функция (класс, модуль) в работе основывается только на принятые параметры, его не только легко тестировать, но и проще понимать.
+ Разделение чтения и записи. Функция не должна возвращать что-то, если она изменяет внешний мир. И напротив, если функция что-то возвращает, то она не может мутировать ничего.

Пример неочевидного поведения — некотрые методы регулярных выражений в JS.

#архитектура

ФП

Функциональное программирование помогает избежать магического поведения системы.

+ Если все функции чистые, то они никак не могут иметь внутреннего состояния и всегда зависят только от своих параметров.
+ Если все структуры данных иммутабельны, то невозможно написать функцию изменяющую какие-то данные.

Функциональные подходы применимы почти к любой системе и всегда они повышают ее надежность.

#архитектура

​​Я уже писал о том, что любая система должна вести себя предсказуемо. Теперь о способах этого добиться.

Абстракция

Конструирование ПО заключается в создании модели какой-то части реального мира. И эта модель должна быть нарезана на слои — слои абстракции. Чем слой выше, тем ближе он к задаче, чем ниже — тем ближе к машине.

sendNotificationToUser — где-то на верхних слоях, а sendSms — много ниже, callSmsGateway — совсем внизу.

Правильный путь — выдерживать в одной программной единице (функции, классе, модуле) один уровень абстракции.

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

Такой подход позволяет читать код с меньшей нагрузкой на голову. Он становится предсказуемым.

#проектирование #архитектура

Микро-фронтенд

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

Сейчас вокруг многие обсуждают микросервисы на фронтенде. Значит немного странно, но, вероятно, нам это нужно.

Тематический доклад — Разрываем монолит.

#фронтенд #архитектура

Недостаточно красивой идеи

Redux — супер красивая концепция. Он прост, логичен и детерминирован. Но есть проблема — в реальном мире это не работает. И появляется куча шаблонного кода.

Mobx — не очень красив. Это утилитарная штука. Он не отрицает реального мира, а помогает с ним работать.

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

Если для достижения этих характеристик нужно пожертвовать красивой идей — нужно пожертвовать.

#softskills #сделывание #архитектура

Связанность

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

Крутейшний доклад Сергея Протько  «Связать и развязать».

#проектирование #архитектура

Красивый код — не рюшечки

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

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

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

#архитектура #проектирование

Красивый код — не рюшечки

Окей, для длинных проектов важна чистота кода. Как определить, что проект длинный?

Все просто. Есть два признака.

1. Проект длится больше месяца. Обычно известно заранее, сколько есть времени на проект. Если проект должен занять больше, чем 4 недели — он длинный.

2. Над проектом работает трое. В команде от трёх человек невозможно делить знания о всех костылях, значит нужно их избегать. Конечно, есть и тут ценз по длительности. Если проект занимает больше недели — это длинный проект.

Наша работа — не допускать длинных проектов с плохим кодом. Работать с ними не только сложно для инженеров, но и опасно для бизнеса.

#проектирование #архитектура

Solid

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

Способ писать хорошой объектно-ориентированный код описан в принципах SOLID, котроые сформулировал и описал в "Чистой архитектуре" Дядя Боб. Это прекрасная книга, которую должен прочесть каждый программист. Но она достаточно теоретическая, в ней мочти нет примеров хорошего кода.

Саша Беспоясов и Артем Самофалов сделали интерактивный курс про принципы SOLID, с примерами на TypeScript, тестами и автоматическими проверками. Если вы не чувствуете себя уверенно при проектировании приложений — пройдите этот курс.

https://ota-solid.now.sh/

#проектирование #архитектура

Микро-фронтенд

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

Сейчас вокруг многие обсуждают микросервисы на фронтенде. Значит немного странно, но, вероятно, нам это нужно.

Тематический доклад — Разрываем монолит.

#фронтенд #архитектура

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

Доклад в основном про C# (и немного F#), но сами подходы ценны в любой экосистеме.

#фп #архитектура

Сегодня утром посмотрел крутой доклад про архитектуру — Быстрорастворимое проектирование.

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

В докладе весь код приводится на C#, но подходы применимы к любому языку (с небольшими правками, конечно)

#проектирование #архитектура

Последнее время большую часть времени я работаю над платформой для развития фронтендов внутри Авиасейлс.

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

Посмотрел про это доклад «Как мы в Tinkoff принимаем архитектурные решения». Он довольно высокоуровневый, но как вводная лекция — просто отлично.

#архитектура