Доработка сайта: как не платить дважды за чужой код

Самое честное признание

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

У меня был ровно такой случай. Обратился старый клиент с задачей «на вчера»: парсер, который я собирал годом раньше, внезапно перестал работать. А он гонял данные сразу с трёх сайтов и раскладывал их в Битрикс по кастомному алгоритму. Разбираться в том, что писал сам год назад, было то ещё удовольствие.

И я тогда сделал не то, о чём просили. Просили починить — я починил, но заодно переписал всё на модули, почистил код, добавил защиты для стабильности и расширил обработку ошибок. Теперь, если где-то поломается вёрстка или ресурс решит, что парсить его больше нельзя, прилетает аккуратное уведомление в стиле «шеф, всё пропало, нужно адаптировать». В итоге и проблему закрыли, и продукт стал лучше.

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

Три способа заплатить дважды

Доработка сайта превращается в двойную оплату тремя путями. Все три я видел не по одному разу.

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

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

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

Что проверить до начала работ

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

1. Доступы. Домен, хостинг или сервер, репозиторий с кодом, база данных, панель CRM, ключи API платёжек и сервисов. Всё должно быть оформлено на вас. Если чего-то нет — это первая задача, а не пятая.
2. Исходный код целиком. Не «файлы с сервера», а история изменений. Без неё непонятно, что и когда менялось, и любая правка становится сапёрной работой.
3. Бэкап. До первой строчки правок — копия кода и базы, которую вы проверили на разворачивание. Не «где-то у хостера», а у вас.
4. Возможность развернуть копию. Проект должен запускаться отдельно от боевого. Если правки можно вносить только на живом сайте — любая доработка становится рулеткой.
5. Что вообще происходит при сбое. Кто узнаёт первым: вы, клиент или никто? Есть ли логи и уведомления? Чаще всего ответ — «никто и никаких», и это первое, что стоит поправить.

Аудит, который экономит бюджет

Дальше — короткая диагностика на несколько часов, после которой видно, латать или переписывать. Я смотрю на четыре вещи.

Структура. Разложено на модули или лежит одним куском? У того самого парсера после переделки появились модули, и следующая правка заняла в разы меньше времени — просто потому, что стало понятно, куда смотреть.

Обработка ошибок. Что происходит, когда внешний сайт сменил вёрстку, API отвалился, пользователь отправил кривой файл. Если ответ «ничего, оно молча ломается» — работа предстоит не по функциям, а по надёжности.

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

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

Когда переписать дешевле, чем латать

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

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

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

• Каждая новая функция стоит дороже предыдущей. Значит, вы платите за архитектуру, а не за функции.
• Никто не берётся оценивать правки. Если подрядчики отказываются давать срок даже на мелочь, код непредсказуем.
• Проект нельзя развернуть заново. Живёт только на том сервере, где стоит, и никто не знает почему. Это не проект, это артефакт.

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

Как ставить задачу на доработку

Три правила, которые снимают 90 % споров.

Отделяйте диагностику от лечения. Сначала платите за аудит и получаете письменный вывод: что сломано, почему, что предлагается. Потом решаете по деньгам. Смешивать это в один счёт — гарантия конфликта.

Фиксируйте критерий приёмки. Не «чтобы работало», а «заявка из формы попадает в CRM за такое-то время, дубли не создаются, при сбое приходит уведомление». Проверяемая формулировка — ваша защита.

Договаривайтесь на берегу о границе работ. Что входит в правку, а что уже новая задача. Всё, что не проговорено заранее, потом превращается в спор о деньгах — и это одинаково неприятно обеим сторонам.

Что дальше

Я в IT с 2014 года, партнёр AmoCRM и Битрикс24, и чужие проекты принимал не раз — и поднимал их, и переписывал, когда иначе было нельзя. Главное, что понял: доработка сайта почти никогда не про код. Она про контроль над собственным продуктом: доступы у вас, разворачивается заново, ломается громко и понятно.

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