Целина, пустырь, бетонные джунгли и Материализация Идей

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

От целины к каменным джунглям

Большую часть моей профессиональной жизни я занимался автоматизацией труда различных специалистов. В самом начале самые массовые интеллектуальные операции (вычисления на ручных калькуляторах, подготовка документов, черчение, картография и т.д.) «перепоручались» компьютерам (которые тогда назывались ЭВМ). В англоязычной литературе такое программирование получило название „целинного» („green field“). 

Со временем “целины” становилось всё меньше и меньше, вместо “бескрайних просторов” человеческой деятельности для автоматизации оставались отдельные, только частично незанятые участки. 

Системы первого поколения, работавшие на больших mainframes стали заменять гибридными системами с клиентами, работающими на персональных компьютерах. Падкая на слэнг англоязычная литература придумала на этот счёт новый термин – “braun field”, что на русский язык вольно можно было бы перевести как “пустырное” программирование по аналогии с постройкой дома на пустующем пока участке между уже построчными зданиями.

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

И вот, примерно в первой-второй декаде этого века ИТ-шные “пустыри” были “застроены”. Т.е. большинство видов массовой профессиональной интеллектуальной человеческой деятельности в развитых и не очень странах мира так или иначе было автоматизировано. Сегодня основная масса программистов в мире, по моему мнению, занимаются миграцией существующих ИТ-систем на новые платформы и языки программирования. Яркий англоязычный термин, описывающий эту ситуацию, мне неизвестен, но развивая аналогию целины и пустыря я сравнил бы это со строительством в густонаселённом мегаполисе – “бетонных джунглях” (concrete jungle).

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

Почему архитектура снова становится важной

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

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

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

Материализация Идей при миграции систем

Определённые рекомендации на эту тему изложены в моей статье https://habr.com/ru/post/553794/ и ссылках к ней. Более подробно о подходящих ментальных моделях я планирую написать в ближайшее время. В этой статье я хотел бы кратко описать процесс применения парадигмы Программирования как Материализации Идей (см. https://habr.com/ru/post/425321/ ) при миграции систем на новые платформы и языки программирования.

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

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

Таким образом процесс миграции развивается на следующие шаги:

  1. Экстрагирование (импорт) Ментальных Моделей и трансформирование их промежуточные архитектурные модели.
  2. Проверка и возможно, обогащение промежуточной модели.
  3. Трансформирование первоначальной (обогащенной) архитектурной модели в целевую архитектурную модель.
  4. Принятие решений о покупке или лизинге определённых частей новой системы. Решение и планирование собственной разработки.
  5. Загрузка (экспорт) необходимых релевантных архитектурных моделей в сознание разработчиков с целью формирования необходимых Ментальных Моделей.
  6. Разработка, интеграция и запуск новой системы.

Заключение

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

Если тема Материализации Идей в Программировании вам интересна, присоединяйтесь к нашей группе в Телеграм:    Материализация Идей.