Архитектор развития

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

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

Основные отвественности архитектора:
• определение концептуального технического устройства системы;
• умение сотрудничать в лидерами отдельных команд для выработки архитектурных решений;
• коррекция уровня автономности команд.

#микросервисы

На Хекслете вышла статья «Преждевременная оптимизация: абсолютное зло или иногда полезная практика?», в которой кажется все специалисты выразили завидное единодушие. Почитайте.

#общие_знания

Всех нас занимают вопросы: «Как стать лучшим инженером?», «Как расти профессионально?». На них в целом, похоже нет ответов. Зато можно попробовать изменить отдельные аспекты своей работы.

Хороший тематический доклад — Мерцание технологий, или Инжиниринг.

#softskills #рост

​​Зачитываюсь книгой про микросервисы, поэтому статей на этой неделе совсем мало 😢

+ Архитектура программного обеспечения переоценена, простой и понятный дизайн — недооценен — архитектура ПО не то, чем кажется, отличный обзор от Гергелия Ороса (чувак из Uber)

+ Понимание брокеров сообщений — вообще-то это книга, но на Хабре сейчас выходит ее перевод по главам, первая глава — хорошее введение в тему

+ Метапрограммирование в JavaScript и TypeScript — немногие разработчики пользуются приемами метапрограммирования, а это мощная концепция, которая может сильно упросить код

#дайджест

Я читаю много статей на английском, но почему-то не хотел их добавлять в дайджесты. Добавить?
anonymous poll

Да – 254
👍👍👍👍👍👍👍 92%

Нет – 21
👍 8%

👥 275 people voted so far. Poll closed.

Типизация

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

Но, к сожалению, в JavaScript-мире я не могу получить желаемого. Самый популярный инструмент типизации TypeScript дает мне статическую слабую типизацию. Плюс в нем довольно плохо работает вывод типов, очень мягкие правила проверки типов по умолчанию. Этого мало. Поэтому, я с интересом смотрю на альтернативные решения. Elm, Scala.js, PureScript — это все очень весело, но абсолютно бессмысленно. Слишком непопулярные решения, которые требуют менять кодовую базу.

Недавно наткнулся на Hegel.js — это статический типизатор, которые переваривает аннотации типов от TypeScript, но лишен его проблем. Если этот проект дойдет до продакшн-реди состояния, я обязательно возьму его в пару проектов. Доклад автора на HolyJS — Как и зачем я пишу свой статический типизатор.

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

#языки

Шрифты

Во фронтенд разработке есть две проблемы: подключение шрифтов и настройка CORS.

Вадим Макеева рассказал в докладе все о шрифтах в вебе: как их правильно подготовить (сжать, обрезать) и подключить. Смотрите его доклад со странным названием _ __ _____?.

С CORS все сложнее, пару месяцев назад осерчал и запилил мини-тред в твиттере.

#фронтенд

Как моделировать сервисы

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

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

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

Делить сервисы по ограниченным контекстам (понятие Эрика Эванса из книжки DDD) — хорошая идея.

Обычно, системы проще начинать создавать как монолитные, а потом разбивать на микросервисы. Это связно с ценой ошибки. Если система была неудачно нарезана на ограниченные конктесты, перекроить модули внутри монолита дёшево, а переделать микросервисы — дорого.

Сервисы не должны делиться по принципу «владения данными», лучше смотреть на бизнес-возможности.

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

#микросервисы

​​Суббота начинается с дайджеста статей. Насладжайтесь.

+ О 30-кратном увеличении параллелизма в Node.js — отличная история рефакторинга, который сэкономил компании 300 тысяч долларов за год;

+ Делаем HTTP-запросы, изящно деградируем (и ни единого разрыва) — хорошая статья про аккуратную работу с сетью;

+ Чем программирование сегодня отличается от программирования 20 лет назад? — очередное размышление на тему плачевного состояния нашей индустрии, но в этот раз справедливое.

И еще три англоязычные статьи:

+ Goodbye, Clean Code — Дэн Абрамов рассказывает когда нужно и когда не нужно делать код «чистым»;

+ How to move your project to TypeScript - at your own pace — статья о постепенном переводе приложения на TypeScript без большой единовременной траты времени;

+ who are you trying to impress with your deadlines? (перевод) — критика необоснованных дедлайнов, замораживания состава спринта, очень актуальная тема.

