У сукупності: як ми будемо підтримувати застарілі системи? [зачинено]

Нью-Йорк - Під час вибуху, який змусив хмарочоси тремтіти, 83-річний паропровід надіслав потужне повідомлення про те, що милі труб, проводів і заліза під Нью-Йорком та іншими містами США старіють і можуть стати небезпечно нестабільними.

Липень 2007 р. Історія про розривну парову трубу на Манхеттені

Ми чули про гниття програмного забезпечення та технічну заборгованість .

І ми чули від подібних:

• "Дядько Боб" Мартін - Хто попередив нас про " наслідки внесення безладу ".
• Майкл К. Пір'я - Хто дав нам рекомендації щодо «Ефективної роботи зі спадковим кодексом» .

Отож, безумовно, спільнота інженерних програмних програм знає ці проблеми.

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

Як зазначає Стів МакКоннелл :

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

Якщо це правда, і я вважаю, що це так, то я побоююся, що уряди та підприємства можуть відкласти регулярне обслуговування та фортифікацію проти хакерів, поки не пізно. [Начебто як Нью-Йорк і парові труби.]

Моє запитання:

• Чи є спосіб, щоб ми могли уникнути програмного еквівалента NYC та паропроводів?

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

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

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

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

Однак, на практиці, я думаю, що буде:

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

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

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

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

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

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

Більшість підприємств вже не знають про технічну заборгованість і навіть не усвідомлюють, що справи погані, поки він буквально не обвалиться навколо них і не відправить їх у банкрутство (якщо він коли-небудь потрапить до цього моменту). Я насправді бачивце трапляється, і це було не дуже; що погіршило те, що я неодноразово намагався повідомити власників бізнесу про зростаючу технічну заборгованість і про те, що це доведеться виправляти, і кожен раз його відхиляли через небажання витрачати потрібний час та ресурси на виправлення це. Кінцевим результатом було через 10+ років система, нарешті, катастрофічно вийшла з ладу (після того, як я пішов), і вони не змогли відновитися, і пішли з бізнесу, бо були занадто дурні, щоб усвідомити протягом цих десяти років, що витрачають трохи грошей на виправити проблему було б краще, ніж цілком її ігнорувати. Я міг битися годинами про безглузду дурість цієї компанії, і що мене найбільше болило, це можна було цілком уникнути, якби власники не були просто зробити швидкий долар, вирізавши все інше цілком.

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

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

Милі труб, дротів і заліза під Нью-Йорком та іншими містами США старіють і можуть стати небезпечно нестабільними.

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

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

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

Ми пережили помилку Y2k. Помилка Y2036 змусить багатьох організацій оновити обладнання та програмне забезпечення. Світ міг би закінчитися у 2012 році. Але комп'ютерні науковці - не соціологи чи літературознавці .

О, і, як сказано тим часом: пишіть код так, ніби наступний супровідник - злий психопат, який знає, де ви живете.

Я забуваю, що ми вважаємо застарілим кодом сьогодні? Код минулого року, код минулого десятиліття чи код минулого століття?

Гроші ведуть розмову про підтримку застарілих систем. Технічна заборгованість приймає свою форму як збільшення витрат на зміну системи.

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

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

Що стосується обіцяного переписування, то більшість систем, які мали величезні інвестиції, не виправдовують перезапис. Дивно, як довго можна продовжувати працювати і вдосконалювати програмне забезпечення. Зміни обладнання (деякі системи, які підтримує моя компанія, використовують спеціалізоване обладнання), як правило, є нашою найбільшою проблемою. Можливість вдосконалення часто обмежується лише механізмами інтеграції застарілого коду з новими можливостями.

Це вже велика проблема. І це не показує ознак зміни.

У 60-70-ті роки великі установи усіх видів перейшли від ведення бухгалтерського обліку на папері до ведення обліку на обчислювальних системах. Переважно вони вибрали COBOL. Більшість досі використовують оновлені версії цих систем COBOL. Дивіться http://cis.hfcc.edu/faq/cobol для деяких статистичних даних щодо цього

