@johan классическое определение Легаси - код, переданный от одного разработчика другому "по наследству".
Оно может быть и трехдневным.
@cauf А разве не смена архитектуры, языка и т.д.? Разработчик психанул, всё поменял, плагины остались?
@johan нет. Это ты про какую-то хероту написал. Смена архитектуры и языка - это фактически закрытие проекта и написание с нуля. Это никак не Легаси.
Сейчас под Легаси чаще называют проект с большим техдолгом.
@cauf @johan Чёто это "легаси" больше напоминает какое-то жужужу без определённого смысла
https://understandlegacycode.com/blog/what-is-legacy-code-is-it-code-without-tests/
@cauf @akastargazer Не погромист, но вроде верно написано: тебе не особо хочется разбираться, кода дофига, он запускается... Пишем обертку?
т.е. когда любители «доставлять ценность непрерывно», приветствуя постоянные изменения, выжрали почти все заложенные запасы гибкости с изменямостью исходный код и архитектуру решения.
в результате, любая попытка внести изменения в функциональность обходится уже в сотню раз дороже по человеко часам, чем было в начале проекта, в первых версиях. само по себе редактирование кода, внесения в него, обходится не так уж и дорого. но даже малейшее изменение в одной части начинает аукиваться проблемами в другой. и требуется много сил (человеко часов), чтобы внося изменения в кодовую базу по одним вопросам отловить и поправить проблемы появившиеся из-за этих изменений в совсем другой функциональности решения (продукта).
вот это вся ситуация — это смерть проекта/решения/продукта. единственный выход из ситуации — дробить проект на куски и переделывать каждый из них по отдельности — тупо переписывать.
в таком вот случае, те части, которые ещё не были переписаны, а другие уже вроде как переделаны — вот это и зовётся легаси.
фраза, которую ты цитируешь: «Сейчас все старее года уже легаси». повествует о том, что софт стали делать постоянно на ходу меняя требования к функционалу и при этом не желая вкладываться в соблюдение SOLID и других вещей при контроле качества исходного кода.
т.е. срабатывает два фактора в сумме приводящих к такому результату. с одной стороны, бизнесовая часть компаний очень хочет, чтобы под их дудку плясала разработка и заёбывает со всякими сиюминутными изменениями в требованиях.
с другой стороны, компании нанимают такой персонал в разработку, который про тот же SOLID читает лишь ради прохождения собеседований, но вот на практике нихера не применяет.
@erua Я, конечно, плюсану, но... Инкапсуляцию, перерузку — отменили? Позвать, что тебе надо, из старой библиотеки?
все системы изнашиваются, и в случае софта изнашивания происходят именно из-за внесения такого рода изменений. по-началу, в первой части жизненного цикла софтового решения можно спокойно вносить определённые изменения. если разработчики предусмотрели на этапе проектирования и реализации возможность внесения определённого класса и типа изменений. но всё течёт, всё меняется и наступают моменты требующие изменений, которые изначально не предусмотрены. но которые может выдержать архитектура и кодовая база.
сделав такое один-два раза без особых последствий для работоспособности системы бизнесовая часть компании начинает думать, а вдруг ещё раз прокатит, а потом давайте ещё раз, это важно.
как результат — изношенность софтового решения, в котором после таких изменений уже полным полно сложных не нужных ибыточных связей, нарушающих любой здравый смысл — это и есть система из подпорок и костылей.
и любая попытка заставить это работать определённым образом, через внесение очередных изменений, превращает отдел разработки в тебя, вскрывшего механические часы и пытающегося разобраться, что тут и как подкрутить, желая получить движение секундной стрелки через два деления в первой половине циферблата (между 12 и 6 часами) и через три деления, когда она движется во второй части (с 6 часов до 12).
@erua Ты сейчас описал все продукты Adobe, крому InDesign, который изначально сделан как фреймворк для плагинов. И весь DTP'шный софт туда же. А как они отрубили многопоточность в Premier и AfterEffects? Нахуй вам Rizen, многопоточность и вот это всио, будем считать на одном ядре.
