Legacy код что это: терминология — Что такое legacy code?

Кофе-брейк #20. Что такое legacy-код и как с ним работать. Инструменты, которые облегчают написание технической документации

Что такое legacy-код и как с ним работать

Источник: Dou
Рано и поздно программисту наверняка придется встретиться с legacy-кодом. Чтобы облегчить последствия этого знакомства, я подобрал несколько практических советов и примеров из собственного опыта — в частности, работы с унаследованной Java-системой.

Особенности legacy

Legacy (наследство) — это чужой код, который часто бывает ужасен настолько, что оказывается вообще непонятно, как с ним работать. И если вам придется работать с legacy-системой, кроме старого кода вы также встретитесь:

• с устаревшей технологией;
• неоднородной архитектурой;
• недостатком или даже полным отсутствием документации.

На самом деле, legacy-код — это не так уж страшно, и вот почему: если система жила все эти десять лет и до сих пор работает, значит, какой-то толк от нее есть. Может быть, она приносит хорошие деньги (в отличие от вашего последнего стартапа). Кроме того, этот код относительно надежен, если он смог так долго выживать в продакшене. Поэтому вносить в него изменения нужно с осторожностью.
Прежде всего, нужно понять две вещи:

1. Мы не можем неуважительно относиться к системе, которая зарабатывает миллионы, или к которой обращаются тысячи людей в день. Как бы плохо она ни была написана, этот отвратительный код дожил до продакшена и работает в режиме 24/7.

2. Раз эта система приносит реальные деньги, работа с ней сопряжена с большой ответственностью. Это не стартап в стол, а то, с чем пользователи будут работать уже завтра. Это подразумевает и очень высокую цену ошибки, причем дело здесь не в претензиях клиента, а в реальном положении вещей.

Обратный инжиниринг

Для успешной работы с legacy-кодом придется пользоваться приемами reverse engineering. Для начала, нужно внимательно читать код, чтобы точно понимать, как именно он работает. Это обязательно, ведь документации у нас, скорее всего, не будет. Если мы не поймем хода мыслей автора, будем делать изменения с непредсказуемыми последствиями. Чтобы обезопасить себя от этого, нужно вникать еще и в смежный код. И при этом двигаться не только вширь, но и вглубь. Откуда вызывается метод с ошибкой? Откуда вызывается вызывающий его код? В legacy-проекте «call hierarchy» и «type hierarchy» используется чаще, чем что-либо еще.
Придется провести много времени с отладчиком: во-первых, чтобы находить ошибки, и, во-вторых, чтобы понять, как все работает. Что касается документации, не лишним будет прибегнуть к промышленной археологии. Очень полезно бывает откопать где-нибудь старую документацию и поговорить с теми, кто помнит, как писался доставшийся вам код.
Используя эти приемы, рано или поздно вы начнете более или менее понимать код. Но чтобы ваши усилия не пошли прахом, вы должны обязательно сразу же документировать результаты своих изысканий. Для этого я советую рисовать блок-схемы или диаграммы последовательности (sequence diagrams). Конечно, вам будет лень, но делать это точно нужно, иначе через полгода без документации вы сами в этом коде будете копаться как в первый раз.

Не переписывайте код

Самое важное в процессе разработки — вовремя бить себя по рукам и не пытаться переписать весь код заново. Прикиньте, сколько человеко-лет для этого потребуется. Вряд ли заказчик захочет потратить столько денег на переделывание того, что уже и так работает. Это касается не только системы в целом, но и любой ее части. Вам, конечно, могут дать неделю на то, чтобы во всем разобраться, и еще неделю на то, чтобы что-то исправить. Но вряд ли дадут два месяца на написание части системы заново.
Вместо этого реализуйте новый функционал в том же стиле, в каком написан остальной код. Иными словами, если код старый, не стоит поддаваться соблазну использовать новые красивые технологии: такой код потом будет очень тяжело читать. Например, вы можете столкнуться с ситуацией, которая была у нас: часть системы написана на Spring MVC, а часть — на голых сервлетах. И если в части, написанной на сервлетах, нужно дописать еще что-то, то дописываем мы это так же — на сервлетах.

Соблюдайте бизнес-интересы