Кожна так часто ми отримуємо випадкові нагадування про це, наприклад, коли Арнольд Шварценеггер пару років тому виявив, що він не міг просто знизити зарплату 200 000 державних службовців без 6 місяців розвитку спочатку (див. Http: //www.infoworld. com / d / світ розробників / californias-cobol-conundrum-067 для перевірки).

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

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

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

У 1970-х роках компаніябула заснована з метою створення інтернет-ринку для торговців. PDP-11 підходив для них гарною ціною / продуктивністю, тому вони вибрали саме це. Вони просували межі продуктивності машини, тому вони написали свою систему у високооптимізованій збірці PDP-11. Через кілька років PDP-11 перестали продаватися. Однак бізнес був чудовим, машини тривали, і заміни в секонд-хенді було легко підійти. Вони зберегли свою платформу. Через кілька років заміни стало важче прийти. Був зроблений великий проект із заміни торгової платформи. Це не вдалося. Вони спробували ще раз. І знову не вдалося. Головною причиною відмови було те, що ніхто не знав, як працює система торгівлі, і ніхто вже не міг прочитати збірку PDP-11. Тоді порятунок вдарив. Хтось створив асемблер PDP-11, який працював на Linux.

Таким чином, у 2000 році торги, що займаються бізнесом на мільярд доларів / рік, переходили на машини Linux, через міст Ethernet-деконета, на емуляцію машин PDP-11, які здійснювали торгівлю на програмній системі, яка була написана високооптимізованою PDP- 11 збірка. Для швидкості.

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

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

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

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

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

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

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

Попередження: Це буде трохи вільної форми ...

Я думаю, що є два способи поглянути на свою стурбованість.

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

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

Але наше середовище змінюється. І якимось чином, що є ключем до вашої проблеми - це також рішення. Наше середовище змінюється так швидко, що в наш час ми не очікували, що програмне рішення не розвиватиметься з часом. Ми не помічаємо програмних проектів, які не оновлювалися в минулому році, і будемо стогнати щодо підтримки продуктів та клієнтів, які не дають чіткої дорожньої карти. І навіть коли це добре виходить - ви отримуєте чітку дорожню карту, гарну підтримку, регулярні оновлення ... - зараз завжди є шанс, що виклик вийде з експоненціальним зростанням. Ми часто робимо помилку, думаючи, що великі створені компанії завжди будуть домінувати саме через те, що вони домінують. Однак тим самим чином, коли домінуючий елемент у стаді стає дорослішим, надмірно масивне програмне забезпечення / обладнання / будь-який постачальник старіє. Або просто трохи лінивий. І приходить претендент і обертає справи навіть швидше, ніж встановлена ​​домінанта могла це зробити за 5 або 10 років до цього. Або домінанти просто приймуть добру побиття, ледве виживши, поки ми побачимо зрив на ринку (економічно кажучи, з впливом на різні сфери), і тоді все буде продовжуватися. Можливо, це виглядає недосконало, але саме по собі це органічний процес.

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

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

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

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

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

Джефф Лангер у "Чистому кодексі" задає подібне запитання ... без посилань на парові труби:)

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

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

За словами Кента (у поясненні екстремального програмування), дизайн є "простим", якщо він дотримується цих правил:

• Виконує всі тести
• Не містить дублювання
• Висловлює наміри програміста
• Мінімізує кількість класів і методів

Для того, щоб виконати всі тести ... нам потрібні тести для запуску, і це один величезний показник технічної заборгованості. Наприклад, якщо в такій системі, як Центр якості Меркурія, є 10 000 тестових випадків, і жоден з цих тестів не є автоматизованим, це є одним із чітких показників технічної заборгованості, яка була накопичена.

І саме тут потрапляє Пір'я та його книга "Ефективна робота зі спадковим кодом".