Коли код "спадщина"? [зачинено]


63

Ми все це зробили, ми позначили якийсь код (часто речі, які ми успадкували) як "спадщину"? Але він все ще використовується у виробничих системах - так це справді спадщина? І що робить це спадщиною? Чи слід ухилятися від цього необґрунтованого маркування ідеально функціонуючого коду; де маркування - це чиста переконаність, яка дозволяє нам просувати нові речі та підтримувати вищий менеджмент приємним та щасливим?


Підсумок відповідей

Переглядаючи відповіді, я бачу чотири загальні теми. Ось як я бачу поломку:

  1. Будь-який код, який було доставлено: 6
  2. Мертві системи: 2.5
  3. Немає одиничних тестів: 2
  4. Розробників немає навколо: 1.5


1
Це застарілий код, як тільки він буде доставлений і працює.
Мартін Бекетт

23
це спадковий код, якщо ви його не писали ;-)
Стівен А. Лоу

20
Це спадковий код, якщо всі, хто його написав, вийшли на пенсію або померли, і якщо ті, хто продовжує підтримувати це, хочуть, щоб вони були. В іншому випадку це просто називається наявна база коду.
непітонічний

3
@ StevenA.Lowe, давши достатньо часу, це застарілий код, навіть якщо я його написав.
Kyralessa

Відповіді:


43

Я досить частковий до резюме Вікіпедії :

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

Багато з того, що описують інші у своїх відповідях, є причинами того, що код стає "спадщиною". Але найважливішим питанням є таке:

Але він все ще використовується у виробничих системах - так це справді спадщина? І що робить це спадщиною?

Те, що він все ще використовується у виробництві , саме те, що робить його спадщиною . Якщо код не працює належним чином або більше не використовується у виробництві, то цей код відповідно "зламаний" або "звільнений". Спадщина означає, що вона все ще використовується та працює чудово, але включає в себе конструкції чи методи, які вже не є загальноприйнятими.

Будь-який код або система, яку ви (а) хотіли б оновити / оновити, але не можете, або (b) все ще перебуваєте в середині оновлення, є застарілою системою. Це не означає рефакторинг або загальне очищення коду, це означає значні зміни в дизайні, можливо, використовуючи новий фреймворк або навіть нову платформу.

Є безліч причин , чому система або код може стати спадщиною:

  • Відсутність регулярного технічного обслуговування або гниття програмного забезпечення . Зрозуміло, що якщо програма не підтримується регулярно, вона не буде йти в ногу з істотними змінами в світі програмного забезпечення. Це може бути пов’язано з простою нехтуванням, або це може бути свідомий вибір, що базується на бізнес-пріоритетах або бюджетних обмеженнях.

  • Відсутність тестування. Інша відповідь посилається на гіперболічну претензію популярного автора на будь-який код, який не охоплюється тестами, а це старий код. Це на самому ділі не є точним визначення , але це є можливою першопричиною; без хороших тестів (автоматизованих або ручних) розробники стають боязкими і бояться вносити серйозні зміни, оскільки переживають про те, щоб щось зламати, тим самим ведучи "гниття програмного забезпечення" вище.

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

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

Все, що уповільнює або зупиняє оновлення бази даних коду, може призвести до того, що база коду стане спадщиною.

Тепер окреме, невстановлене, але мається на увазі питання, що не так із застарілим кодом? Його часто використовують як пейоративний термін, звідси питання:

Чи слід ухилятися від цього необґрунтованого маркування ідеально функціонуючого коду?

І відповідь - ні, ми не повинні; маркування є гарантованим, а сам термін чітко передбачає функціонуючий код. Справа не в тому, що це функція, а в тому, як вона функціонує.

У деяких випадках із застарілим кодом нічого поганого. Це не погане слово. Спадковий код / ​​системи - це не зло. Вони щойно збирали пил - іноді мало, іноді багато.

Спадщина стає застарілим , коли система вже не може служити (все) потреб клієнта. Ця етикетка - це те, над чим ми повинні бути обережні. В іншому випадку це просто співвідношення витрат / вигод; якщо вартість модернізації буде нижчою, ніж вартість її переваг (включаючи нижчі майбутні витрати на обслуговування), тоді оновлення, в іншому випадку, залиште його в спокої. Не потрібно виплювати слово "спадщина" тим же тоном, який ви зазвичай резервуєте для "податкової перевірки". Це абсолютно нормально ситуація.


