Когда код «наследие»? [закрыто]

63

Мы все сделали это, мы пометили некоторый код (часто вещи, которые мы унаследовали) как «наследие»? Но он все еще используется в производственных системах - так ли это на самом деле наследие? И что делает это наследство? Должны ли мы уклоняться от этой необоснованной маркировки прекрасно функционирующего кода; где маркировка - это чистое удобство, которое позволяет нам продвигать новые вещи и сохранять высшее руководство приятным и счастливым?


Резюме ответов

Просматривая ответы, я вижу четыре общие темы. Вот как я вижу разбивку:

  1. Любой код, который был доставлен: 6
  2. Мертвые системы: 2,5
  3. Нет юнит-тестов: 2
  4. Разработчиков нет рядом: 1,5
Nim
источник
3
ru.wikipedia.org/wiki/Deprecation
Роберт Харви
1
Это устаревший код, как только он доставлен и работает.
Мартин Беккет
23
это унаследованный код, если вы его не писали ;-)
Стивен А. Лоу
20
Это унаследованный код, если все, кто его написал, ушли на пенсию или умерли, и если те, кто продолжает поддерживать его, хотят, чтобы они были. В противном случае это просто называется существующей кодовой базой.
пифоничный
3
@ StevenA.Lowe, учитывая достаточно времени, это устаревший код, даже если я его написал.
Kyralessa

Ответы:

43

Я довольно неравнодушен к резюме Википедии :

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

Многое из того, что другие люди описывают в своих ответах, является причиной того, почему код становится «наследием». Но основной вопрос сам по себе заключается в следующем:

Но он все еще используется в производственных системах - так ли это на самом деле наследие? И что делает это наследство?

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

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

Существует множество причин, по которым системы или код могут стать устаревшими:

  • Отсутствие регулярного обслуживания или программного гниения . Ясно, что если приложение не поддерживается регулярно, оно не поспевает за серьезными изменениями в мире программного обеспечения. Это может быть связано с простым пренебрежением или это может быть преднамеренный выбор, основанный на бизнес-приоритетах или бюджетных ограничениях.

  • Отсутствие тестирования. Другой ответ ссылается на гиперболическое утверждение популярного автора о том, что любой код, не охваченный тестами, является устаревшим кодом. Это действительно не точное определение, но это является возможной основной причиной; без хороших тестов (автоматических или ручных) разработчики становятся робкими и боятся вносить серьезные изменения, потому что боятся что-то сломать, что приводит к «программной гнили» выше.

  • Блокировка оборотов, часто упускаемый из виду фактор, который особенно коварен в проектах, использующих большие библиотеки с открытым исходным кодом или фреймворки (хотя я видел, что это происходит и с коммерческими инструментами). Часто для фреймворка / библиотеки будут проводиться серьезные настройки, что сделает обновление слишком сложным или дорогостоящим. Таким образом, система становится устаревшей, поскольку она работает на более старой (и, возможно, больше не поддерживается) платформе.

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

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

Теперь отдельный, неустановленный, но подразумеваемый вопрос: что не так с унаследованным кодом? Он часто используется как уничижительный термин, поэтому возникает вопрос:

Должны ли мы уклоняться от этой необоснованной маркировки идеально функционирующего кода?

И ответ - нет, мы не должны; маркировка является оправданным и сам термин явно подразумевает код функционирования. Дело не в том, что это функция, а в том , как она работает.

В некоторых случаях нет ничего плохого в устаревшем коде. Это не плохое слово. Устаревший код / ​​системы не являются злом. Они только что собрали немного пыли - иногда немного, иногда много.

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

оборота Аарона
источник
Тем не менее, налоговая проверка должна быть в полном порядке.
Флориан Маргейн
Я бы сказал: система, которая больше не может масштабироваться с помощью существующего стека технологий.
Рамиз Уддин
40

Обычно это означает, что он написан на языке или основан на системе, в которой вы обычно не разрабатываете новые разработки.

Например, большинство мест не пишут новые программы на Коболе. Однако большая часть их бизнеса может работать на приложениях, написанных на Cobol. Следовательно, эти приложения помечены как «Наследие».

