Comments 15
При оформлении заказа некорректно применялся промокод «ВЕСНА2025». Завели баг, разработчик нашел проблему, пофиксил, выкатил фикс — промокод заработал, все довольны.
Сделал фикс и не покрыл тестом, потому что тестов не было.
Через час прилетает сообщение из бухгалтерии: в новых заказах несоответствие между ценой на товар и оплаченной суммой. Параллельно в CRM — неверно рассчиталась скидка.
Ибо тестов на это тоже не было.
Идем к разработчику — он обнаруживает странный «костыль» в логике, влияющий на работу промокодов, и убирает его. Промокоды «восстановлены», но вместе с этим ломается расчет стоимости с учетом скидок — потому что вся логика «держалась» на этом самом костыле.
Стопудово нигде не было ни одного юнит-теста.
Всё снова повторится в ближайшие пару лет.
Все верно, тестов не было. Более того, в моем примере (он близок к реальному из моей практики) воркфлоу и регламенты разработки были в таком запущенном состоянии на проекте, что зачастую и ручной регресс не выполнялся.
А Вы типа контора-спаситель, которая все переписывает с нуля?
Всегда?
Типа "предыдущий разработчик - мудак"?
А Вы типа контора-спаситель, которая все переписывает с нуля?Всегда?
Странный вывод! Конкретно в данной статье описывается история, в которой заново сделать проект дешевле и целесообразнее, чем пытаться исправить текущий. Разумеется, это не относится к каждому проекту. Приходит новый проект - проводим тех. аудит и принимаем решение, по какому пути идем дальше. В практике всегда бывают случаи продолжения тех. поддержки и доработок без переработки с нуля, если архитектура и стек заложены изначально верно, тех.долг описан и поддается планированию его закрытия и поддержки.
Типа "предыдущий разработчик - мудак"?
В нормальной ситуации оценка разработчиков, в т.ч. и предыдущих, производится в другой плоскости. И в статье я привожу пример вполне нормальной и рабочей схемы, при которой MVP разрабатывается джунами-мидлами, с короткими сроками и малыми деньгами - это ни в коем случае не делает их "нехорошими людьми".
Я вот не могу распарсить вторую и третью цитату.
Для меня это один и тот же баг.
И промокоды 2 раза чинятся. В цитате 1 и 3.
Если сайт тормозит, и подрядчик из-за этого предлагает переписать сайт, то нужно менять подрядчика. Если подрядчик не может определить причину тормозов, то он не сможет избежать этой проблемы в будущем.
Две самые распространённые причины переписывания сайта это то, что менеджмент подрядчика хочет вытянуть побольше денег, а вторая в том, что разработчики подрядчика не умеют читать чужой код.
Чем эти переписывания оборачиваются в реальности: существующий сайт анализируют крайне поверхностно, не учитывают нюансов. Затем бюджет и сроки начинают поджимать, а какой-то специфический функционал не готов, в итоге свеженаписанный проект начинает обрастать костылями. Получается долго, дорого и плохо. Клиент не доволен, находит нового подрядчика, тот опять предлагает всё переписать.
Я не говорю, что ничего не нужно никогда переписывать с нуля. Но чаще всего это ошибочное решение.
Вы описываете ситуацию с новыми непрофессиональными и/или недобросовестными подрядчиками (я не просто так в чеклисте указывал про senior-архитектора). Тогда конечно смену подрядчика можно охарактеризовать фразой "шило на мыло". Чтобы этого не было, лучше всего в команде инхаус иметь порядочного и преданного делу технаря (чем выше скиллы тем лучше) - он бы помог менеджменту избежать описанной вами ситуации.
Если в компании есть возможность держать инхаус технаря, то это уже априори означает более высокий бюджет и возможность позволить себе более высокую культуру разработки. На деле же существует проблема у малого бизнеса, когда им бесконечно предлагают переписать их сайт, и они просто тратят деньги впустую. Я сам лично видел менеджера, который навязывал компании услуги, говорил, что надо переписать сайт, потому что у вас там то, то и то, и начинал описывать изъяны функционала, которого на сайте даже нет. То есть чувак даже не удосужился покликать страницы сайта, а сразу стал обрабатывать клиента по чек-листу.
А зачем сейчас вообще сайты? Все маркетплейсами же пользуются
Я сам лично видел менеджера, который навязывал компании услуги
либо это был менеджер по продажам, либо недобросовестный менеджер проекта с KPI на бюджетах проекта) если владелец продукта не понимает ничего в технике, а такому менеджеру "дать волю" - действительно может произойти впаривание ненужного и избыточного решения, к сожалению..
Статья ни о чём. Если хочется переписать, создать новый проект с нуля и есть ресурсы, можно зафигачить с нуля. Если хочется поддерживать старый проект, можно поддерживать старый, всё упирается только в желание и ресурсы(специалисты, деньги, время).
Судить, что подрядчик и его спецы некомпетенты потому что предложили создать проект заново думаю неверно, одни пойдут путём вышибания всей дряни из старого, развитие и поддержка старого проекта, потому что их менеджер так договорился, так увидил и ему так ближе с заказчиком, а другие пойдут путём,что они видят лучшее только во всём новом. Кто-то до блеска восстанавливает старые авто, вкладывая в них необходимые ресурсы и модифицируют(заменяют) морально устаревшие запчасти на необходимые новые, более подходящие, проходят испытания, регистрируют изменения, кто-то восстанавливает и поддерживает ретро стиль как оно есть, кто-то строит единичные новые машины, кто-то строит заводы которые штампуют новые машины. Как бы у всех разный уровень успеха, вложений и результат, но все в целом делают хорошие вещи.
Ценность автомобильной ретро-техники понятна - это история, эстетика и демонстрация инженерного таланта в условиях примитивности технологий и материалов. Только технике этой почетное место в музее, на выставках, либо исторических автопробегах/ралли. Мы же говорим о промышленной коммерческой эксплуатации в современных реалиях, с современными требованиями по производительности и безопасности.
Что касается ресурсов - нет ни одного проекта, который не упирался бы в производственные ресурсы. И любой владелец ИС всегда имеет цель оптимизации ресурсов на поддержку и доработки системы. Иначе он был бы неэффективен.
Скрытый текст
Зачем переписывать сайт с нуля?