Компьютерра - Журнал «Компьютерра» № 34 от 18 сентября 2007 года

Кстати, когда я говорил о методической многоплановости всей этой «археологической» деятельности, то имел в виду, что возрастные границы участников такой работы тоже очень широки. Младшие школьники, например, с удовольствием занимаются имитационным моделированием – по старым фотографиям и книжным описаниям воссоздают на экранах мониторов анимированные «модели» ЭВМ с «работающими» устройствами ввода-вывода, панелями индикации, инженерными пультами и т. п. Однажды группа школьников столкнулась с неожиданной трудностью – машина МИР-1 [В машинах серии МИР разработки Киевского института кибернетики впервые в мире встроенными микропрограммными средствами были реализованы возможности решения уравнений в аналитической (символьной) форме] в качестве устройства ввода-вывода и операторской консоли была укомплектована ГДРовской электрической пишущей машинкой «Зоемтрон», звук работы которой ребята хотели вставить в программу визуализации модели этой во многом замечательной ЭВМ. Ничего не вышло! Ни одного «живого» «Зоемтрона» мы так и не нашли, а те два экземпляра, которые все-таки отыскались в… инструментальной кладовой одного завода, были безнадежно поломаны и лишены плат управляющей электроники. Понятно, что и шум оригинальных воздуходувок, который так хорошо помнят пользователи давешних малых ВЦ, мы записать "в цифре" так и не смогли.

Анатолий Рудой,

старший преподаватель компьютерного колледжа

Автор: Виктор Шепелев

Из всех областей «цифровой археологии» – дисциплины использования устаревшего, но все еще ценного контента – труднее всего очертить границы копания в исходном коде «старых» программ и библиотек. Главная тому причина – применительно к исходникам сами понятия «старости» и «устаревания» обрастают новыми, невиданными в других областях смыслами.

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

Я не случайно взял «язык» в кавычки. Дело в том, что обычное представление о «древнем» коде, как о коде на языке программирования вроде Fortran или Cobol, – крайне упрощенное. Как раз по Фортрану вполне можно найти учебник или справочник. Здесь нет необходимости восстанавливать его правила только по исходному тексту программы. Проблема в том, что любой достаточно объемный кусок кода, помимо «основного» языка программирования, содержит и использует множество «подъязыков» и знаковых систем. Это служебные процедуры и классы, это используемые библиотеки и API операционной системы, это различные паттерны и встроенные алгоритмы. Единственная строчка кода может породить множество вопросов и потребовать многих дней сосредоточенного анализа для выяснения смысла и логики.

Таким образом, понятие «древности» кода (что есть, по сути, характеристика его непрозрачности для чтения и изменения в силу «забытости» правил и логики его написания) определяется не только и не столько языком программирования. Код может использовать устаревшие (а некогда общедоступные) библиотеки, даже документацию по которым сегодня найти весьма затруднительно. Код может быть написан для устаревшей ОС и широко использовать ее сервисы (например, для чтения/записи файлов, работы с сетевыми или графическими примитивами); или для устаревшего «железа» под специфику его процессора, памяти и портов. И, наконец, код может быть "устаревшим условно" – например, в нашей организации решили отказаться от библиотеки Х, так как не осталось людей, в ней разбирающихся, а кое-какой код, ее использующий, все еще актуален и активно применяется. При этом Х может быть вполне современной библиотекой, но в контексте нашей конторы исходники, ее использующие, – "древние".

Впрочем, помимо всех «объективных» компонентов знаковой системы кода, есть и «субъективные» – та часть процедур, библиотек и идиом, которая создана непосредственно автором (авторами) программы. И здесь-то может быть зарыта самая крупная собака "археологии исходников". Программист, работающий над нетривиальной задачей (к тому же работающий, как правило, итеративно – написание-отладка-исправление; и добро еще, если исправления сделаны не "абы запустить"), так вот этот программист, помимо использования существующих знаковых систем, создает множество своих. Они могут быть довольно стройны и логичны – а могут и не быть; объем и связность частей проекта превращает "полное погружение" в него в задачу не для слабых духом [Более того, все это справедливо даже для случая, когда автор кода – ты сам, но с момента написания/отладки прошло значительное время. Искусственность и многочисленность "самодельных знаковых систем" приводит к перегрузкам памяти – логика кода, в который не "закапывался с головой" на этой неделе, быстро забывается. Отсюда – даже если автор некоторого кода "как бы под рукой" – это не значит, что код не потребует "археологических изысканий"].