Пояснения
Хорошо составленная, снабженная пояснениями распечатка с более или менее подробно составленной блок-схемой помогает проследить ход выполнения программы, но имена переменных и их использование могут оставаться невыясненными. Выдача полной таблицы переменных для каждого модуля, тоже может быть хорошим вспомогательным средством. В такой таблице должно указываться, присваивается ли переменной значение в результате операции ввода или при помощи оператора присваивания, используется ли существующее значение в некотором выражении или в операции вывода.
Конечно, в некоторых случаях корректность использования переменных удается определить лишь при рассмотрении каждого модуля в отдельности. Глобальные переменные, которые могут использоваться или изменяться за пределами модуля (например, переменные, фигурирующие в COMMON-блоке Фортрана), являются потенциальными источниками неприятностей. Точно так же логично предположить, что переменные, применяемые для передачи информации между модулями, будут использоваться и могут изменяться внутри этих модулей.
В особенно запутанных ситуациях могут применяться также и другие методы, как правило, связанные с отладкой программ. Сюда относятся снимки и различные виды трассировки программ. Однако трудоемкость интерпретации результатов приводит к тому, что эти методы обычно относят к категории крайних мер и используют лишь как последнее средство, когда никакие другие не помогают.
Таким образом, многие из указанных средств, способствующих пониманию программы, непосредственно направлены на подготовку письменной информации о программе, которая могла бы дополнить существующую документацию или восполнить ее отсутствие. Вся эта новая информация вместе с новым описанием программы и любыми другими заметками, способствующими пониманию, должна быть сопоставлена с файлом документации и добавлена к нему для обеспечения Помощи тем, кому в дальнейшем придется разбираться в этой программе.
Из сказанного ясно, что для того, чтобы разобраться в программе, разработанной другими, могут потребоваться значительные усилия. Если программа сложна и недостаточно полно документирована, то для того, чтобы прочитать ее и разобраться в ней в достаточной степени для сопровождения и модификации, могут потребоваться более значительные усилия, чем для написания новой программы согласно той же спецификации. В такой ситуации, возможно, будет разумнее отказаться от использования исходной программы. Это может плохо отразиться на карьере разработчиков программы и поэтому будет предостерегающим примером для тех, кто станет писать новую программу. Однако решение о том, чтобы отказаться от программы и написать новую, может находиться вне Вашей компетенции.
Сопровождение программы. Существуют две основные причины, определяющие необходимость сопровождения программ. Первая вызвана нашим неумением писать большие программы, свободные от всякого рода ошибок, т. е. необходимостью находить и исправлять оставшиеся в программе ошибки. Процесс выявления ошибок во многих случаях продолжается на протяжении всей жизни программы. Большинство ошибок выявляется и исправляется во время отладки и тестирования, прежде чем программа считается законченной.
Еще некоторое число ошибок будет обнаружено в начальный период эксплуатации программы, когда в нее вводятся реальные данные, которые могут быть не такими простыми, как тестовые. Обычно можно обратиться к разработчику программы или в группу разработчиков, которые примут участие в выяснении причин ошибок. Проблемы появляются позже, когда программа уже внедрена. Трудности усугубляются тем, что причину ошибки, которая долго не проявлялась, по всей вероятности, определив будет сложнее.