Peter Mortensen
источник
Я согласен с этим ответом больше всего. Legacy - это больше застревание на устаревшей платформе, чем надоедливый (но современный) код, который вы не хотите поддерживать. Устаревший код часто довольно хорош (в противном случае никого не волнует, если вы его оставите!), Но обычно он привязан к устаревшему оборудованию и устаревшим языкам / библиотекам / базам данных / и т. Д.
Satanicpuppy
3
@Satanicpuppy: Я просто не могу согласиться - я имел дело (с одним примером) с какой-то Java, которая определенно не была привязана к какому-либо конкретному оборудованию, библиотеке или базе данных - но была настолько «унаследована», насколько это возможно (и было переписывается на Java, поэтому язык тоже не проблема). Я также имел дело с некоторым кодом, который был привязан к конкретному оборудованию, но все еще едва входил в категорию «устаревших».
Джерри Гроб
4
@jerry: Так что сделало это наследство? Наследие не является синонимом «плохо».
Satanicpuppy
1
В случае, о котором я думаю, это была довольно большая распределенная система (построенная вокруг BEA Tuxedo). Дизайн, казалось, основывался на сценариях учебника, которые предназначены, чтобы преподавать о синхронизации, максимизируя количество времен / мест, необходимых для синхронизации. Это (вроде) имеет смысл для учебника, но это ужасно для реальных проектов. Он был достаточно большим, чтобы даже разработка замены была многолетним проектом. Замена должна была выполняться поэтапно, без простоя, потому что система была крайне необходима для бизнеса.
Джерри Гроб
1
@Cawas: Мне кажется, что ответ @ Chad будет применим, когда / если новая система будет работать на другом языке, или с использованием другого оборудования и т. Д. Это было переработано с использованием Java, Tuxedo и т. Д. Я не вижу в этом применения.
Джерри Гроб
28

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

  1. Акцент «скорее» предназначен для передачи этого унаследованного кода, а также означает, что вы застряли, работая с ним, даже если вы этого не хотите. Я не уверен, что акцент был достаточным, хотя. Причины этого могут быть разными. Некоторые действительно слишком большие и сложные для замены. Другие являются интерфейсами к другим системам. Третьи движимы политикой и личностями (например, код ужасен, но детка на стенде была потрясающей).
  2. Еще один момент, который я, возможно, недостаточно подчеркивал, заключается в том, что, хотя качество кода может быть фактором, оно редко (если вообще когда-либо) является единственным фактором - и зачастую даже не особенно важным.
  3. Я думаю, что люди, проводящие юнит-тесты в качестве единственного определяющего фактора, похожи на парня, ищущего под уличным фонарем серьгу, которую его жена выбросила за квартал. Свет может быть лучше, но вы все еще смотрите не в том месте. Подумайте, прежде чем пить Kool-Aid .
  4. (Следствие к 3.) Мне кажется, что некоторые люди больше говорят о том, как они хотят, чтобы вещи были, чем как они есть на самом деле. Если Джон Conways " Игра жизни для компании Apple IIc Plus не наследство, это потому , что это достаточно маленький и простой , что это легко повторно реализовать с нуля. Самое совершенное модульное тестирование, когда-либо написанное, не изменит ни одной йоты .

Последний пункт действительно приводит к двум другим пунктам, которые я считаю часто верными.

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

Во-вторых, юнит-тесты - это палка о двух концах. Благодаря им слишком легко думать, что локальные изменения в реализации - это то, что действительно имеет значение. Чтобы внести существенные улучшения в более крупную систему, вам часто (обычно?) Приходится менять достаточно общий дизайн, чтобы многие (если не большинство) модульных тестов стали неактуальными. К сожалению, наличие модульных тестов и отношение, которое они порождают, может слишком легко игнорировать изменения, которые действительно необходимы.

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

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

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

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

