Совместная работа нескольких авторов (или группы разработчиков) еще больше осложняет задачу – за счет «интерференции» понимания происходящего в проекте (то есть все тех же знаковых систем, на которые разные участники могут смотреть немного по-разному).
Никакие спецификации и комментарии, к сожалению, не могут ни поспеть за кодом, ни исчерпывающе описать все нюансы – разве что в идеальном мире.
Совмещение «самодельных» знаковых систем с проблемой "объективно древних" библиотек, окружений, языков завершает картину того, чем же является "археология исходников". Суммируя вышесказанное, можно сформулировать: практически любые исходники начинают устаревать в тот самый момент, когда их перестают изменять. Устаревать не в смысле соответствия задаче (хотя и это тоже), а в смысле понятности тому, кто вздумает в них разобраться.
Читатель, знакомый с различными методологиями разработки, может заметить, что «недревнеющий» код, код постоянно обновляемый и частично переписываемый, напоминает о гибких agile-методологиях, с их непрерывной интеграцией и постоянным рефакторингом. Кроме того, мы знаем, что "код, не покрытый тестами, не существует".
Противопоставить этому можно многоступенчатые крайне формализованные процессы типа RUP (Rational Unified Process), где все аспекты работы проекта единожды специфицированы, документированы и изменения в «стерильный» код вносятся крайне неохотно. В нашей «археологической» метафоре такие методологии разработки, кажется, самой природой предназначены сразу производить «окаменелости» – монолитно, надежно, монументально, сто лет простоит. Но вот любое исследование или внесение изменений…
В идеальном мире программистам не приходилось бы возиться с "историческими артефактами" (по крайней мере, не приходилось бы слишком часто). Мы бы работали лишь с небольшими объемами "кода текущей задачи", который легко перерабатывать и столь же легко удерживать в голове целиком; а библиотеки и программы использовали бы лишь единожды скомпилировав, в бинарном виде. Реальность, к сожалению, куда печальнее и круче.
Ситуации, в которых программист тратит бо, льшую часть своего времени на анализ чужого, давно и не здесь написанного кода, встречаются сплошь и рядом. Причин может быть масса; помимо тривиальной – доставшаяся "по наследству" система или модуль, может возникнуть необходимость разобраться в работе (или исправить баги) исходников используемой (открытой или купленной) библиотеки, поскольку лучшим «справочником» по сложному формату или протоколу зачастую является библиотека, этот формат-протокол реализующая, и т. п.
Кстати говоря, чтение чужого хорошо написанного кода является неплохим подспорьем для самообучения (в том числе – обучения собственно искусству чтения).
Продолжим. Для анализа чужого кода, особенно кода крупного проекта, "с высоты птичьего полета" (построение ментальной модели, выяснение основных знаковых систем) исходники принято сводить к набору "основных сущностей" [Мы здесь не останавливаемся на том, что "объективные знаковые системы" – использованные языки программирования, API и библиотеки – все же придется изучить. Впрочем, для некоторых частных случаев, наиболее востребованных, существуют автоматизированные средства перевода с одного языка на другой (например, Cobol->Java)]. Для популярных языков программирования, в «обиходе» которых существует множество инструментов анализа и проектирования, это может выглядеть как автоматизированное построение диаграмм классов (иерархий наследования и включения и т. п.) или функций и процедур (иерархий вызовов). Здесь еще может помочь спецификация или другая документация на проект (на более низких уровнях, как правило, любая документация малорелевантна коду).
Как только мы спускаемся уровнем ниже "общего плана" – до отдельных строк кода, параметров функций и времени жизни переменных [Знаменитый теоретик computer sciense Гради Буч называет это "археологией при помощи зубной щетки"], – никакого другого метода понять и разобраться, кроме чтения строки за строкой, не остается.