Нужно помнить, что любые задачи обусловлены, прежде всего, ценностью для бизнеса. Если вы не докажете заказчику необходимость тех или иных изменений с точки зрения бизнеса, этих изменений не будет. А для того, чтобы убедить заказчика, вы должны попробовать встать на его место и понять его интересы. В частности, если вам хочется провести рефакторинг только потому, что код плохо читается, вам не дадут этого сделать, и с этим нужно смириться. Если совсем уж невмоготу, реорганизовывать код можно по-тихому и понемногу, размазывая работу по бизнес-тикетам. Либо убедить заказчика в том, что это, например, сократит время, необходимое для поиска ошибок, а значит, в конечном итоге сократит расходы.

Тестируйте

Понятно, что тестирование необходимо в любом проекте. Но при работе с legacy-системами тестированию нужно уделять особое внимание еще и потому, что влияние вносимых изменений не всегда предсказуемо. Тестировщиков потребуется не меньше, чем разработчиков, в противном случае у вас должно быть все просто невероятно хорошо с автоматизацией.
В нашем проекте тестирование состояло из следующих фаз:

1. Верификация, когда реализованный функционал фичи проверяется в отдельной ветке.
2. Стабилизация, когда проверяется ветка релиза, в которой все фичи слиты вместе.
3. Сертификация, когда все то же самое прогоняется еще раз на немного других тест-кейсах в сертификационном окружении, максимально приближенном к продакшену по характеристикам железа и конфигурации.

И только после прохождения всех этих трех фаз мы можем делать релиз. Кто-то наверняка считает, что сертификация — лишняя фаза, так как на стадии стабилизации все уже выяснено, но наш опыт говорит о том, что это не так: иногда во время регрессионного теста, который прогоняется по второму кругу на другой машине, что-нибудь да вылезет.

Формализуйте DevOps и релиз

Релизная процедура может быть, например, следующей. Когда заканчивается разработка и пройдены две или три фазы тестирования, мы пишем письмо DevOps-команде за 36 часов до предполагаемого времени релиза. После этого созваниваемся с девопсами и обсуждаем все изменения окружений (мы сообщаем им обо всех изменениях в БД и конфигурации). На каждое изменение у нас есть документ (тикет в Jira). Затем во время релиза все причастные к этому собираются вместе, и каждый говорит, что он сейчас делает: «Мы залили базу», «Мы перезапустили такие-то серверы», «Мы пошли прогонять регрессионные тесты в рабочем окружении». Если же что-то идет не так, запускается процедура отката релиза, точно описанная в изначальном документе на релиз — без такого документа мы обязательно что-нибудь забудем или напутаем.

Контролируйте качество кода

И наконец, code review — практика, к которой прибегают почему-то далеко не во всех проектах. Очень хорошо, если каждая часть кода проверяется более чем одним человеком. Даже в очень сильной команде в процессе code review обязательно обнаруживаются какие-то косяки, а если смотрят несколько человек, количество выявленных косяков возрастает. Причем иногда самое страшное находит третий или четвертый ревьюер.

Инструменты, которые облегчают написание технической документации

Источник: Dzone
Большинство программистов не любят писать техническую документацию. Эксперт по психологии Джеральд Вайнберг даже назвал документацию «касторовым маслом программирования»: разработчики любят ее читать, но сами писать просто ненавидят.
Отсутствие руководства или пустая дорожная карта приводят к нехватке информации о том, как работают различные части программного обеспечения. В конечном итоге это ухудшает восприятие ситуации конечными пользователями кода, поскольку при отсутствии документации они не могут полагаться на точность и полезность продукта.
Чтобы программисту было легче сформировать у себя привычку писать документацию, я рекомендую обратить внимание на четыре отличных инструмента, доступных сейчас практически каждому.

GitHub Pages

Сегодня, вероятно, нет ни одного разработчика, который не имел бы опыта работы в GitHub. Кроме того, это отличное место для программистов, которым нужно где-то хранить документацию. Многие используют стандартный Readme в своей кодовой базе, чтобы предоставить пользователю простое практическое руководство, но это не единственный способ создания документации на GitHub.
Используя GitHub Pages, вы получаете не только хостинг для страниц своего проекта, включая документацию и руководства. Вы получаете возможность напрямую взаимодействовать со всеми репозиториями GitHub, что позволяет разработчикам обновлять документацию так же, как они обновляют свой код. Более того, здесь вы можете использовать Jekyll — он помогает преобразовать разметку в виде обычного текста или в полноценные веб-страницы.

