V
Зачем? Кому должен?
Менеджерам проектов
Size: a a a
2019 June 12
V
При этом проект может уже рабоать и полностю выполнять свою функцию без нареканий вообще - тогда его не дописывают и не рефакторят
Несколько раз прилетал на проекты с махровым Легаси. Это содом
N
Какое этому экономическое обоснование ?
повышение экспертизы команды. Не самое приоритетное, но достаточно важное мероприятие. Снижение рисков по использованию некого старого функционала, работающего как черный ящик. Сбор метрик работы этого черного ящика, выпил устаревшей функцинальности, в конечном счете экономия ресурсов.
V
Если не исправлять очевидные проблемы сразу, то это аукается дальше. А именно тем, что невозможно прогнозирование новых фичей и багов
V
Это до первой потребности поменять или добавить что-то. И вдруг оказывается, что тесты есть только интеграционные, coupling кода слишком высокий и тп
А если потребность не появится?
V
А если потребность не появится?
Тогда что это за проект?
V
Vyacheslav
Если не исправлять очевидные проблемы сразу, то это аукается дальше. А именно тем, что невозможно прогнозирование новых фичей и багов
Если эти фичи тоько будут связаны со старым кодом
V
Если эти фичи тоько будут связаны со старым кодом
Код неотделим
V
Vyacheslav
Тогда что это за проект?
В любом проекте есть части кода, почти не модифицируемы
V
Да есть. Но это пара процентов
V
Если мы говорим о Легаси, то это очень много непонятного недокументированного кода без людей, которые знают, что там написано
V
А если ещё и использованы старые методы разработки и сборки, то проще переписать
V
Да и банально опыта становится больше у разработчика. Появляются более верные мысли в голове, как это должно работать
AG
И что можно сидеть переписывать вместо того чтобы делать продукт для людей, ага)
V
И да и нет
r
А если потребность не появится?
Возможно, потребность не появляется как раз потому, что разрабам не хочется лишний раз туда лезть. То есть там могли бы появляться новые фичи, например, но их даже не предлагают, чтобы не вляпаться в "инициатива наказуема исполнением"
V
Конечно, тут промежуточный вариант
r
И что можно сидеть переписывать вместо того чтобы делать продукт для людей, ага)
В DevOps Handbook есть примеры такого
r
Про сайт магаза Macies и софт для принтеров HP
N
чем раньше обнаруживается проблема - тем меньше потерь бизнесу же. Проблемы можно устранять после того как они выстрелили или уменьшать проактивно риск их появления. Если это делать систематически - будет лучше не только старый код, но и новый. Просто за счет полученной экспертизы.