Что делает код наследственным? - PullRequest
41 голосов
/ 26 января 2009

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

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

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

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

Ответы [ 21 ]

5 голосов
/ 26 января 2009

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

  • встроенные комментарии
  • техническая документация
  • устная документация (человек, который ее написал)
  • модульные тесты, документирующие работу кода
5 голосов
/ 26 января 2009

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

"Устаревший код - это исходный код, который больше не поддерживается или не производится"

2 голосов
/ 26 января 2009

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

2 голосов
/ 26 января 2009

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

2 голосов
/ 14 мая 2018

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

1 голос
/ 02 июня 2015

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

Это может произойти двумя способами:

  1. Код не подходит для изменения
  2. Семантика кода заменена на кремниевую

1) легче распознать. Это программное обеспечение имеет фундаментальные ограничения, что делает его неспособным идти в ногу с экосистемой вокруг него. Например, система, построенная на алгоритме O (n ^ 2), не масштабируется за пределами определенной точки и должна быть переписана, если требования движутся в этом направлении. Другой пример - код с использованием библиотек, которые не поддерживаются в последних версиях ОС.

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

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

1 голос
/ 01 февраля 2009

Я считаю код "устаревшим", если выполняются какие-либо или все следующие условия:

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

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

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

0 голосов
/ 04 мая 2019

Это общий термин, часто встречающийся (и довольно общий) в экосистеме программного обеспечения.

Ну, мне нравится думать о устаревшем коде как о унаследованном коде . Это просто код, который был написан в прошлом. В большинстве случаев устаревший код не соответствует новым / текущим практикам и часто считается архаичным.

0 голосов
/ 26 января 2009

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

0 голосов
/ 07 октября 2011

Часто это любой код, который не написан на модном языке сценариев du jour, и я только наполовину шучу.

...