Read the Docs

Как следует из названия, Read the Docs предоставляет разработчикам платформу для хранения и чтения документации. Сервис работает примерно так же, как GitHub Pages: программисты могут вносить изменения в документацию из своих любимых систем контроля версий, включая Git, Bazaar, Mercurial и других. Также поддерживается автоматическая обработка версий и создание страниц.
Лучшая часть Read Docs — это его гибкость. Он поддерживает веб-хуки, поэтому можно автоматизировать большую часть процесса создания документов. Это огромная экономия времени при выполнении задачи, с которой большинство программистов вообще не хотят иметь ничего общего. Кроме того, все, что размещено на платформе, доступно для широкой публики в различных форматах, включая PDF, одностраничный HTML и даже формат электронных книг. Сервис берет на себя значительную часть рутинной работы по поддержанию актуальности документации.

Tettra

Tettra — это не просто платформа для хранения документации программного обеспечения, а полноценная база знаний. Она особенно хорошо работает, когда в проекте задействована большая группа кодеров, работающих над различными частями программного обеспечения. Tettra можно использовать для документирования ответов на распространенные вопросы.

Apiary

Что делает Apiary такой полезной для разработчиков, так это тот факт, что она отлично помогает с документированием API. Платформа позволяет пользователям писать свою документацию в Markdown, включая ложные вызовы API. Также Apiary позволяет провести тестирование и прототипирование элементов API. Иными словами, это инструмент создания документации и платформа тестирования в одном месте.

что нужно знать о работе с чужим кодом

Доходчивый гайд по работе с legacy кодом, который раскроет тонкости взаимодействия с не всегда понятным плодом чужих рук.

У вас бывало так, что вы смотрите на чужой код и не знаете, с чего начать? В этом лабиринте чужих решений не придет на помощь и нить Ариадны: полагайтесь только на свои силы. А мы подскажем 🙂

Пожалуй, первое правило звучит так:

«Если в коде что-то реализовано не так, как вы привыкли – это не значит, что оно реализовано неправильно.»

Каждый опытный программист найдет недостатки в чужом коде. Из этого может последовать решение переписать код «под себя», ведь можно сделать лучше. «Правильность» кода в этом случае понимается исключительно субъективно, исходя из собственного опыта.

Прежде чем приступить, подумайте, что вы пытаетесь сделать, и есть ли причины не делать этого. Используйте Итеративный подход, а главное помните: возможно, код, над которым вы работаете, написан командой в течение многих лет. Наверняка там исправлено много багов, и, скорее всего, это целостное решение, которое не пишется за неделю.

О рефакторинге есть не одна книга. Поэтому вторым советом будет обратиться к литературе, например, Working Effectively With Legacy Code.

Главная идея книги построена на тестах, которые помогают понять и улучшить систему. Книга организована по принципу «вопрос-ответ», помогает разобраться в сложном коде и решить проблемы.

Есть очень важный момент – уважение к чужому коду и коллегам, работавшим до вас. Сложно быть эффективным без соблюдения этого правила.

Легко критиковать чужую систему, но от этого она не станет понятней. Поэтому при вхождении в новый проект приложите максимум усилий к пониманию внутреннего устройства и заложенных знаний. Вам помогут официальные или собственные юнит-тесты. Задокументируйте все, что слышите от людей, связанных с проектом, анализируйте ссылки и документацию проекта, сверяйте с собственными результатами. Фундаментальные знания помогут понять сложную систему.

Привыкните к тому, что люди редко жертвуют временем ради того, что уже работает, и предпочитают сосредоточиться на новых тасках. Но в legacy часто нужен человек, который способен внести ясность. Решение этой проблемы может не входить в прямые обязанности действующих или бывших сотрудников. Так что «новичку» приходится разбираться самому: разворачивать среду разработки, искать повторяющиеся конфигурации, процессы, улучшать виртуальную среду или контейнеры, подключать внешние службы к локальной среде или использовать заглушки, проводить тесты.

