Comments 10
Добавьте еще "перерисуем", "проанализируем" и т.п. ))) примерно с тем же успехом все происходит
Это дань времени - слишком большой объём задач и они слишком разные. Желание везде успеть и усидеть на всех возможных стульях, потому что нет гарантии, что одно основное дело выгорит приводит к подобному - галопом по самым верхушкам. Что-то иногда действительно получается, но основной объём работ "на корзину".
Всё упирается в финансирование. Деньги на проекты или покупки не свои, а как правило заёмные или от инвесторов - а им нужно постоянно улыбаться и показывать, говоря, что всё отлично и скоро они получат дивиденды. Относительно спокойная работа остаётся сейчас наверное только у ремесленников и в некоторых странах в научной среде. Госсектор, например, это самый яркий пример такого поверхностного отношения к проектам со своим бюджетом. Дали - осваивай любой ценой. Ври, нанимай индусов, делай что хочешь, но трать предоставленное иначе в следующий раз не получишь. Это современная данность, реалии. Так есть.
Всё верно важные три вопроса: Кто? Когда? За чей счёт?
Договоритесь в команде: как только долг выходит за лимит — ставим фичи на паузу, идём чистить.
Не работает. Сегодня всегда все согласны, а завтра - некогда.
Единственный способ - еще на стадии mvp оценить риски этого техдолга (да, ИСО 31000, COSO и пр. в помощь). То есть все сразу должны понимать как должно быть (BDUP. Проектирование на порядок дешевле реализации и исправления) и как делаем сейчас (MVP), в чем разница (ограничения), сколько она стоит (хоть в попугаях), когда (зависимости) и для кого именно - долг он всегда персонален. Если при долге отсутствует конкретный должник, то вас кинули. То есть, да, "выплата" техдолга должна сразу иметь подробный план, а целевое решение запроектировано еще до MVP.
час на тесты сегодня = неделя экономии завтра
CapEx (час на тесты сегодня, до запуска в прод) часто гораздо дороже Opex-a (неделя завтра, во время работы в проде), а "свой" час всегда дороже "чужого". Завтра (сопровождение, развитие) - это уже "чужие" для РП (для "внедряев") время и деньги, даже если это один и тот же человек, не говоря о той же команде. Ценить чужое время - это культура. Культура - это правила (в т.ч. неписанные). Если ваши правила, паттерны и фреймворки не соблюдаются, то вы неправильно оценили степень зрелости команды. Глупо ожидать, что племя попуасов, если их заставить выучить фреймворки и регламенты, построят космическую ракету.
Зачем что-то переписывать? Чтоб красиво было? В топку перфекционистов - они не добиваются успеха, так как нет предела совершенству. Пишите гавнакоды и в продакшн.
Есть оборотная сторона медали: "мы все сделаем правильно, нагрузку будет держать любую, все покроем автотестами и полным CI/CD включая 0-downtime updates".
Проблем тут три
за чей счет банкет
завтра идеально будет ненужно, надо как то рабоче но сегодня
бизнес не знает стрельнет ли стартап. А если стрельнет, угадал ли бизнес с направлением, скоупом, целевой аудиторией и тд, или же станет ясно что надо срочно на коленке скорректировать направление развития продукта похоронив все архитектруные изыски.
Так шо тут надо балансировать между сциллой и харибдой. Говнокод в стартапах неизбежен(если конечно нет бесконечного бюджета). И остановиться после получения инвестиций для "переписывания всего" тоже невозможно. И если продолжать говнокодить то неизбежно все посыпится.
Альтернатив кроме управления техническим и архитектурными долгами найти сложно. Для начала их надо вести в явном виде, показывать бизнесу и обьяснять почему конкретно вот этот долг мешает и почему его фикс поможет нам в будущем. Договариваться о том что какой то % времени будет уходить на рефакторинг. Идеал недостижим, главное чтобы долг был управляемый.
Ха-ха. Однажды надо было сделать демо, в старой кодовой базе на PHP и нейтив JS, руками стажёра, а потом реализовать в новом проекте с нуля, на nestJS и Vue.
В общем, демо работало три года почти основным продуктом, пока с двух попыток смогли переписать с нуля и почти мигрировать на новую платформу...
Эта фраза настолько универсальна, что применима к любой сфере и, да, применяется. Когда я такое слышу, уже просто молча улыбаюсь и киваю) Просто нет надобности делать то, что обсуждается )
Инвестор платит за результат. Если риски не описаны для него, то это очень безответственно. Об этом в том числе писал дядя Боб долго и нудно, подчёркивая что в ином случае это не профессионал. Действительно, это так безответственно и непрофессионально вводить в заблуждение или не сообщить о рисках и цене рисков для инвестора, который тратит огромные деньги. Это похоже на неопытность и неспособность просчитать риски. Именно просчитать, а не просто нудеть, что это нехорошо. Что значит просчитать ? Сообщить, что стоимость фичи через год будет стоить в ~3 раза дороже, что поддержка кода в течение 3 месяцев станет равна стоимости разработки с нуля. В цифрах, в деньгах. Если это сложно посчитать, скорее всего нет опыта.
Техдолг бывает разный, но неправильная архитектура, несоблюдение паттернов - это не про тех долг, это отсутствие опыта. Для сеньора с опытом это все не требует значительных затрат времени, он попросту не умеет по другому уже.
Сделайте архитектуру такой, чтобы её можно было расширять без боли.
А кому больно? Вам, или бизнесу, который понял, что это КОГДА-ТО в невероятном будущем может стать проблемой, а значит, не о чем беспокоиться? Ему есть о чем беспокоиться, он может не выжить. Ваша боль может подождать, особенно если она условная.
А когда ему приходит время загнуться — ну да, бизнес загнётся. Вам-то чего, если вы не бизнес? Они деньги уже заработали, проект удачный, раунд, всем до свидания. И да, они будут говорить, что прекрасный проект загнулся только потому, что «программисты все сделали плохо, впрочем, как всегда…» Но к вам это всё уже не относится, вам надо искать новый бизнес, которому нужны программисты.
Заметили, что ИИ замечательно решает задачу бизнеса, а не программистов? Надо малыми затратами, максимально быстро выкатить максимально просто работающий проект, good enough чтобы показать его инвесторам — и он сделает. Если всё будет ок, то когда-нибудь позже, в следующей жизни можно будет подумать о том, чтобы найти программистов, которые будут всё переделывать — ну так им же нравится в коде копаться?! Вот пусть копаются. Тестировщикам же нравится работать по 12 часов и по выходным перед каждым релизом — ок, мы им пиццу дадим, пусть пожрути объяснят, почему эти неряхи пропустили баги. Всё нормально, всё как всегда.
Почему «мы потом перепишем» — это самая дорогая ложь?