Jerry Coffin
источник
3
Видите ли, теперь я не знаю, стоит ли отмечать это или нет, к сожалению, это правда, но мне интересно, нужно ли такое отношение, чтобы уйти от ...
Ним
+1. Я собирался ответить на что-то в той же степени. Legacy - это любой код, который используется, а не активно поддерживается.
Дени де Бернарди
@Nim: Я не думаю, что это отношение, от которого «мы» должны уйти. Это просто утверждение очевидного. :-) Подумайте об этом на мгновение и подумайте, что бы вы считали устаревшим кодом, если бы вам пришлось приехать в новую среду; это будет все, кроме новых и классных вещей, которые активно развиваются.
Дени де Бернарди
@ Джерри, значит тебе не нравятся юнит-тесты? ;)
Ним
1
@Nim: Не так - я думаю, что они полезны, но далеко от панацеи, которую они часто изображают.
Джерри Гроб
17

Устаревший код обычно в некотором роде осиротевший. Ведущий разработчик, единственный парень, который понял это, был сбит автобусом, и его заметки были написаны на его родном украинском диалекте, который теперь мертвый язык. Или, альтернативно, все, что написано в Visual Basic 6.0 .

Я работаю над устаревшим кодом все время. Я бы сказал, что характеристики:

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

Если у него нет этих характеристик, то, вероятно, это не наследство. Если вам не нравятся Perl- скрипты ваших предшественников , я сочувствую, но я не думаю, что это наследие. Недавно я модернизировал некоторый 15-летний Perl-скрипт, который был встроен в устаревшую базу данных Sybase . Это был торт по сравнению с внесением даже самых маленьких изменений в нашу ужасную систему учета COBOL .

Satanicpuppy
источник
Страшно, наш ведущий разработчик тоже украинец ... хаха ... Я согласен с серединой вашего ответа, первый пункт - не так много - я думаю, что это зависит от того, как настроена ваша команда разработчиков.
Ним
1
LOL, вам, вероятно, удалось обидеть (водители автобусов, украинский язык и разработчики VB6) все в одном пункте. Но, черт возьми, я смеялся :)
Темная ночь
Я путешествую во времени с 1999 года, вы имеете в виду, что Visual Basic 6 является наследием с 2011 года?
hjk
@hjk Я бы сказал, что после появления C # / asp.net в 2005 году все будет в шатком положении, но, разумеется, после прекращения поддержки со стороны Microsoft в 2008 году.
Satanicpuppy
12

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

Грант Пэйлин
источник
24
Это поражает меня как случай попытки определить «все, что не следует выбранной мной методологии» как «наследие». Это ничто иное, как дешевая тактика дебатов, в основном просто принятие закона Годвина и смягчение языка (едва), чтобы не дать читателям мгновенно осознать, что это не что иное, как неподдерживаемая (и часто невыносимая) атака на всех, кто не следует его предпочтения.
Джерри Гроб
4
@ Джерри: я согласен с определением Пера. Код без юнит-тестов - ужасно работать. Если вы решите реорганизовать некоторые его части, чтобы было легче рассуждать об этом, забудьте об этом! Вы можете вносить ошибки и код, вероятно, так, как он не тестируется, в любом случае! Я считаю, что определение Пера было нетрадиционным, но он - тот, кто зарабатывал на жизнь, работая с унаследованным кодом.
пожрал Элизиум
10
@devoured: модульные тесты не являются точным лакмусовым тестом на способность работать с кодом. Я имел дело с кодом, в котором отсутствовали модульные тесты, но он был легким - и с кодом, который имел модульные тесты, и все еще был кошмаром. В конечном счете, модульные тесты сами по себе ничего не решают. Модульные тесты для проекта, в котором (например) деление на блоки было сделано плохо, все еще могут быть совершенно бесполезными, и весь проект (включая тесты) необходимо выбросить на замену, чтобы получить что-то полезное.
Джерри Коффин
6
Я согласен с комментариями Джерри. Отсутствие модульных тестов является лишь одним из множества запахов кода, которые могут (или не могут ) указывать на плохую работу.
smci
4
Я снова согласен с определением Пера, а также пожрал Отсутствие модульного тестирования - это все, так как это означает, что даже самый красивый фрагмент кода не соответствует своим спецификациям. Модульные тесты составляют 51% документации и 100% спецификации кода. Код, в котором отсутствует большая часть его документации, и все его спецификации должны быть справедливо классифицированы как устаревшие.
8

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