Зважаючи на це, податкова перевірка повинна бути цілком нормальною ситуацією, щоб також бути.
Флоріан Маргаїн

Я б сказав: Система, яка вже не може бути масштабованою завдяки наявній стеці технології.
Раміз Уддін

40

Зазвичай це означає, що він написаний мовою або заснований на системі, в якій ти зазвичай не робиш нових розробок.

Наприклад, більшість місць не пишуть нові програми в Cobol. Однак значна частина їх бізнесу може працювати на додатках, написаних на Cobol. Отже, ці програми позначаються "Спадщина".


Я найбільше згоден з цією відповіддю. Legacy - це більше про те, щоб застрягнути на застарілій платформі, ніж набридлий (але сучасний) код, який ви не хочете підтримувати. Спадковий код часто є досить хорошим (інакше ніхто не буде байдужим, якщо ви його залишите!), Але зазвичай він пов'язаний із застарілим обладнанням та старовинними мовами / бібліотеками / базами даних тощо.
Satanicpuppy

3
@Satanicpuppy: Я просто не можу погодитися - я мав справу з (на прикладі) деякою Java, яка напевно не була прив’язана до якогось конкретного обладнання, бібліотеки чи бази даних - але була такою ж "спадщиною", як це отримується (і було переписується на Java, тому і мова не була проблемою). Я також мав справу з деяким кодом, який був прив'язаний до конкретного обладнання, але все ще ледве переходив до категорії "спадщина".
Jerry Coffin

4
@jerry: Отже, що зробило це у спадщину? Спадщина не є синонімом «поганого».
Satanicpuppy

1
У випадку, про який я думаю, це була досить велика розподілена система (побудована навколо BEA Tuxedo). Дизайн здавався заснованим на сценаріях підручників, які призначені для навчання синхронізації шляхом максимального збільшення кількості синхронізації разів / місць. Це (свого роду) має сенс для текстової книги, але це справді жахливо для реальних конструкцій. Це було досить багато, що навіть архітектурна заміна була багаторічним проектом. Заміну довелося проводити поетапно, без часу простою, оскільки система вкрай необхідна бізнесу.
Джеррі Труну

1
@Cawas: Мені здається, відповідь @ Чада застосовуватиметься, коли / якщо нова система робилася іншою мовою, або використовувалося інше обладнання, і т.д. Я не вважаю, що це застосовується.
Джеррі Труну

28

Спадщина означає будь-який код, який ви краще заміните, ніж працюєте. Враховуючи ставлення більшості програмістів до більшості існуючих кодів, це, як правило, включає майже все, крім того, що ви зараз активно пишете (і для великого проекту, де вам потрібно кодувати заморожений дизайн, навіть те, що ви пишете в момент можна також включити).

  1. Наголос "скоріше" призначений для того, щоб переконати, що застарілий код також означає, що ви затрималися працювати з ним, хоча і не хочете. Я не впевнений, що наголос був достатнім. Причини цього можуть бути різними. Деякі насправді є занадто великими і складними для заміни. Інші - це інтерфейси до інших систем. Інші люди керуються політикою та персоналіями (наприклад, код жахливий, але будка немовля була дивовижною).
  2. Ще один момент, який я, можливо, не наголосив достатньо на тому, що, хоча якість коду може бути фактором, він рідко (якщо взагалі є) єдиним фактором - а часто навіть не особливо важливим.
  3. Я думаю, що люди, що підштовхують тести до одиниць , є єдиним визначальним фактором, як хлопець, що дивиться під вуличне світло для сережки, яку його дружина відкинула. Світло може бути кращим, але ви все ще шукаєте в неправильному місці. Подумайте, перш ніж випити пит-кула .
  4. (Дослідження до 3.) Мені здається, що деякі люди більше говорять про те, як вони бажають, щоб все було, ніж про те, як вони є насправді. Якщо « Життя життя Джона Конвейса для Apple IIc Plus» не є спадщиною, то це тому, що це достатньо мало і просто, що легко реалізувати з нуля. Найдосконаліше одиничне тестування, яке колись написано, не змінить жодної йоти .

