Лекс Айрин писал(а):Ну-ну... вот только с ростом плюшек в программах они растут, изменяются и накапливают ошибки ((( Иногда и в структуре кода.
Вы говорите правильно. Но есть условно говоря два способа решения указанной Вами проблемы:
а) применить средства визуализации, подобные тому, которые Вы бы хотели увидеть
б) применить рефакторинг и восстановить понятность и очевидность кода.
Меня мои учителя по программированию (очень грамотные были спецы) сразу так научили делать. Не нужно делать описание программы, ее структуры и связей. Не нужно запоминать эту структуру. Не нужно ее визуализировать. Нужно иметь некоторый набор правил и принципов, исходя из которого структура программы является однозначной. Поэтому когда мне говорят, что в программе написанной 10 лет назад, возникла ошибка при таком-то действии в таком-то окне. Я в ответ еще не глядя в год и ничего не вспоминая сразу для себя помечаю название модуля, название класса или функции, а иногда и переменной. Далее подымаю старый код, открываю нужный модуль, класс, функцию и ее просто смотрю. В 90% случаев без всякого отладчика ошибка находится путем перепроверки текста этого участка кода программы. Иногда можно запустить отладчик.
Да, я обычно все же пишу описание. Но не описание кода, а описание задачи. Причем описание задачи на русском литературном языке пишу так (структурируя его), чтобы мне было однозначно понятно, какая будет структура кода для решения этой задачи. Иногда в тексте делаю небольшие иллюстрации, но касающиеся самой постановки задачи. Например, график технологического процесса, или математическую формулу.
Кстати, применяя такой способ программирования у меня получается поддерживать код написанный не мною, а коллегами, использующими тот же способ программирования. А способ заключается в том, чтобы одинаковая подзадача всегда решалась одинаково. Есть мелкая подзадача, она имеет 10 способов решения, и Вы применяете всегда один и тот же способ ее решения. Это как бы унификация мелких узлов и деталей. Есть унификация за счет применения библиотек, а есть еще в дополнение унификация за счет однотипности написания кода. Например, если в диалоговом окне идет проверка взаимной корректности нескольких полей ввода, то процедура проверки будет всегда называться одинаково. Если эта проверка выполняется, то ее вызов всегда делается в конкретном месте. И т.д. Если в постановке задачи есть описание на русском языке неких прикладных объектов, то имея 100 способов организовать структуру классов, я буду всегда применять только один способ. Поэтому прочитав описание задача на полстраницы я уже знаю, какая в этой программе структура классов, и мне не нужна диаграмма классов. Зная какой способ формирования структуры классов я применил, я знаю, какие здесь могут быть ссылки, поэтому мне их тоже не нужно визуализировать.
Этот принцип, как в автосервисе. Мастер может быть в первый раз видит данную модель авто, но он изначально знает, как открутить колеса, как и где заменить масло. Ему не нужно изучать чертежи авто (которых и нет), он знает, что во всех авто определенные узлы делают однотипно, хотя изначальная разработка этого узла требовала глубочайших научных исследований.
