архитектура

Невозможно находиться в городе со зданиями Калатравы и не поделиться фоточками:

Давненько у нас не было «классических» эпизодов про то, как технически устроены известные сервисы и как там построена разработка.

Восполняем этот пробел эпизодом про ЦИАН. Если вы снимали, сдавали или покупали жилье в России — вы с ним точно сталкивались.

Как ЦИАН смог стать таким популярным, что случилось, когда они объединили два огромных бэкенда на .NET и PHP/Python и как они борются с мошенниками с помощью алгоритмов — узнаем у технического директора ЦИАНа Алексея Чеканова.

Слушайте и подписывайтесь: Apple, Google, Яндекс, Spotify, Castbox, Overcast, веб-версия.

Хорошая полемическая статья (aka trolling) на на тему «чем плох REST».

1. Переводить сложные операции на язык, в котором всего 4 глагола - то ещё развлечение.
2. В парадигме REST неестественно передавать изменения машины состояний, а это часто необходимо и ошибки на этом фронте могут быть фатальны.
3. Коммуникация ошибок и других особых состояний: «всегда HTTP 200 OK, а ошибка в теле» или придумаем свои коды?

https://medium.com/@pakaldebonchamp/rest-is-the-new-soap-97ff6c09896d

Мой вывод: парадигмы, правила и концепции - это наши рабочие инструменты. Не человек и дела для инструментов, но наоборот. Каждой задаче - свой инструмент. Черт, кажется это просится в инстаграм глубокомысленные цитаты. Сорян.

Сегодня я видел небольшой самодельный ERP (много мелких крудов типа оформления отпуска) на скале, с Кафкой и Кассандрой. Там есть блоги. На скале.

А вчера — высоконагруженное e-commerce решение с ядром на битриксе.

Не могу решить, что мне нравится больше 👀

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

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

Изменение архитектуры проекта при масштабировании. Обратите внимание на отличающуюся конфигурацию палок и брёвен.

Помните клиента, который делает стартап в одно лицо и уже напрограммировал два миллиона строк кода?

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

С таким я ещё не сталкивался — мы ставим клиенту задачи, а он их программирует!

Ну и классное рассуждение по мотивам исследования: автор цитирует классика Питера Науэра (того самого, который N в BNF), который говорил, что программирование — это создание ментальной модели задачи, предметной области, в которой мы работаем.

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

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

—

Удивительно, как теория переплетается с практикой.

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

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

Красиво!

Похвастаюсь. Делаем с Федей аудит одного крупного финансового сервиса. Сегодня был третий день встреч с техдиром.

Каждый фиолетовый прямоугольник — это довольно большой сервис (отдельный репозиторий), над которым работает своя команда.

На схеме примерно треть, а то и четверть всей системы. Базы по много терабайт, тысячи интеграций — вызывает уважение, да что говорить, восхищение, что всё это работает и приносит пользу и деньги. 😍

Составляем карту технологических зависимостей Медузы.

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

Посередине слева — полный список «пользовательских view»: то, откуда можно читать Медузу. Web, iOS, Android, Instant Articles, etc. 20 пунктов.

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

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

Где лучше составлять такие схемы? Я пока остановился на Scapple. Кстати, эта же компания уже много лет производит очень мощную программу для писателей Scrivener — ведь не всем писателям нравится WordStar.