Останній пункт дійсно веде до двох інших пунктів, які, на мою думку, часто відповідають дійсності.

По-перше, код часто зберігається як спадщина, навіть коли він насправді не повинен бути. Зазвичай керівники вищого рівня припускають, що повторна реалізація системи обійдеться стільки ж, скільки дорожчала початкова реалізація, що рідко буває так.

По-друге, одиничні випробування - це меч з двома ребрами. Вони змушують занадто легко думати, що важливі значення мають локалізовані зміни в реалізації. Щоб зробити значні вдосконалення в більшій системі, вам часто (зазвичай?) Доводиться досить змінювати загальну конструкцію, щоб багато (якщо не більшість) тестових приладів стали неактуальними. На жаль, наявність одиничних тестів та відношення, яке вони формують, можуть зробити занадто легко ігнорувати зміни, які справді необхідні.

Можливо, приклад цього допоможе: припустимо, що програма має бібліотеку інтерфейсу користувача з великим тестуванням одиниць і декілька програм, які використовують цю бібліотеку. Хтось із вищого керівництва переконується, що "ввімкнено Інтернет" є важливим (і, просто для аргументації, припустимо, що в цьому випадку він насправді в цьому прав). Після ретельного огляду менеджери середніх служб виявляють, що їх тестування на сьогоднішній блок достатньо, щоб вони могли змінитись із користувальницького інтерфейсу, який відображається за допомогою можливості віконної локальної операційної системи, щоб відображатися віддалено через HTML / CSS / AJAX, зберігаючи всю початкову перевірку вхідних даних.

Це чудово, чи не так? Він показує, наскільки корисним може бути тестування одиниць. Ми замінили всю реалізацію всього інтерфейсу, але переконалися, що зовнішній вигляд, відчуття та функціональність залишаються практично послідовними, а всі дані користувачів перевірені для забезпечення цілісності даних. Блок тестування врятував день!

Чи ні! Ця велика, гнучка, ретельно перевірена бібліотека користувальницького інтерфейсу допомогла засліпити всіх причетних до того, що для цієї програми на ринку з її користувачами веб-інтерфейс - це зовсім неправильна справа. Насправді потрібен веб-сервіс з RESTful інтерфейсом і абсолютно не має власного інтерфейсу.

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


3
Дивіться, зараз я не знаю, відзначати це чи ні, на жаль це правда, але мені цікаво, чи це ставлення, від якого нам потрібно піти ...
Нім

+1. Я збирався щось відповісти в однаковій мірі. Спадщина - це будь-який код, який використовується, а не активно підтримується.
Дені де Бернарді

@Nim: Я не думаю, що це "ми" повинні піти від нас. Це просто твердження очевидного. :-) Подумайте про це на мить і поцікавтеся, що б ви вважали застарілим кодом, якби приїхали в нове середовище; це буде все, окрім нових та класних речей, які активно розробляються.
Дені де Бернарді

@ Jerry, тож тобі не подобаються одиничні тести? ;)
Нім

1
@Nim: Не так - я думаю, що вони корисні, але далеко не панацея, яку вони часто зображують.
Джеррі Труну

17

Спадковий код, як правило, є осиротілим якимось чином. Провідний розробник, єдиний хлопець, який це зрозумів, потрапив у автобус, а його замітки були написані на його рідному українському діалекті, який зараз є мертвою мовою. Або по черзі все, що написано у Visual Basic 6.0 .

Я працюю над застарілим кодом увесь час. Я б сказав, що характеристики такі:

  • Її неможливо продовжити без великих зусиль
  • Його неможливо легко перенести на нове обладнання
  • Це занадто важливо для бізнесу, щоб його легко замінити

Якщо він не має цих характеристик, то, ймовірно, це не є спадщиною. Якщо вам не подобаються сценарії Perl ваших попередників , я співчуваю, але не думаю, що це спадщина. Нещодавно я модернізував певний 15-річний сценарій Perl, який був укладений у застарілу базу даних Sybase . Це був пиріг порівняно із внесенням навіть найменших змін до нашої жахливої системи обліку COBOL .