Изучение системы может забрать недели или месяцы. Но безрезультатным это не будет. В итоге вы узнаете систему, поймете процессы и всё задокументируете.

Работа с legacy-кодом открывает большие перспективы. И не спешите углубляться в критические проблемы, которыми озадачены другие люди. Очищайте и документируйте код. Помните, люди рассказывают гораздо больше о том, как работает код, когда критикуют, чем когда вы спрашиваете напрямую.

Кончено, не обойдется без собственных ошибок в процессе, поэтому придется часто начинать заново.

Есть поставленные цели и задачи: их нельзя игнорировать. Учитывайте интересы бизнеса и вносите изменения, когда:

• приняты правила того, как никто не должен делать;
• есть негативное влияние на показатели бизнеса, такие как производительность, безопасность, etc.;
• текущая система мешает бизнесу выйти на новый левел.

Умение правильно определять решения – тоже навык. Поэтому вместе с утверждением, приведенным в начале, спросите себя:

«Открою ли я новую возможность, которая была нереализуема до этого, и принесет ли это пользу кому-то, кроме меня?»

Если нет уверенного «Да», отложите изменения. Улучшение одного или нескольких показателей стоит немалых усилий.

Абстрагирование – это важный инструмент ООП наряду с полиморфизмом, наследованием и инкапсуляцией. Абстракция позволяет работать с объектами, не вдаваясь в подробности их реализации.

Но разработчики часто неверно полагают, что можно «спрятать» сложности кода за абстрактный слой. Это не так. Лучше мириться с явными сложностями существующей системы, чем выдумывать абстрактный уровень над этими сложностями.

Проблемы начинаются когда команда первых разработчиков становится недоступной. В этом случае невозможно овладеть теоретической базой в полной мере и, как следствие, выбрать правильные абстракции.

Правильный способ – упрощение существующего кода или рефакторинг.

Да, бывает откровенно плохой код.

Но нужно сперва разобраться.

Общение – важный навык. Без него тяжко разобраться в сложной системе. Поэтому, прежде чем проводить рефакторинг и тесты, спросите других разработчиков:

• «Какой используется шаблон проектирования?»
• «Как производятся тесты?»
• «Каким образом разворачивается среда разработки?»
• «Как получить доступ к данным?»
• «Каким способом происходит миграция данных?»
• «Как обеспечивается масштабирование, параллелизм, безопасность, аутентификация?»

Если разработчики недоступны, ищите ответы в коде.

Столкнулись с незнакомым паттерном? Ищите информацию о странных на первый взгляд наименованиях, встречающихся в коде.

А еще помните, что разработчики часто копируют код из интернета, и реализовывают идеи, которые изучили недавно (все этим грешат, верно? 🙂 ). Для подозрительных отрывков кода используйте поисковики.

Следуйте сценарию использования для анализа уровней приложения с помощью debugger’а. Возьмите на заметку непонятные фрагменты и набросайте диаграмму архитектуры.

Читайте также:

• Налаживаем отладку или улучшаем свой скилл дебаггинга
• Отладка программы: 3 типа ошибок
• Хороший код: писать так, чтобы потом не было мучительно больно

Будем рады, если вы пополните копилку наших советов.

Что такое устаревший код? Это код без тестов?

Вы боретесь с устаревшим кодом и не хватает времени, чтобы очистить его?
⛑ Моя аптечка может помочь вам спасти любую кодовую базу быстро и безопасно !

«Устаревший код» .

Если вы работаете в сфере ИТ, вы часто будете слышать этот термин в своей карьере. Разработчики говорят об этом много . Обычно с большим количеством негативных коннотаций.

Но что именно они называют «устаревшим кодом»? Просто старый код? Или чужой код? В любом случае, вы поняли, что это не «хороший код».

Теперь, если вы были в игре какое-то время, вы, возможно, поняли, что у всех разные взгляды на то, как должен выглядеть хороший код. Итак, есть ли полезное определение «устаревшего кода», на которое вы можете сослаться?

Код без тестов

Если вы осмотрелись, прежде чем читать это, возможно, вы натолкнулись на это описание.

