VF
Вот разница миров и есть техдолг
Size: a a a
2021 November 09
VF
Придумавший название сам сказал что аналогия плохая, насколько я помню
VF
Надо было объяснить бизнесменам финансистам, зачем перед запиливанием новой фичи приходится переписывать предыдущий код
VF
Они понимали про деньги и им так и объяснили, но в целом это не очень правильная аналогия
VF
Можно отдать долг, только частично и только тогда, когда известен следующий функционал
VF
Т.е. надо рефакторить не после фичи, а перед следующей фичей
VF
Если я сознательно упрощаю, но норм зааорачиваю в интерфейс файлик вместо БД, то это не техдолг.
ММ
А как классифицировать ситуацию "воткнули костылей, чтобы сдать проект в срок (и не словить штрафов), а убирать костыли будем во время поддержки"? Известно, что костыли в ряде ситуаций приводят к проблемам (но заказчик про это не знает).
VF
Если код работает и не мешает добавлять новый функционал, то зачем его менять?
VF
Чтобы попытаться угадать как оно там будет в будущем?
ММ
Всё основное работает, благодаря костылям, но в редких известных случаях костыли боком выходят, и на длинной дистанции наверняка это у заказчика вылезет -- минус к репутации.
Так что, может, есть смысл этого не дожидаться.
Так что, может, есть смысл этого не дожидаться.
ММ
Ну да -- угадать, по сути. Ожидать худшего.
VF
Есть функция (мир) и ее апроксимация (код). Когда апроксимация начинает слишком сильно отклоняться, мы ее переделываем. Я бы так объяснил техдолг.
VF
Пытаться угадывать отклонение, такое себе
VF
Кое где можно, но обычно не нужно
VF
Пишите тесты и все будет хорошо
ММ
Вообще, кажется логичным, что прогнозировать изменение мира -- невозможно почти.
А что если инвестировать в такие изменения, которые в любой ситуации помогут реагировать быстрее? Например, упрощать, т.к. простое переделывать проще?
А что если инвестировать в такие изменения, которые в любой ситуации помогут реагировать быстрее? Например, упрощать, т.к. простое переделывать проще?
VF
Переделывать проще когда есть тесты, по моему мнению. Потому что любое (сложное/простое) выделить и удалить в целом не напрягает
AB
Вот именно поэтому большинству проектов нужно не больше микросервисов (усложнение), а больше тестов (переделывать проще).
ММ
Допустим, есть даже хорошее тестовое покрытие, но вносить изменения из-за (неоправданно) навороченной архитектуры (и костылей) всё равно тяжело. И это ядровая функциональность, которая в программе повсеместно используется. Почему бы заранее не упростить?
Может, грубый прогноз, всё же, выгоднее полного отсутствия прогноза (100% реактивность)?
(ответа не знаю)
Может, грубый прогноз, всё же, выгоднее полного отсутствия прогноза (100% реактивность)?
(ответа не знаю)