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

Кто я такой, чтобы рассуждать о стратегии разработки?
Я в 1С с 1998 года. Прошел путь от программиста-внедренца во франчайзи, до руководителя и совладельца бизнеса, который эту автоматизацию потребляет. И - да, так тоже бывает - вернулся обратно в ИТ. Я закладывал архитектуру в системах, которые работают до сих пор и разгребал последствия решений, принятых за пятнадцать минут до дедлайна. Сейчас я, в роли "играющего тренера", проектирую и руковожу, не отрываясь от кода. Мой опыт - это 27 лет принятия решений, где каждая строчка имеет цену в деньгах и рисках. Я не претендую на истину в последней инстанции и не собираюсь никого учить "жить", на Инфостарте очень много умных и опытных людей, у которых можно много чему научится. Я просто делюсь своей системой координат - если хотите примените её на своей практике, возьмите что-то полезное, если нет просто не забивайте себе голову.

Эта статья родилась из диалога.

Недавно я опубликовал шуточный рассказ "История о том, как Вася Пупкин спас квартальный отчет Марьи Ивановны" - байку про легендарный отчёт на 11 000 строк и костыль 2014 года. Некоторые читатели узнали в этой истории меня. И они были правы: прототипом был я, но очень, очень давно, да и сама история получилась с изрядной долей художественного вымысла. В комментариях развернулась жаркая дискуссия: одни говорили, что "за такое браться нельзя", другие - что "иногда приходится". Этот спор и заставил меня сформулировать то, что я интуитивно применял все эти годы: чёткую систему, которая определяет, когда можно (и нужно!) "костылить", а когда это - преступление против будущего проекта.
 

Вступление: Два типа боли и один разработчик

В понедельник мне нужно за 2 часа исправить алгоритм, иначе Марья Ивановна не сдаст отчёт. В пятницу я начинаю проектировать новый механизм ценообразования для сети розничных магазинов, который будет жить не менее 10 лет. Это - два полюса нашей работы. И главный навык senior-разработчика - не умение быстро кодить или правильно проектировать. А точное знание, когда какой полюс выбрать.

Сегодня я покажу свою систему принятия этих решений.

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

• Разработчику выгоднее написать новый костыль или свой "правильный", как он считает модуль, чем разбираться в чужом, может быть даже legacy-коде.

• Руководителю проекта выгоднее закрыть задачу костылём в срок, чем выделить бюджет на рефакторинг.

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

Но на длинной дистанции проигрывают все. Статья - о том, как эту дистанцию пройти победителем.
 

Часть 1: Карта территории - три зоны ответственности разработчика

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

Зона 1: "Пожар" (Fire Zone)

• Что это: Срочное требование, блокирующее бизнес-процесс прямо сейчас. Баг в период закрытия месяца/квартала.

• Пример из жизни: "Не печатается ТОРГ-12 для отгрузки, машина стоит, клиент не доволен".

• Ключевой критерий: Стоимость простоя бизнеса (здесь и сейчас) заведомо выше стоимости любого будущего техдолга.

• Моё правило: Костыль не только допустим - он обязателен. Ваша задача - потушить пожар любой ценой. Но с одним железным условием: вы немедленно заносите это решение в реестр технического долга с меткой [FIRE] "разбором полетов" и сроком "обезвреживания".
   

Зона 2: "Ремонт" (Maintenance Zone)

• Что это: Эволюция или расширение существующей функциональности. Новый отчёт на основе старого, интеграция с новым API, доработка типового механизма.

• Пример: "Нужно добавить выгрузку в Ozon в дополнение к WB в уже работающий модуль".

• Ключевой критерий: Решение будет жить долго и часто использоваться. Ошибка дорога, но не катастрофична. Сложность кода мешает развитию.

• Моё правило: Рефакторинг перед расширением. Нельзя наращивать функциональность на кривой код. Сначала приводим участок кода в состояние "чисто и понятно", потом добавляем новое. Здесь важен баланс между качеством и сроком.
   

Зона 3: "Строительство" (Foundation Zone)

• Что это: Создание новой сквозной функциональности, ядра сервиса, миграции данных. То, что станет основой для будущих развитий.

• Пример: "Внедряем полный цикл планирования закупок с учётом сезонности и остатков с использованием ИИ".