В своей книге «Эффективная работа с устаревшим кодом» Майкл Фезерс дает четкое определение того, что для него значит устаревший код:

Для меня унаследованный код — это просто код без тестов.

Это результат многолетнего опыта.

Почему Перья так говорят? Потому что без тестов обычно очень сложно узнать все, на что способен код.

Если вам нужно понять, что делает код, вам нужно внимательно прочитать его, поиграть с компьютером в голове и представить все возможные сценарии. Вы также можете протестировать его вручную, чтобы увидеть, что он делает. Как правило, код без тестов сложно изменить, не внося где-то регрессии.

Мне нравится это определение. Это рабочий. Чаще всего тесты отсутствуют. Так что это хорошее начало.

Но думаю не полный.

2 аспекта отсутствуют:

1. Код с тестами также может быть Legacy Code . Плохо написанные тесты мешают. Да, код может быть сложнее изменить, потому что тесты — отстой! Если вы читаете тесты, но не можете понять, что должен делать код, это отстой. Протестированный код может быть так же сложно изменить, как если бы он не тестировался, а может быть, даже сложнее!
2. Код может не иметь тестов, но его можно легко изменить . Возможно, вы поддерживаете небольшую кодовую базу, которая не тестировалась, но которую легко понять и изменить — хотя, по моему опыту, это редкость. Эту кодовую базу можно протестировать. Но отсутствие автоматических тестов может не квалифицировать его как устаревший код.

Код, который вам неудобно менять

Это мое определение устаревшего кода. Позвольте мне повторить это по-другому:

Устаревший код — это ценный код, который вы боитесь изменить.

Возможно, вы ищете основную причину ошибки. Или, может быть, вы выясняете, куда вставить свою функцию. Вы хотите изменить код, но вам трудно это сделать, потому что вы не знаете, как не сломать существующее поведение. Это устаревший код.

Вам нужно понять несколько вещей:

• Незнание кода играет большую роль . Мы переоцениваем сложность незнакомого кода. Вот почему вы думаете, что этот код, который вы не писали, является устаревшим кодом. Или тот код, который вы написали, потому что не можете вспомнить, какой ад вы имели в виду, когда делали это. Да, наше прошлое я часто совершает глупые ошибки. Не рассказывай себе в будущем 🤫
• Хорошие тесты помогут вам легко изменить незнакомый код . Отсюда и определение Перьев. Но плохие тесты не будут.
• Через несколько месяцев станет лучше . Имейте это в виду, если вы начали работать над устаревшим проектом и испытываете трудности. Я не говорю, что код отличный — большая часть кода ужасна. Но вы привыкнете к нему и лучше поймете его причуды и особенности. Увлекательно, не так ли? Не чувствуете возбуждения? Хорошо, идем дальше.
• Большая часть кода ужасна , потому что это результат работы многих людей в течение длительного периода времени с противоречивыми требованиями в условиях дефицита времени. Рецепт устаревшего кода™. Знания несовершенны, и чтобы уложиться в сроки, используются короткие пути. Это ОЧЕНЬ распространено. В конце концов, вы достигнете состояния, когда каждое действие приводит к ошибке, а реализация любой функции занимает целую вечность. Мех.

Послушайте меня еще раз:

Устаревший код — это код, который вам нужно изменить, и вам трудно его понять.

Чем полезно это определение? Потому что в нем говорится то, что люди не могут понять: Унаследованный код — это личная точка зрения .

Это зависит от вашего понимания кода. И ваше чувство о его смене.

Некоторый код может быть проблемой для каждого разработчика команды. Некоторый код может показаться вам сложным, потому что вы его еще не понимаете. Некоторый код вы можете понять, но вам все еще неудобно его менять. 🤷

Будем надеяться, что есть способы быстрее ознакомиться с Legacy Code!

Изучение устаревшего кода необходимо для продуктивной работы.

Существует много устаревшего кода! Каждая кодовая база, над которой вы будете работать, будет в основном Legacy. Вы можете попытаться избежать этого и чувствовать себя плохо, когда вы застряли с этим. ..

Или вы можете рассматривать это как возможность развить ценные навыки, которые сделают вас отличным разработчиком .

Что делает код устаревшим? — Переполнение стека

спросил
13 лет, 11 месяцев назад

