В совокупности: как мы будем поддерживать устаревшие системы? [закрыто]

НЬЮ-ЙОРК. Взрыв, вызвавший дрожь небоскребов, показал, что 83-летняя паровая труба послала мощное сообщение о том, что мили труб, проводов и железа под Нью-Йорком и другими городами США стареют и могут стать опасно нестабильными.

Июль 2007 г. Рассказ о взрыве паровой трубы на Манхэттене

Мы слышали о программной гнили и технических долгах .

И мы слышали от таких как:

• «Дядя Боб» Мартин - Кто предупредил нас о « последствиях беспорядка ».
• Майкл С. Перья - кто дал нам руководство для «Эффективной работы с устаревшим кодом» .

Конечно, сообщество разработчиков программного обеспечения знает об этих проблемах.

Но я чувствую, что наше объединенное общество не понимает, как эти проблемы могут мешать работе систем и приложений.

Как отмечает Стив Макконнелл :

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

Если это правда, и я верю, что это так, то я боюсь, что правительства и компании могут отложить регулярное обслуживание и укрепление против хакеров, пока не станет слишком поздно. [Очень похоже на Нью-Йорк и паровые трубы.]

Мой вопрос:

• Есть ли способ, которым мы можем избежать программного эквивалента Нью-Йорка и паровых труб?

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

Я недавно задал вопрос в том же духе относительно того, заинтересованы ли молодые программисты в мэйнфреймах вообще. Консенсус склонился к нет.

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

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

Однако на практике я думаю, что произойдет:

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

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

Тем не менее, для каждого человека, который купит мэйнфрейм IBM, потому что вы можете запускать на нем Linux, он стоит меньше электроэнергии и является высокоэффективным, у вас будет еще несколько человек, которые выберут ферму серверов, потому что они более знакомы с этим миром. и многие другие программисты.

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

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

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

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

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

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

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

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

К тому времени, когда целые городские кварталы рушились в землю, были даны указания заполнять ненужные ямы и туннели гравием и костями (у них также были переполненные кладбищенские проблемы). Город выжил таким образом, пока не был изобретен бетон.

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

Мы пережили ошибку Y2k. Ошибка Y2036 заставит многие организации обновить свое аппаратное и программное обеспечение. Мир может закончиться в 2012 году. Но компьютерщики не социологи и не литературоведы .

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

Я забыл, что мы считаем устаревшим кодом в наши дни? Код прошлого года, код прошлого десятилетия или код прошлого века?

Деньги ведут разговор об обслуживании устаревших систем. Технический долг принимает форму увеличения затрат на изменение системы.

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

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

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

Это уже большая проблема. И это не показывает никаких признаков изменения.

В 60-х и 70-х годах крупные учреждения всех видов перешли от бухгалтерского учета на бумаге к бухгалтерскому учету на вычислительных системах. В подавляющем большинстве они выбрали КОБОЛ. Большинство все еще используют обновленные версии этих систем COBOL. См. Http://cis.hfcc.edu/faq/cobol для получения некоторой статистики по этому вопросу.

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

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

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

Позвольте мне закончить с реальной историей того, что может произойти.

В 1970-х годах компаниябыл основан, чтобы обеспечить онлайн-рынок для трейдеров. PDP-11 подходил для них по соотношению цена / производительность, поэтому они выбрали именно это. Они раздвигали границы производительности машины, поэтому они написали свою систему в высокооптимизированной сборке PDP-11. Спустя несколько лет PDP-11 перестала продаваться. Однако бизнес был отличным, машины работали, и замена подержанных машин была легко найдена. Они сохранили свою платформу. Через несколько лет после этого стало труднее найти замену. Был сделан крупный проект по замене торговой платформы. Это не удалось. Они попробовали еще раз. И снова не удалось. Основной причиной сбоя было то, что никто не знал, как работает их торговая система, и никто больше не мог читать сборку PDP-11. Тогда спасение ударил. Кто-то создал ассемблер PDP-11, который работал на Linux.