• Ключевой критерий: Ошибка проектирования обойдётся в миллионы и годы переделок. Решение станет "позвоночником" бизнес-процесса.

• Моё правило: ПОЛНЫЙ запрет на костыли. Только проектирование, прототипирование, ревью кода. Здесь вы - архитектор, а не пожарный. Скорость вторична, правильность - первична.

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

Часть 2: Диагностика - 5 вопросов перед первой строчкой кода

Как определить зону? Я задаю себе пять вопросов. Ответы на них - и есть диагноз.

1. Вопрос на миллион: "Что случится, если это сломается через год?"
   Варианты ответа: 
   "Марья Ивановна позвонит и попросит пересчитать" → (Зона 1 или 2).
   "Остановится конвейер, будут простой и штрафы" → (Зона 3).

2. Вопрос на время: "Сколько человек будут это использовать и как часто?"
   Частота использования - это мультипликатор.
   Костыль для отчёта, который запустят 1 раз - это терпимо.
   Костыль в механизме ежедневного проведения документов для 100 пользователей - бомба.

3. Вопрос на связанность: "Сколько других процессов/модулей/отчетов от этого зависит?"
   Изменение в отчёте "Статистика посещений сайта" - это одно.
   Изменение в справочнике "Номенклатура" или документе "Заказ покупателя" - это другое.
   Чем выше связанность, тем ближе к Зоне 3.

4. Вопрос на живучесть: "На сколько лет мы это делаем?"
   Временный отчёт для проверки гипотезы? Можно и на скорую руку.
   Механизм расчёта зарплаты? Только фундаментально.

5. Вопрос на сложность: "Можно ли будет это выкинуть и переписать или это станет неубиваемым?"
   Самый важный вопрос. Если решение легко изолировать и заменить - риски ниже.
   Если оно "врастёт" в десятки точек системы - это Зона 3.
    

Часть 3: Инструменты - от быстрого хака до чистого кода

Для каждой зоны - свои инструменты и техники.

Для Зоны "Пожар": Техника "Изоляция и маркировка"

Цель: минимизировать ущерб от временного решения.

1. Изолируйте костыль: Вынесите его в отдельную внешнюю обработку, общий модуль с понятным именем (Костыль_Для_ТОРГ12_До_01012026).

2. Ярко пометьте: В названии и в заголовочном комментарии укажите: 
   // ВРЕМЕННОЕ РЕШЕНИЕ (FIRE). Причина: блокировка отгрузки. Удалить после: 01.01.2026. Автор: Иванов.

3. Настройте напоминание: Создайте задачу в вашей системе учёта на дату "удаления после".
    

Для Зоны "Ремонт": Техника "Санитарная зона"

Цель: улучшить код ровно настолько, чтобы безопасно его расширить.

1. Оцените объём: Выделите 30% времени от задачи не на новую функциональность, а на приведение в порядок только того кода, которого вы касаетесь.

2. Не переписывайте всё: Не нужно рефакторить весь модуль на 11 000 строк. Нужно сделать чистым и понятным тот фрагмент, в который вы добавляете новую логику.

3. Документируйте: Чётко опишите (хотя бы в комментарии), что теперь принимает и возвращает ваш переписанный метод.
    

Для Зоны "Строительство": Техника "Прототип в песке"

Цель: проверить архитектурную гипотезу до внедрения в боевую конфигурацию.

1. Сначала - концепция: Схемы, UML, список сущностей и их связей. Обсудите с коллегами.

2. Затем - прототип вне основной базы: Создайте внешнюю обработку или тестовую базу. Реализуйте ядро логики там.

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

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

Часть 4: Экономика решений - разговор с бизнесом на его языке

Самый важный навык senior-разработчика - переводить технические дилеммы на язык бизнес-рисков и финансов.

Пример неправильного диалога:

• Бизнес: "Нужно доработать этот сложный отчёт к четвергу".

• Разработчик: "Там плохой код, нужно долго рефакторить. Не успеем".

• Итог: Конфликт. Бизнес считает разработчика "тормозом".

Пример правильно диалога:

• Бизнес: "Нужно доработать этот сложный отчёт к четвергу".