Изменено
3 года, 7 месяцев назад

Просмотрено
8к раз

Я слышал, что многие разработчики называют код «устаревшим». В большинстве случаев это код, написанный кем-то, кто больше не работает над проектом. Что делает код унаследованным кодом?

Обновление в ответ на:
«Что-то переданное от предка или предшественника или из прошлого» http://www.thefreedictionary.com/legacy. Очевидно, вы хотели узнать что-то еще. Не могли бы вы уточнить или расширить свой вопрос? S.Lott

Я ищу признаки унаследованного кода, которые делают его непригодным для использования или с которым трудно работать. Когда лучше выбросить? Я считаю, что код следует чаще выбрасывать, а изобретать велосипед — ценная часть разработки. Академический идеал не изобретать велосипед хорош, но не очень практичен.

С другой стороны, очевидно, что устаревший код стоит сохранить.

• наследие

1

Путем использования оборудования, программного обеспечения, API-интерфейсов, языков, технологий или функций, которые либо больше не поддерживаются, либо были заменены, как правило, в сочетании с минимальной или нулевой возможностью когда-либо заменить этот код, вместо этого используя его до тех пор, пока он или система не умрет.

Что делает код унаследованным кодом?

Как и в случае простого наследия, когда автор мертв или пропал без вести, вы, как наследник, получаете весь или часть его кода.

Вы проливаете слезы и пытаетесь понять, что делать со всем этим мусором.

0

У Майкла Фезерса есть интересное определение в его книге «Эффективная работа с устаревшим кодом». По его словам, унаследованный код — это код без автоматизированных тестов.

9

Это очень общий термин (и им часто злоупотребляют), но любой из следующих может быть законным основанием для того, чтобы назвать приложение устаревшим: оригинальный продукт (часто говорят, что производитель прекратил свою деятельность).

Наследие обычно относится к коду, который больше не разрабатывается — это означает, что если вы его используете, вы должны использовать его в исходных условиях — вы не можете просто отредактировать его, чтобы он поддерживал то, как мир выглядит сегодня. Например, устаревший код должен выполняться на оборудовании, которого сегодня может не быть или оно больше не поддерживается.

По словам Майкла Фезерса, автора превосходной книги «Работаем эффективно с устаревшим кодом», устаревший код — это код, не имеющий тестов. Когда нет возможности узнать, что ломается при изменении этого кода.

Главное, что отличает
устаревший код из неустаревшего кода
тесты, а точнее их отсутствие. Мы
может получить представление об этом с небольшим
мысленный эксперимент: как легко было бы
изменить кодовую базу, если она
мог бы укусить, если бы он мог сказать вам
когда вы ошиблись? Это было бы
довольно легко, не так ли? Большинство из
страх, связанный с внесением изменений в
больших кодовых баз боятся
введение малозаметных ошибок; страх
непреднамеренное изменение вещей. С
тесты, вы можете улучшить ситуацию с помощью
безнаказанность. по мне так разница
критический, он подавляет любой другой
различие. С тестами можно сделать
вещи лучше. Без них вы просто
не знаю, идут ли дела
лучше или хуже.

3

Никто не будет это читать, но я чувствую, что другие ответы не совсем верны:

1. Это имеет ценность, если бы оно не было полезным, его бы давно выбросили
2. Трудно рассуждать, потому что любой из
   1. Отсутствие документации,
   2. Первоначальный автор не может быть найден или забыт (да, через 2 месяца ваш код тоже может быть устаревшим кодом!!),
   3. Отсутствие тестов или системы типов
   4. Не следует современным практикам (т. е. нет контекста, за который можно было бы держаться)
3. Требуется изменить или расширить его.
   Если нет необходимости его менять, это не устаревший код.
   так как это никого не волнует. Он делает свое дело, и нет никого
   вокруг, чтобы назвать это унаследованным кодом.

1

Коллега однажды сказал мне, что унаследованный код — это любой код, который вы не написали сами.

Возможно, это просто уничижительный термин для кода, который нам больше не нравится по какой-либо причине (обычно потому, что он не крутой или модный, но работает).

Бригада TDD может предположить, что любой код без тестов является устаревшим кодом.

1

