Теория эволюции программного обеспечения в эпоху искусственного интеллекта
Теория эволюции программного обеспечения в эпоху искусственного интеллекта

Мир, в котором бизнес и программное обеспечение больше не могут быть разделены
Сегодня во многих компаниях большая часть принятия, исполнения, проверки и улучшения решений происходит в системах ПО. Точки взаимодействия с клиентами, изменения цен и контрактов, корректировка поставок и запасов, сбор и анализ журналов, а также внутренние операционные рабочие процессы — все это глубоко зависит от ПО. Это уже не тот этап, когда ИТ просто были внедрены; сама работа бизнеса привязана к состоянию его ПО, а возможность обновления ПО стала эквивалентной возможности обновлять бизнес.
Эта ситуация не ограничивается конкретными отраслями. В разных секторах и размерах компаний предприятия, которые работают с определенным уровнем скорости и сложности, больше не могут функционировать без ПО в своей основе. Поскольку внешние условия меняются быстрее и частота циклов решения-исполнения увеличивается, способность меняться сама становится конкурентным фактором. Когда изменения в ценности клиента, условиях обслуживания, операционных ограничениях, нормативных требованиях и структурах затрат совпадают, бизнес, который не может обновить свою ПО, не может преобразовать решения в действия, не может вносить исправления и в конечном итоге останавливается.
В этой среде наблюдается множество случаев, когда обновления ПО становятся узким местом для принятия бизнес-решений и изменений политики. Решения могут быть приняты, но структурные изменения, необходимые для их реализации, не могут быть завершены вовремя, что сужает круг инициатив, которые можно реально протестировать.
Чем дольше происходят обновления ПО, тем больше становится расстояние между решением и исполнением. Во время этой задержки условия окружающей среды продолжают меняться. В результате все больше решений остаются невыполненными, а диапазон деятельности бизнеса постепенно сужается.
Общие характеристики долгоживущего программного обеспечения
Когда мы смотрим на ПО, который использовался в течение длительного периода времени, редко можно найти системы, которые остаются в исходном состоянии. Добавляются функции, меняются конфигурации, эксплуатация корректируется, и ПО приобретает форму, совершенно отличную от его первоначального дизайна. Редко бывает, чтобы ранние спецификации или проектная документация полностью соответствовали реалиям реализации и эксплуатации годы спустя. Это не означает, что первоначальный замысел был бессмысленным; скорее, это отражает наблюдение о том, что условия, принятые вначале, трудно сохранить в течение длительных периодов эксплуатации.
Поскольку ПО продолжает использоваться, задачи и решения, которые изначально не предполагались, становятся частью повседневной жизни эксплуатация. Поведение пользователей меняется, объем и значение данных меняются, а отношения с окружающими системами меняются. Накапливается дополнительная обработка, реорганизация, замены и обходные пути. То, что поначалу кажется небольшим исключением, со временем становится нормой, и эти нормы выталкивают внутреннюю структуру наружу. Со временем дизайн, который когда-то был простым, становится более сложным, поскольку он учитывает требования реального мира.
Также редко одни и те же люди остаются ответственными на протяжении всего срока службы системы. Разработчики и операторы меняются, организационные структуры развиваются, роли перераспределяются. Даже когда документация сохраняется, контекстуальные предположения, лежащие в основе прошлых решений, не полностью разделяются. Теряется не объем информации, а набор условий, при которых предыдущие решения имели смысл. Когда эти предположения исчезают, один и тот же текст больше не приводит к одним и тем же выводам. Изменения становятся более осторожными, количество локальных обходных путей увеличивается, а общая согласованность постепенно ухудшается.
Связь между продолжением использования и структурными изменениями
Эти изменения не возникают в результате конкретных сбоев или исключительных обстоятельств. Подобные закономерности неоднократно наблюдаются в разных организациях, отраслях и технических областях. Их объединяет то, что ПО используется в течение длительных периодов времени, в то время как окружающие условия продолжают меняться. Хотя природа этих изменений различается в зависимости от контекста, тот факт, что изменения сохраняются, является общим.
Небольшие различия в предположениях накапливаются со временем. Корректировки, которые когда-то могли быть внесены посредством рутинных эксплуатация, в конечном итоге требуют структурного пересмотра. На этом этапе вес и масштаб изменений возрастают. По мере расширения диапазона воздействия растут затраты на проверку, откат становится сложнее, а принятие решений замедляется. Когда решения принимаются медленно, компании больше не могут тестировать то, что хотят попробовать. Это состояние не низкого качества, а заторможенного обучения — и чем быстрее меняется окружающая среда, тем более разрушительным это становится.
Временная структура развития, предполагающая завершение
Многие разработки традиционно следовали модели, согласно которой проекты максимально дорабатываются до начала реализации. Этот подход оказался эффективным для достижения консенсуса, обеспечения разделения труда и управления масштабными проектами. В средах, где затраты на внедрение высоки, а экспериментирование дорого, раннее закрепление проектов было практическим выбором, а проектирование служило для предварительного снижения сложности.
Однако этому подходу присущи ограничения временной структуры. С момента завершения проекта условия, которые он предполагает, начинают меняться. Чем больше разрыв между завершением проектирования и реализацией, тем больше расхождение между предположениями и реальностью. Когда условия быстро меняются, это расхождение может стать значительным к моменту завершения работы системы. Изменения часто происходят не в мелких деталях спецификации, а в фундаментальных приоритетах, эксплуатационных ограничениях или значении данных.
Это не означает, что проект был неправильным. Во многих случаях это было лучшее решение на тот момент. Проблема возникает, когда не учитывается тот факт, что предположения будут меняться с течением времени. Если корректировка после завершения не встроена, систему будет сложно обновить в момент ее завершения. Когда завершение рассматривается как точка доступа, последующие изменения обрабатываются как исключения, накапливающиеся как запоздалые мысли. Со временем обновления накапливаются в виде локальных исправлений, структура становится жестче, а скорость обучения бизнеса снижается.
Роль накопленного опыта
Такой подход к развитию возник по понятным причинам. Высокие затраты на реализацию и тяжелое бремя экспериментов сделали необходимым раннее планирование. Способность оценивать условия, организовывать зависимости и заранее определять полную систему играла решающую роль в таких средах. Достижение консенсуса, ранняя загрузка рисков и структурированное разделение труда были практическими потребностями.
По мере изменения условий меняется и положение ценности. Прошлые суждения, неудачи и корректировки не становятся недействительными. Вместо этого на них ссылаются и применяют по-разному. Опыт, полученный в ходе обзоров проектов, больше не используется для точного прогнозирования будущего, а используется для определения того, где системы могут выйти из строя при изменениях. Практические уроки позволяют понять, какие основы должны оставаться неизменными, а какие области должны оставаться гибкими. Прошлый опыт не отбрасывается; он используется повторно.
Поскольку такое повторное использование становится возможным, ценность опыта часто увеличивается, а не уменьшается. В быстро меняющихся условиях неправильные суждения быстро усиливаются. Более низкие затраты на эксперименты означают больше попыток, в том числе ошибочных. В результате качество расстановки приоритетов и направленных суждений оказывает большее влияние на результаты.
Изменения условий разработки
В последние годы в условиях развития произошли явные изменения. Стоимость внедрения и экспериментирования снизилась, а время, необходимое для превращения гипотез в проверяемые формы, сократилось. Частично этот сдвиг обусловлен широким распространением ПО на базе искусственного интеллекта, который напрямую поддерживает генерацию и модификацию кода. Эти инструменты снижают первоначальные затраты на проверку реализаций и позволяют опробовать, отбросить и реструктурировать проекты.
Здесь важно не то, будет ли принят ИИ, а то, что условия изменились. Когда условия меняются, меняются и структуры, эффективно функционирующие в них.
Важно отметить, что речь не идет о противопоставлении развития, движимого искусственным интеллектом, развитию, движимому человеком. Происходит сближение человеческих суждений, таких как расстановка приоритетов, структурные решения и контекстуальное понимание, с генерацией и модификацией кода с помощью ИИ. Люди решают, что попробовать и где изменить; ИИ снижает стоимость реализации этих решений. Благодаря этому сотрудничеству экспериментирование и обучение на скоростях, ранее невозможных, стали возможными.
В результате разработка, которая постоянно обновляет ПО в соответствии с изменениями в бизнесе, впервые стала реалистичным вариантом.
Структуры, которые остаются жизнеспособными в меняющихся условиях
В этих условиях структуры, допускающие корректировку постфактум, более управляемы, чем те, которые пытаются исправить все заранее. По мере роста масштаба и развития требований возможность пересматривать и изменять структуру становится обязательным условием. Это не означает отказ от дизайна. Это означает сужение фиксированной основы, четкое определение того, что должно оставаться гибким, и сохранение возможности постепенной реорганизации структуры с четкими приоритетами. Фундаментальный дизайн становится более важным, а не менее важным.
По мере масштабирования систем инфраструктура неизбежно заменяется. Конфигурации, которых когда-то было достаточно, требуют механизмов избыточности, разделения, распределения, наблюдения и восстановления. Продолжающийся эксплуатация требует реорганизации и расширения функций. В реальных средах обновления, понижения версий, откат, поэтапная миграция, параллельная работа и частичная замена — это рутинные действия, а не исключительные инциденты. Структуры, которые не могут перемещаться вперед и назад, увеличивают риск и затраты с каждым изменением, что в конечном итоге приводит к полной остановке обновлений.
По этой причине структуры ПО должны поддерживать обратимость и заменяемость. Когда границы неясны и системы растут в одном направлении, изменения распространяются широко, проверка становится грубой, а откат затруднителен. Четко определенные границы и модульные сменные блоки позволяют продолжать обучение, несмотря на изменения.
Эти решения не могут быть оставлены на усмотрение только индивидуальной изобретательности. Определение того, что остается неизменным, что остается гибким и какие изменения приемлемы, следует рассматривать как общие предположения. Это требует большего, чем просто выбор инструментов или стандартов кодирования; это требует общего тактического понимания. Там, где такое общее мнение отсутствует, обновления становятся индивидуальными, скорость снижается и обучение прекращается.
Опыт, который продолжает использоваться повторно посредством изменений
Каждый раз, когда условия меняются, к ПО и бизнесу добавляются новые ограничения. Хотя прошлые проекты и реализации больше не могут применяться напрямую, это не отменяет лежащий в их основе опыт.
Суждения, сформированные в результате предыдущих изменений (понимание того, где системы ломаются, где возникают узкие места и как далеко распространяются изменения), продолжают использоваться, когда условия снова меняются. Даже когда форма меняется, эти суждения вновь всплывают на поверхность при принятии решения о том, что делать дальше и куда вмешаться.
В современных средах разработки сочетание человеческого ситуационного суждения и реализации с помощью искусственного интеллекта позволяет применять такой опыт с гораздо более короткими интервалами. Накопленные знания остаются заложенными в качество суждений и перетекают непосредственно в последующие реализации и проверки.
В результате системы не перестраиваются с нуля при каждом изменении, а прошлые формы не сохраняются жестко. Вместо этого опыт используется повторно по мере изменения условий, и ПО развивается соответствующим образом.
Изменения будут продолжаться. Появятся новые технологии и ограничения. Но накопленный опыт не будет потерян. По мере увеличения скорости и частоты повторного использования опыта его ценность становится более непосредственно и последовательно отражаться на результатах.