Таким образом, в 2000 году сделки, приходившие на бизнес стоимостью в миллиарды долларов в год, приходились на машины Linux, через мост ethernet-decnet, на эмулированные машины PDP-11, которые выполняли торговлю на программной системе, которая была написана на сильно оптимизированном PDP-сервере. 11 сборка. Для скорости.

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

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

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

Или, если вы немного открыты для идеи свободного программного обеспечения, вы можете писать свои программы под свободной лицензией, такой как AGPL или GPL, или другими лицензиями свободного программного обеспечения. Из того, что я видел, когда источники программного обеспечения больше не интересуются разработчиками, чтобы улучшить его по любой причине, исходная база становится каннибализированной и приобретает новую жизнь. Насколько я видел, пакеты в операционной системе Debian, как правило, следуют этому жизненному циклу.

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

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

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

Предупреждение: это будет немного свободной формы ...

Я думаю, что есть 2 способа взглянуть на вашу проблему.

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

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

Но наша среда меняется. И как-то, что является ключом к вашей проблеме, также является решением. Наша среда меняется настолько быстро, что в настоящее время мы не ожидаем, что программное решение не будет развиваться со временем. Мы пропускаем программные проекты, которые не обновлялись в прошлом году, и будем стонать о продуктах и ​​поддержке клиентов, которые не дают четкого плана действий. И даже когда это работает хорошо - вы получаете четкую дорожную карту, хорошую поддержку, регулярные обновления ... - теперь всегда есть шанс, что претендент появится, с экспоненциальным ростом. Мы часто ошибаемся, думая, что крупные авторитетные компании всегда будут доминировать именно потому, что они доминируют. Тем не менее, так же, как доминирующий элемент в стаде стареет, супер-массивное программное / аппаратное обеспечение / любой поставщик становится старше. Или просто немного ленивый. И претендент приходит и меняет положение вещей даже быстрее, чем мог бы сделать установленная доминанта 5 или 10 лет назад. Или доминирующая сторона просто ударит, едва выживет, пока мы видим срыв на рынке (экономически говоря, с последствиями для разных областей), и тогда все будет продолжаться. Может быть, это выглядит несовершенно, но само по себе это органический процесс.

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

Теперь предположим, что мы не видим вещи с точки зрения пользователя, или что мы говорим о системе, которая защищена - по неизвестным причинам, правительственным разработкам, космическим путешествиям и т. Д. - - от конкуренции и действительно предполагается Чтобы быть построенным, чтобы жить / выживать в течение очень долгого времени, нам нужно взглянуть на тексты, на которые вы ссылались. И, возможно, еще немного литературы о надежных системах и отказоустойчивых системах. Хотя мы, вероятно, хотим двигаться дальше. Мы не просто хотим отказоустойчивости, мы хотим эволюционные системы.

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

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

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

Джефф Лангер в «Чистом коде» задает аналогичный вопрос ... без ссылок на паровые трубы :)

Что, если бы вы могли следовать четырем простым правилам, которые помогли бы вам создавать хорошие дизайны во время работы? Что если, следуя этим правилам, вы получите представление о структуре и дизайне своего кода, что облегчит применение таких принципов, как SRP и DIP? Что если эти четыре правила способствовали появлению хороших дизайнов?

Многие из нас считают, что четыре правила простого проектирования Кента Бека очень помогают в создании хорошо спроектированного программного обеспечения.

Согласно Кенту (в «Объясненном экстремальном программировании») дизайн «прост», если он следует этим правилам:

• Запускает все тесты
• Не содержит дублирования
• Выражает намерение программиста
• Минимизирует количество классов и методов

Чтобы запустить все тесты ... нам нужны тесты, и это один из огромных показателей технического долга. Например, если в системе, такой как Mercury Quality Center, имеется 10 000 тестовых случаев, и ни один из этих тестов не автоматизирован, это является одним из четких показателей накопившейся технической задолженности.

И вот тут-то и появляется «Перья» и его книга «Эффективная работа с устаревшим кодом».