Тяжкий груз легаси

[d0ctor_z]

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

Comments

[rdia]

Я просто намекал на известную книжку Working Effectively with Legacy Code, где рассказывается, как обновлять большие legacy системы, написанные на ООП/однофазных императивных языках (без препроцессора). Это хорошо проработанные протоколы, когда кусок изолируется, пишутся тесты, потом переписывается. В общем, все более-менее интуитивно знают.

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

неизменяемые, инициализируемые (однократное изменение), локально многократно изменяемые и т.д.

См выпуск 1, статья "Изменяемое состояние: опасности и борьба с ними" https://fprog.ru/2009/issue1/eugene-kirpichov-fighting-mutable-state/

Так вот ту же классификацию можно применить и к коду:

1. Неизменяемый - интерпретируемый/компилируемый без макросов.

2. Однократно изменяемый - макросы.

3. Многократно изменяемый локально.

4. Многократно изменяемый глобально.

Так вот мы умеем как-то уверенно писать только до уровня 2, а работать с legacy у нас протоколы только на уровень 1.

Живые же существа - это уровни 3-4. То есть, мы не то, что исправлять такое не можем, мы даже создавать такое не можем. А вы, как профессионал, должны знать, что починка сложнее создания.

[d0ctor_z]

Изменяемость, ох... Вспоминаю свое знакомство с древним кодом одного проекта на C#, откуда мне нужно было вытащить какие-то алгоритмы (обсчета массива данных, точнее не вспомню). Вот класс, который писали математики. Все логично, метод принимает параметры расчета и выдает массив. А вот другой класс. Гигантский исходник, тысячи строк кода и метод без параметров, ничего не возвращающий: void calculate(), что-то типа такого. И параметры он читает из полей класса, и результат куда-то туда пишет...

[rdia]

> А вот другой класс. Гигантский исходник, тысячи строк кода и метод без параметров, ничего не возвращающий: void calculate(), что-то типа такого.

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

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

[d0ctor_z]

Кромсать такое можно, да - нормальные функции получения массивов я написал (старый код не трогал, конечно). Самомодификация очень сложна. Даже сериализация и рефлексия в C# (которые до собственно самомодификации кода не доходят) способны попить немало крови, особенно когда ими, скажем так, несколько злоупотребляют.

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