#дайджест

Собрал книги, которые считаю обязательными к прочтению в единый список с краткими описаниями.

https://read.kamyshev.me

Ставьте звездочки на гитхабе, присылайте пулл-реквесты — igorkamyshev/mustread.

Интеграция

При выборе языка общения сервисов нужно обратить внимание на следующие характеристики:
+ возможность вносить не-ломающие изменения в протокол;
+ независимость протокола от языка (технологии);
+ сокрытие деталей реализации сервиса.

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

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

#микросервисы

Какие софт-скилы нужны

Сейчас популярно мнение, что софт-скилы для разработчика супер-важны. Иногда, они даже важнее технический экспертизы. Есть две проблемы:
1. непонятно, какие скилы нужны;
2. непонятно, как их развивать;

Андрей Смирнов нашел интересный рецепт выбора самых важных навыков и сделал доклад The state of soft skills. Он классный, посмотрите.

#softskills

Сегодня дайджеста не будет, простите. Я в мини-отупске и не хотел его готовить. 🙄

Говорить в мире собеседника

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

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

Объясню на примере. Представьте, что человеку нужно сделать сайт, а он в этом ничего не понимает. Он нанимает специалиста и в какой-то момент интересуется, как продвигается работа. Ему отвечают:

> У меня возникли проблемы с модулем кеширования страниц в WordPress, почитал StackOverflow, там рекомендуют обновиться до PHP 7, тем более в нём появились декларации типов, которые очень полезны в разработке. Я обновил PHP, но из-за этого пришлось решать проблемы с новым механизмом обработки ошибок. К счастью, как раз сегодня закончил с этим разбираться и доделал главную страницу, двигаюсь дальше!

Что из этого понятно заказчику:

> доделал главную страницу, двигаюсь дальше!

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

Чтобы не совершать этих ошибок, можно пользоваться двумя приёмами:

1. Отвечать на вопросы максимально коротко, не погружаясь в детали. Собеседник при необходимости переспросит или уточнит важные ему детали.
2. В разговоре ставить себя на место собеседника и стараться оценить, будете ли вы ему понятны.

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

Заметил, что посты с конспектом книжки про микросервисы очень длинные. Напрягает?
anonymous poll

Нет – 187
👍👍👍👍👍👍👍 89%

Да – 23
👍 11%

👥 210 people voted so far.

Варианты интеграции

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

Популярный тип интеграции сервисов — совместное использование базы данных. Это плохой путь. Все клиенты знают устройство базы данных, можно легко нарушить ее и сломать всех остальных потребителей (повышается связность сервисов). Любая логика завязанная на изменение данных должна дублироваться в каждом сервисе (снижается зацепление).

Для синхронного взаимодействия сервисов есть много вариантов, два самых популярных — RPC и REST. RPC — отличный вариант, нужно только выбрать подходящую реализацию и не завязываться на конкретные технологии, клиентские библиотеки создавать легко. REST — тоже хорошо, но сложнее создавать клиентские библиотеки (если придерживаться REST-философии).

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

#микросервисы

​​Вот и джайджест.

+ СтрижПИ — в диком мире iOS-разработки новый фреймворк, обзор SwiftUI от Никиты Прокопова;

+ Композируй это — в ещё более диком мире Andoriod-разработки тоже новый фреймворк, снова обзор, снова от Никиты Прокопова;

+ Yarn 2 — с Prolog’ом и плагнплеями — краткий обзор революционного обновления классного менеджера пакетов для JS (в будущем, возможно вообще для любой экосистемы);

Пара статей на английском:

+ What I learned as a developer from accidents in space (перевод) — статья Андрея Ситника об ошибках космической индустрии, которые могут научить программистов чему-то полезному;

+ Writing JavaScript With Only Six Characters — история о волшебной системе приведения типов JS, которая позволяет сделать что угодно с помощью 6 символов;

#дайджест

Обретение навыков

Мне всегда казалось, что классическое программистское деление на junior-middle-senior достаточно бессмысленное: оно сильно разнится от компании к компании, конкретных критериев нет, часто превращается в инструмент вычисления зарплаты из опыта работы.

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

#рост

Общий код

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

#микросервисы

Джедайские техники

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

#softskills #сделывание