Страшно, наш головний розробник теж український ... ха-ха ... Я згоден із середньою частиною вашої відповіді, перший пункт - не так вже й багато - я думаю, це залежить від того, як налаштована ваша команда розробників.
Нім

1
хаха, вам, напевно, вдалося образити (водіїв автобусів, українську мову та VB6 Devs) все в одному абзаці. Але чорт я посміявся :)
Темна ніч

Я мандрівник у часі з 1999 року, ви маєте на увазі Visual Basic 6 - це спадщина з 2011 року?
hjk

@hjk Я б сказав, що майже все після появи C # / asp.net у 2005 році буде хиткою, але, безумовно, колись кінець підтримки від Microsoft
скажеться

12

У своїй книзі « Ефективно працюючи зі застарілим кодом» Майкл Перо визначає застарілий код як код, який не покривається одиничними тестами. Це одне визначення, з яким я згоден. Я також бачу застарілий код як старий, але все ще корисний.


24
Це вражає мене випадком спроби визначити "все, що не відповідає моїй обраній методології", як "спадщину". Це не більше, ніж дешева тактика дебатів, в основному просто прийняття закону Годвіна і пом'якшення мови (ледь) достатньо, щоб читачі не враз усвідомлювали, що це не що інше, як непідтримуваний (і часто непідтримуваний) напад на всіх, хто не дотримується його уподобання.
Jerry Coffin

4
@Jerry: Я згоден з визначенням Пера. Код без тестових одиниць - це жах для роботи. Якщо ви вирішили переробити деякі частини його частини, щоб стало простіше міркувати про це, забудьте про це! ви, можливо, вводите помилки та код, ймовірно, таким, яким він є, це не можна зрозуміти! Я вважаю, що визначення Пера є нетрадиційним, але він є тим, хто заробляє на життя, працюючи зі спадковим кодом.
пожирав елізіум

10
@devoured: одиничні тести не є точним лакмусовим тестом на здатність працювати з кодом. Я мав справу з кодом, у якого бракувало одиничних тестів, але був вітер - і з кодом, який мав одиничні тести, і все ще був кошмаром. Зрештою, одиничні тести самі по собі нічого не вирішують. Експертні випробування конструкції, в якій (наприклад) розподіл на одиниці було зроблено погано, все ще можуть бути абсолютно марними, і всю конструкцію (включаючи тести) потрібно викинути заміненою, щоб створити щось корисне.
Джеррі Труну

6
Я згоден з коментарями Джеррі. Відсутність одиничних тестів - це лише одна з купових запахів коду, які можуть (або не можуть ) свідчити про поганість.
smci

4
Я знову погоджуюся з визначенням Пера, а також пожирає. Відсутність одиничного тесту - це все , що означає, що навіть у найкрасивішому фрагменті коду немає його технічних характеристик. Одиничні випробування складають 51% документації та 100% специфікації коду. Код, на якому відсутня більша частина його документації, і всю його специфікацію по праву слід класифікувати як спадщину.

8

Технічно спадщина - це будь-який код, написаний готовим. Тож як тільки воно з’являється у виробництві, це спадщина. Тому що там вже є цінність, ви її не можете просто викинути ... Ви повинні з цим боротися.

Це "до свого часу", але "все одно ваш головний біль" .


5

Спадковий код - це код, який залишається лише в базі коду, оскільки багато речей припинять роботу в іншому випадку. Іншими словами: єдиною причиною існування є відстала сумісність.

Ви б краще змінити його або навіть викинути, але не можете, оскільки ви порушите весь код, спираючись на нього (який може бути кодом, який ви не зможете відповідно адаптувати). Тому ви повинні зберігати його (а іноді навіть підтримувати), але бажаєте, щоб увесь новий код не був написаний проти нього.

Прикладом є застарілі методи API бібліотеки. Вони все ще існують, так що якщо той, хто оновлює бібліотеку, все ще може створити свій проект, але вони позначені як застарілі, і ви, компілятор, повинні вам попередити.

Іншим прикладом є всі ті дивні хитрощі, які робить Microsoft, щоб змусити програми запускати програми, написані для версій своєї ОС, вони повністю застаріли. Вершина цієї істоти:

Я вперше почув про це від одного з розробників хіт-гри SimCity, який сказав мені, що в його застосуванні була критична помилка: вона використовувала пам’ять відразу після її звільнення, головний ні-ні, що трапилося, щоб вона працювала нормально на DOS, але не працює в Windows, де звільнена пам'ять, швидше за все, буде вирвана іншим запущеним додатком відразу. Команда тестувальників Windows переглядала різні популярні програми, перевіряючи їх, щоб переконатися, що вони справні, але SimCity продовжував виходити з ладу. Вони повідомили про це розробникам Windows, які розібрали SimCity, перейшли через нього в налагоджувач, знайшли помилку та додали спеціальний код, який перевіряв, чи працює SimCity, і якщо це робиться, запускав розподільник пам'яті в спеціальному режимі, в якому ви все ще може використовувати пам'ять після звільнення.
- Джоель із програмного забезпечення


4

Спадщина тягне за собою спадкування. Спадковий код - це просто код, який ви успадковуєте з минулого. Це застарілий код, навіть якщо ви його самі раніше писали!

Всі інші міркування виходять в основному з того, що ви не написали це спеціально для свого поточного проекту. Це не обов'язково сама по собі погана справа.


Минуле може бути 1 день, 1 година або 1 рік. Це не робить його спадщиною.
Вінс Пануччо

2

На мою думку, те, що вважається застарілим кодом, залежить від кількох речей, а тег "спадщина", ймовірно, залежить від організації.

Якщо апаратне забезпечення / ОС, на яких він працює, старі, і продавець їх припинив - ударіть 1.

Якщо це більше роботи, спробувати виправити це, ніж переписати, з будь-якої причини тому

  • оригінальних розробників / ів вже немає
  • програма погано написана
  • це можна зробити краще на більш новій платформі, і все-таки це варто компанії

робити так

  • оригінальне джерело більше не доступне та / або відсутні деталі

Страйк 2.

Злиття декількох організацій в одну - Страйк 3 - одна сторона, ймовірно, буде позначена як спадщина.

Чи є краща, дешевша альтернатива, що продається як стороннє додаток та / або послуга - страйк 4.

Чи є організація чимось на зразок лікарні чи шкільного округу, де цінність оцінюється щодо нових технологій, коли мова йде про щоденні операції? Додаток буде вважатися застарілим порівняно з тим самим додатком у комерційній / конкурентній організації.

Якщо компанія є невеликою розробковою компанією, яка продовжує вдосконалювати / підтримувати додаток для того, щоб робити те, що потрібно клієнтам, чи вважається це застарілим кодом або просто "старим" кодом. Я знаю компанію на ім’я Mc2Ok - вони розробили програмне забезпечення для того, що, здається, було Windows 3.1, і просто продовжували його переносити вперед. Він все ще має вигляд Windows 3.1, але вони також додали до нього веб-інтерфейс. Це двомісна компанія-розробник (я здогадуюсь), і я б сказав, що коли вони кинуть працювати над нею, то це буде вважатися спадщиною, і час перейти через рік-два після його використання. Але це може бути ще 10 і більше років.

Іноді, коли управління змінюється, воно може змінюватися хвилями, які мають безліч ефектів потік ... Залежно від принципу роботи нового управління, він може передати у спадщину багато програм, які в іншому випадку можуть бути просто чудовими.

Я вважаю, що кожна організація повинна визначити, що для них означає "спадковий код". Я раніше щотижня переглядав оголошення оголошень The Sunday Times і бачив, що шукають організації. Це був моїм барометром для того, що вже не було актуальним (тобто спадщиною). Що ж, The Sunday Times вже не актуальний :-) І ми можемо узагальнити, що COBOL є спадщиною, ASP Classic - це спадщиною тощо. Але я вважаю, що кожна організація повинна вирішити, коли заявка вважається спадщиною для неї.


+1, приємна відповідь - краще розглянути щось спадщину з погляду органу ...
Нім

0

Код - це спадщина, коли хтось боїться його змінити, бо може його порушити. Ще болючіше, коли вся система може бути розбита на колінах завдяки змінам цього коду.

Тому я також погоджуюся з визначенням Майкла Пір'я. Код, що має хороші одиничні тести, можна безстрашно змінювати.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.