Устаревший код — это исходный код, относящийся к более не поддерживаемой или не выпускаемой операционной системе или другой компьютерной технологии.

http://en.wikipedia.org/wiki/Legacy_code

«Устаревший код — это исходный код, относящийся к более не поддерживаемому или не выпускаемому продукту»

1

Отсутствует любой код с поддержкой (или документацией). Будь то:

• встроенные комментарии
• техническая документация
• устная документация (тот, кто ее написал)

Модульные тесты

• , документирующие работу кода

Для меня унаследованный код — это код, который был написан до какого-то сдвига парадигмы.
Возможно, он все еще используется, но находится в процессе рефакторинга, чтобы привести его в соответствие.
напр. Старый процедурный код, висящий в другой объектно-ориентированной системе.

Код (или что-то еще, на самом деле) становится «устаревшим», когда он заменяется чем-то более новым/лучшим, и все же, несмотря на это, он все еще используется и сохраняется «в дикой природе».

Сохранение устаревшего кода — это не столько академический идеал, сколько сохранение работоспособного кода, каким бы плохим он ни был. Во многих консервативных корпоративных ситуациях это будет сочтено более практичным, чем выбросить его и начать заново с нуля. Лучше черт тебя знает…

1
92) алгоритм не будет масштабироваться за пределы определенной точки и должен быть переписан, если требования будут двигаться в этом направлении. Другой пример — код, использующий библиотеки, которые не поддерживаются в последних версиях ОС.

2) Его труднее распознать, но все коды такого рода имеют общую характеристику: люди боятся его изменять. Это может быть связано с тем, что он был плохо написан/задокументирован с самого начала, потому что он не тестировался или потому, что он нетривиален, и первоначальные авторы, которые его поняли, покинули команду.

Символы ASCII/Unicode, составляющие живой код, имеют семантическое значение, «почему», «что такое» и в некоторой степени «как» в умах людей, связанных с ним. Устаревший код либо не принадлежит владельцам, либо владельцы не имеют смысла, связанного с большими его частями. Как только это произойдет (а это может произойти на следующий день с действительно плохо написанным кодом), чтобы изменить этот код, кто-то должен его изучить и понять. Этот процесс занимает значительную часть времени, необходимого для его написания.

День, когда вы боитесь реорганизовать свой код, — это день, когда ваш код станет устаревшим.

Я считаю код «устаревшим», если выполняются некоторые или все из следующих условий:

• Он был написан с использованием языка или методологии, которые на поколение отстают от текущих стандартов
• Код представляет собой полный беспорядок, за которым не стоит никакого планирования или дизайна
• Написано на устаревших языках и в устаревшем, не объектно-ориентированном стиле
• Трудно найти разработчиков, знающих этот язык, потому что он такой старый

В отличие от некоторых других мнений здесь, я видел множество современных приложений, которые нормально работают без модульных тестов. Модульное тестирование до сих пор не у всех на слуху. Возможно, через десять лет следующее поколение программистов будет смотреть на наши нынешние приложения и считать их «унаследованными» из-за того, что они не содержат модульных тестов, точно так же, как я считаю унаследованными необъектно-ориентированные приложения.

Если в унаследованную кодовую базу необходимо внести несколько изменений, лучше просто оставить ее как есть и плыть по течению. Если приложению нужны кардинальные изменения функциональности, капитальный ремонт графического интерфейса и/или вы не можете найти никого, кто знает язык программирования, пришло время выбросить его и начать заново. Однако предупреждаю: переписывание с нуля может занять очень много времени, и трудно понять, воспроизвели ли вы все функциональные возможности. Вы, вероятно, захотите, чтобы тестовые примеры и модульные тесты были написаны для устаревшего приложения и нового приложения.

Честно говоря, устаревший код — это любой код, фреймворк, API или другая программная конструкция, которая больше не является «крутой». Например, COBOL единогласно считается устаревшим, а APL — нет. Теперь можно также утверждать, что COBOL считается устаревшим, а APL не потому, что его установочная база примерно в 1 миллион раз больше, чем у APL. Однако, если вы скажете, что вам нужно поработать над кодом APL, ответом будет не «о нет, это устаревшие вещи», а скорее «о боже, думаю, вы ничего не будете делать в следующем столетии».