​​Очень давно я рассказывал о важности инверсии зависимостей внутри приложения.

3 июня в 20.00 МСК OTUS проводит вебинар Dagger 2 для Android-разработчиков.

Казалось бы — где связь? Dagger 2 — это один из самых популярных DI-контейнеров для Android-разработки. На вебинаре будут побробно рассмотрены правильные способы работать с ним.

#проектирование #партнерский_материал

Опасное место

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

Многие языки (привет, TypeScript) не очень хорошо умеют сигнализировать о возможном отсутствии значения. Решение — явно указывать это в коде.

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

Стандарт Option включает в себя многое, что зачастую не нужно в реальных приложениях. А для фронтенда важен каждый байт. Поэтому я сделал минималистичную реализацию для TS/JS — nanoption (220 байт).

Почитайте, как использовать Option в вашем языке и попробуйте.

#проектирование #js

SOLID

Создавать приложения сложно. В первую очередь, сложно уследить за зависимостями внутри кода. Умные люди придумали способ делать это — SOLID.

Тематический доклад — Солидный код

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

Код протухает. С каждой новой фичей приложение становится сложнее, жестче. С этим процессом нужно бороться.

Хороший доклад об общих принципах и подходах в рефакторинге.

Рефакторинг — Где? Куда? Когда? Откуда? Почему? Зачем и Как?

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

Связанность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Solid

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

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

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

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

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

Напиши-дважды-дривен-девелопмент

В разработке есть культ правила «не повторяй себя». Считаю это одним из самых вредных советов.

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

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

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

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

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

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

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

Современный бэкенд для фронтенда на Node.js

Вчера посмотрел доклад про BFF на летнем HolyJS и очень кайфанул — классный обзор бекендов для фронтендов, решаемых задачи и возникающих проблем. Очень хотел им поделиться, но (почему-то) был уверен, что в паблик его еще не выложили. А оказалось, что выложили.

#фронтенд #проектирование

Дизайн-ревью

Я очень люблю код-ревью, свежий взгляд на написанный код — это отлично. Шаринг знаний, все такое.

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

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

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

Акторы

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

Делаю пет-проект, намеренно переусложняя архитектуру акторами, читатю статьи, смотрю доклады. Вот парочка прямо хороших:

+ Моя жизнь с актерами
+ Написание масштабируемых и временами распределённых систем

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

Я сейчас изучаю проектирование распределённых асинхронных систем. В рамках этого проекта посмотрел доклад «Алгоритмы консенсуса. При чем тут Node.is?» В нём Андрей Печкуров рассказывает про проблематику распределённых систем, CAP-теорему, алгоритмы консенсуса и подробно разбирает один из них.

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

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

DDD — это мастхэв при проективными приложений больше туду-листа.

Посмотрите классный вводный доклад об этой технике Просто о сложном — Domain Driven Design

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

Камрад Саша Беспоясов написал цикл статей про проектирование приложений на примере рисовалки деревьев.

https://bespoyasov.ru/blog/generating-trees-on-canvas-using-typescript-and-oop/

Прочитал с большим удовольствием, прочитайте и вы 🚀

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

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

Вот классный чек-лист, которые поможет понять возможные проблемы — Распределенные системы: что может пойти не так

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

На прошлой неделе Антон Шувалов в докладе упомянул, что чтобы научиться строить архитектуру фронтенда следует читать книги про архитектуру бекенда. Это очень хороший совет. Я не знаю почему, но все хорошие книги про проектирование систем написаны для бекендеров.

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

А теперь по делу. За это время прочитал Designing Event Driven Systems и кайфанул.

> Я уже давно копаю тему проектирования систем за пределами фронтенд-приложений. Мне кажется, с одной стороны, там много интересного и некоторые подходы можно адаптировать и перенять на фронтенде. А с другой, развитие технических скиллов вширь повышает мою ценность как специалиста.

Designing Event Driven Systems рассказывает о построении асинхронных распределенных систем. Причем, большенство примеров завязаны на конкретную технологию — Kafka. Сначала это показалось мне странным, но потом зашло. Круто, когда вместо абстрактных историй со схемами тебе дают конкретный пример системы и рассказывают как он устроен.

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

Запись сварилась 😱

Вчера я ходил на публичное собеседование по систем-дизайну на TechLead Crew. Моё первое «бекендерское» интервью. Хоть я его и провалил, все равно считаю опыт успешным.

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

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

#проектирование #собеседования #кейс

Пишите ощущения в комментарии 👇