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

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

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

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

1. Любой код, который был доставлен: 6
2. Мертвые системы: 2,5
3. Нет юнит-тестов: 2
4. Разработчиков нет рядом: 1,5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

сделать так

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

Удар 2.

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

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

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

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

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

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

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

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

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