#технический аудит

Прикольно, как меняются технические аудиты.

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

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

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

А дальше подключаем этот репозиторий к Claude code и задаем вопросы по проекту: «как устроена логика ценообразования», «на что повлияет изменение параметра Х», реестр рисков и так далее. Ответы проверяют живые инженеры — так мы оцениваем качество нашей базы знаний.

—

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

Эту базу знаний будут использовать не только для этого рефакторинга, но и для онбординга новых специалистов.

—

Через 4 недели работы, мой архитектор взял 2 недельный отпуск. Мы дадим свои рекомендации и закончим аудит уже после его возвращения.

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

—

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

—

Делюсь тремя файлами: Claude_md — общие правила игры для модели, а ещё файлы с целями и принципами этого аудита.

Тот момент, когда позвали проанализировать компанию и дать отчет по очень конкретным техническим вопросам, и в ходе интервью я выясняю, что организация тратит 6 млн долларов в год на систему, которая стоит максимум миллион (3% бюджета). 🤔

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

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

Я сначала написал: «а вот если бы у финдира в сейфе в запечатанном конверте были бы ключи доступа и инструкция по входу…».

Но это попытка вернуть иллюзию контроля. Мол, «вот если бы это сделали — то не оказались бы в подобной ситуации».

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

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

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

Через 3-6 лет в компании уже 50 разработчиков. Продукт при этом практически не развивается, фичи доставляются разработкой в продакшен со скорость улитки. Добавьте к этому зарплаты разработчиков в 100-400 тысяч в месяц и вы можете представить, что чувствует бизнес. Почему так?

А происходило вот что: все эти годы, каждый раз, когда нужно было выбрать между «сделать фичу побыстрее прямо сейчас» и «сделать так, чтобы это можно было потом поддерживать, пусть и подольше прямо сейчас» — бизнес с разработкой вместе выбирали первый вариант. Логично, что рано или поздно гора неподдерживабельного кода становится слишком высокой и уже никто не может докинуть ещё что-то сверху.

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

В общем, искать виноватого смысла нет, а варианты решений следующие:

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

2. Если же вам нужно развивать то, что есть — то впереди вас ждут пот и слёзы.

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

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

Организационно, вам придётся выделять на это адское количество времени и сил. Речь о 30-50% времени ваших инженеров. Результаты, в плане увеличения скорости разработки, вы увидите через месяцы в лучшем случае. Другого пути я не знаю.

Также, имеет смысл добавить в команду новых опытных бойцов. Дело тут не только в технической компетентности, но и в отсутствии психологических «долгов», свежести и незамутненности взгляда, в четком мандате на перемены. Желательно, чтобы человек уже имел опыт подобного рефакторинга.

В общем, это — путь смелых.

—

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

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

Новости бизнеса: договорились cделать аудит крупного клиента. Индустрия, о которой я давно мечтаю, и задача интересная — будет о чем рассказать детям потом. Ну и вам похвастаться.

Это корпорация, так что всё согласуется-пересогласуется. На последнем этапе, договор заметил генеральный директор и чуть не завернул буквально формулировкой «что это за Федя и Самат и зачем они нам нужны?!». Пришлось объяснять. Контрагент предлагает переименоваться в ООО «Техэкспертиза». Говорит, так будет меньше проблем.

Завести второе юрлицо, специально для работы с корпоратами? 🤔

P.S. В чате советуют «МосГлавТехЭкспертиза»! 🎩

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

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

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

Готовил вчера отчет по техническому аудиту для одного нашего клиента. Хочу поделиться с вами абзацем, где мы объясняем трудности программирования на пальцах:

… «Лапша в бизнес-логике». Бизнес-логика в приложении — это цепочка вызова команд. Эти цепочки часто содержат больше 7 шагов. Это больше, чем человек может уместить в голове. Чтобы решить эту проблему, люди описывают цепочки в одном месте, последовательно: одна строчка — один шаг бизнес-процесса (пример на руби). В нашем проекте, сейчас, это не так. Логика бизнес-процессов кочует из файла в файл. Пример: … — в попытке отследить бизнес-логику платежей мы «прыгнули» по коду 11 (!) раз. Это бесчеловечно. …

Мне очень нравится, что мы с Федей привлекаем экспертов себе в помощь. Я уже писал об Антоне Давыдове, но если вдруг пропустили — вот его канал в телеге. Кайфую каждый раз, когда делаю что-то вместе с Антоном.

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

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

Теперь с нетерпением жду новостей Forbes.ru о запусках. Меж тем, они расширяются, ищут хорошего бэкендера на пыхе, аналитика и smm-щика. Хотите работать в медиа с хорошей продуктовой командой, дельным руководством и офисом рядом с Белым домом? Пишите Наташе на pushkina@forbes.ru