Чи стосується гниття програмного забезпечення насамперед продуктивність чи безладний код?

Визначення Вікіпедії з програмного забезпечення гнилі фокусується на продуктивності програмного забезпечення. Це інше використання, ніж я звик; Я думав про це набагато більше з точки зору чистоти та дизайну коду - з точки зору того, що код має всі стандартні характеристики якості: читабельність, ремонтопридатність тощо. Тепер, швидше за все, продуктивність знизиться, коли код стане нечитабельним, бо ніхто не знає, що відбувається. Але чи має термін програмне забезпечення гниль особливе відношення до продуктивності? чи я маю рацію, думаючи, що це стосується чистоти коду? або це, можливо, випадок численних почуттів терміна, що використовується загалом, - з точки зору користувача, це має відношення до продуктивності; але для майстра програмного забезпечення він повинен конкретніше робити те, як читається код?

Цей термін не пов'язаний з роботою, принаймні, не де я бачив його.

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

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

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

• Хтось, хто зосереджений на тому, щоб зробити програмне забезпечення швидким, буде більш схильний шукати докази «гниття програмного забезпечення» у виконанні.

• Хтось, хто зосереджений на дизайні / архітектурі (наприклад, тому, що їм потрібно додати нові функціональні можливості або виправити помилки функціональності), з цього погляду побачить "гниття програмного забезпечення".

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

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

У Вікіпедії сказано, що гниття програмного забезпечення та гниття коду однакові. Я не погоджуюсь.

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

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

Програмне забезпечення насправді не погіршується, стає усталеним, зношеним або «гниє» в традиційному розумінні.

Якщо середовище, в якому функціонує програмне забезпечення, не зміниться, програмне забезпечення по суті буде вічно. Ось чому я так поглядаю, коли хтось запитує, чи є якась бібліотека "мертвою", оскільки автор не оновлював її протягом останніх 5 хвилин (лише трохи перебільшуючи ефект).

Але навколишнє середовище , як правило , робить зміна; Операційні системи виправлені та оновлені, комп’ютери замінюються на більш потужні, а також встановлюються нові програми (як-от остання версія такого клієнта, як Internet Explorer, драйвери пристроїв чи інші бібліотеки), від яких програмне забезпечення може залежати. Тому програмне забезпечення повинно бути оновлено, щоб врахувати ці зміни.

Існують програмні системи, які працюють постійно та надійно впродовж буквально десятиліть без істотного оновлення чи обслуговування. Програмне забезпечення COBOL, що працює на мейнфреймі, що обробляють банківські транзакції, приходить до тями (хоча їх потрібно було модифікувати в 1999 році, щоб обробити Y2K).

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

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

Визначення Wikipedia on Software rot не встановлює стандарт, оскільки його також пишуть деякі люди. Я думаю, що цей термін має різноманітне значення і його потрібно розділити на конкретні сфери, де він визначається.

• Програмісти можуть розуміти це як нездійсненну базу коду з повною антидіаграмою, без узгодженості стилів іменування та кодування.
• Системні адміністратори можуть сприймати це як погану продуктивність, повну витоку пам'яті та пекла. обслуговування.
• Кінцевий користувач може розуміти це як дуже складне, неінтуїтивне, важко працююче програмне забезпечення.

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