Анатолий Рудой,
старший преподаватель компьютерного колледжа
Археология исходников
Автор: Виктор Шепелев
Из всех областей «цифровой археологии» – дисциплины использования устаревшего, но все еще ценного контента – труднее всего очертить границы копания в исходном коде «старых» программ и библиотек. Главная тому причина – применительно к исходникам сами понятия «старости» и «устаревания» обрастают новыми, невиданными в других областях смыслами.
Что такое вообще "археология исходников" и зачем она нужна? Примем в качестве первого приближения, что это анализ исходного кода некоторой устаревшей системы (а может быть, программы или библиотеки) с целью понять ее логику – и впоследствии эту логику изменить, воспроизвести в другой системе или встроить данную систему в новую и т. п. «Археологией» приходится заниматься и в тех случаях, когда знаковая система анализируемых исходников нам незнакома – то есть, «двигаясь» по тексту, написанному на "незнакомом языке", необходимо этот «язык» изучить.
Я не случайно взял «язык» в кавычки. Дело в том, что обычное представление о «древнем» коде, как о коде на языке программирования вроде Fortran или Cobol, – крайне упрощенное. Как раз по Фортрану вполне можно найти учебник или справочник. Здесь нет необходимости восстанавливать его правила только по исходному тексту программы. Проблема в том, что любой достаточно объемный кусок кода, помимо «основного» языка программирования, содержит и использует множество «подъязыков» и знаковых систем. Это служебные процедуры и классы, это используемые библиотеки и API операционной системы, это различные паттерны и встроенные алгоритмы. Единственная строчка кода может породить множество вопросов и потребовать многих дней сосредоточенного анализа для выяснения смысла и логики.
Таким образом, понятие «древности» кода (что есть, по сути, характеристика его непрозрачности для чтения и изменения в силу «забытости» правил и логики его написания) определяется не только и не столько языком программирования. Код может использовать устаревшие (а некогда общедоступные) библиотеки, даже документацию по которым сегодня найти весьма затруднительно. Код может быть написан для устаревшей ОС и широко использовать ее сервисы (например, для чтения/записи файлов, работы с сетевыми или графическими примитивами); или для устаревшего «железа» под специфику его процессора, памяти и портов. И, наконец, код может быть "устаревшим условно" – например, в нашей организации решили отказаться от библиотеки Х, так как не осталось людей, в ней разбирающихся, а кое-какой код, ее использующий, все еще актуален и активно применяется. При этом Х может быть вполне современной библиотекой, но в контексте нашей конторы исходники, ее использующие, – "древние".
Впрочем, помимо всех «объективных» компонентов знаковой системы кода, есть и «субъективные» – та часть процедур, библиотек и идиом, которая создана непосредственно автором (авторами) программы. И здесь-то может быть зарыта самая крупная собака "археологии исходников". Программист, работающий над нетривиальной задачей (к тому же работающий, как правило, итеративно – написание-отладка-исправление; и добро еще, если исправления сделаны не "абы запустить"), так вот этот программист, помимо использования существующих знаковых систем, создает множество своих. Они могут быть довольно стройны и логичны – а могут и не быть; объем и связность частей проекта превращает "полное погружение" в него в задачу не для слабых духом [Более того, все это справедливо даже для случая, когда автор кода – ты сам, но с момента написания/отладки прошло значительное время. Искусственность и многочисленность "самодельных знаковых систем" приводит к перегрузкам памяти – логика кода, в который не "закапывался с головой" на этой неделе, быстро забывается. Отсюда – даже если автор некоторого кода "как бы под рукой" – это не значит, что код не потребует "археологических изысканий"].