Это «до вашего времени», но «все еще ваша головная боль» .

дебилы
источник
5

Устаревший код - это код, который остается только в базе кода, потому что многие вещи перестали бы работать в противном случае. Другими словами: единственная причина существования - обратная совместимость.

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

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

Другим примером являются все те странные уловки, которые Microsoft делает для запуска программ, написанных для версий своих ОС, которые они полностью устарели. Вершина этого существа:

Впервые я услышал об этом от одного из разработчиков популярной игры SimCity, который сказал мне, что в его приложении была критическая ошибка: оно использовало память сразу после ее освобождения, а главное, нет-нет, которая работала нормально в DOS, но не будет работать под Windows, где освобождаемая память может быть сразу же захвачена другим запущенным приложением. Тестеры в команде Windows просматривали различные популярные приложения, проверяя их, чтобы убедиться, что они работают нормально, но SimCity продолжал падать. Они сообщили об этом разработчикам Windows, которые разобрали SimCity, прошли через него в отладчике, нашли ошибку и добавили специальный код, который проверял, запущен ли SimCity, и, если это так, запускал распределитель памяти в специальном режиме, в котором вы мог все еще использовать память после освобождения.
- Джоэл по программному обеспечению

back2dos
источник
4

Наследие влечет за собой наследование. Устаревший код - это просто код, который вы наследуете из прошлого. Это устаревший код, даже если вы написали его сами!

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

Ando
источник
Прошлое может быть 1 день, 1 час или 1 год. Это не делает это наследством.
Винс Пануччо
2

Мое мнение таково, что то, что считается устаревшим кодом, зависит от множества вещей, а тег 'legacy', вероятно, зависит от конкретной организации.

Если аппаратное обеспечение / ОС, на котором оно работает, устарело и было прекращено поставщиком - страйк 1.

Если это больше работы, чтобы попытаться исправить это, чем переписать это, по любой причине, потому что

  • первоначальный разработчик / ы ушли
  • программа плохо написана
  • это может быть сделано лучше на более новой платформе, и все еще стоит компании

сделать так

  • первоисточник больше недоступен и / или отсутствуют фрагменты

Удар 2.

Объединение нескольких организаций в одну - Strike 3 - одна сторона, вероятно, будет помечена как устаревшая.

Есть ли лучшая, более дешевая альтернатива, продаваемая в качестве стороннего приложения и / или сервиса - страйк 4.

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

Если компания является небольшой компанией-разработчиком, которая продолжает совершенствовать / поддерживать приложение, чтобы делать то, что нужно заказчикам, считается ли это устаревшим кодом или просто «старым» кодом. Я знаю компанию Mc2Ok, которая разработала программное обеспечение для Windows 3.1 и продолжала его продвигать. Он все еще очень похож на Windows 3.1, но к нему также добавили веб-интерфейс. Это девелоперская компания, состоящая из двух человек (я думаю), и я бы сказал, что когда они перестанут работать над ней, это будет считаться устаревшим, и пора переходить через год или два после его использования. Но это может быть еще 10 или более лет.

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

Я полагаю, что каждая организация должна определить, что для них значит «устаревший код». Я имел обыкновение просматривать объявления The Sunday Times каждую неделю, чтобы увидеть, что ищут организации. Раньше это был мой барометр для того, что больше не имело значения (то есть наследие). Что ж, The Sunday Times больше не имеет отношения к делу :-) И мы можем обобщить, что COBOL является наследием, ASP Classic является устаревшим и т. Д. Но я считаю, что каждая организация должна решить, когда приложение считается унаследованным для него.

Грегори Томсон
источник
+1, хороший ответ - лучше рассмотреть что-то наследственное с точки зрения организации ...
Ним
0

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

Вот почему я также согласен с определением Майкла Перса. Код с хорошими юнит-тестами можно смело менять.

Я также думаю, что унаследованный код не имеет никакого отношения к его возрасту. Можно написать старый код с самого начала.

komisacroS
источник