• Senior-разработчик: "Я понимаю срочность. Давайте рассмотрим варианты:

  1. Быстро (20 часов): Сделаем костыль и закроем задачу к четвергу. 
     Риск: В следующем квартале, при изменении требований, доработка обойдётся уже в 80 часов (в 4 раза дороже), так как код станет ещё запутаннее. Также есть риск ошибки при следующем закрытии.

  2. Надёжно (50 часов): Выделим время на рефакторинг проблемного модуля, затем сделаем доработку. Займёт больше времени сейчас, но полностью снимет риски на будущее. Дополнительные 30 часов сейчас - это страховой полис от будущих 80 часов переделки и срыва сроков.
     С точки зрения совокупной стоимости, вариант 2 экономит нам 80 - 30 = 50 часов и устраняет операционный риск.
     Какой вариант утверждаем?"

Мораль: Senior-разработчик не говорит "нет" и не говорит на все "да".

Он говорит: "Вот цена (деньги/время) и вот последствия каждого варианта". 

Он перестаёт быть "исполнителем запросов" и становится консультантом по ИТ и технологическим рискам.
 

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

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

Помните как в фильме "Тот самый Мюнхгаузен"? (Ссылка на фрагмент). "С восьми до десяти - подвиг". Речь не о работе в выходные и не о фантастических историях. Речь о том, чтобы ежедневно выделять стратегическое время - не на тушение пожаров, а на то, чтобы их предотвращать, вытаскивая проект за волосы из болота рутины и неочевидных рисков. Это про инициативу, которая на порядок снижает будущие затраты, потому что вы видите слабые места системы раньше, чем они дадут сбой.
 

Часть 5: Проактивность - ваш главный "некоммерческий" раздел

Что такое "подвиг" в разработке? 
Это не про героизм и сверхурочные. Это про видение пробела, о котором бизнес ещё не знает и предложение его закрыть до того, как он станет проблемой.

Пока junior и middle ждут, когда их "пнут" задачей, senior сам создает себе и другим новые задачи - те, что повышают устойчивость, снижают риски или открывают новые возможности для бизнеса.

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

Как и когда совершать "подвиги"?

1. Не в ущерб основной работе. 
   Это не про работу по ночам.
   Это про выделение 10-15% вашего профессионального времени (как в Google) на улучшение системы, в которой вы работаете.

2. Предлагать, а не делать молча. 
   Сначала - короткое предложение руководителю или бизнес-владельцу: "Я вижу проблему X. Она стоит нам примерно Y часов/денег в год. Я могу решить её за Z часов. Давайте сделаем?".
   Вы не ставите руководителя перед фактом проблемы, вы вовлекаете в процесс и сразу предлагаете решение.

3. Считать и показывать выгоду. 
   Говорите не "я сделал такую крутую штуку", а "это решение сэкономит N часов в месяц отделу логистики" или "снизит риск штрафа от налоговой на K%".

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

Раз в месяц, раз в квартал, совершайте "подвиги" - уверяю вас бизнес это увидит, оценят и в долгу не останется.

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

Заключение: От интуиции к дисциплине - путь зрелости

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

Не через всеобщий контроль, а через дисциплину решений:

1. Чёткое разделение задач на три зоны: Пожар, Ремонт, Строительство.

2. Холодная диагностика пятью вопросами перед написанием кода.

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

4. Понимание, что наша работа - не просто в написании кода, а в принятии решений о том, какой код писать, а какой - нет.

История про Васю Пупкина и костыль 2014 года - это не анекдот. Это памятник Зоне "Пожар", где решение было правильным для того момента.

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

Архитектурный иммунитет - это не про идеальный код. Это про правильные решения в нужное время.

Это про то, чтобы к 2026 году не оказаться заложником своих же быстрых решений (костылей) 2024-го.

Разрабатывайте осознанно.

Выбирайте зоны мудро.

Другие статьи автора:

• Древняя УТ 10.3 (10.3.6.8) и маркировка товара: как обойтись без перехода на УТ 11.5 (мой практический опыт)
• Автоматическое обновление токенов Честного Знака в 1С: устраняем человеческий фактор
• Дубликатор кодов маркировки (КИЗ) DataMatrix: Расширение 1С с проверкой в Честном Знаке (копирует ЛЮБЫЕ КИЗы!)
• Маркировка остатков товаров на складе: Как сделать все быстро и без ошибок (мой практический опыт)
• Маркировка остатков в распределенной рознице: Как промаркировать более 100 тыс. товаров в нескольких десятках магазинов без хаоса и ошибок