> -- Геннадий Тышов писал(а):
> Странное название темы "Почему программа должна быть структурной" - без знака вопроса.Очевидно, это не вопрос, а вариант ответа.
> -- Геннадий Тышов писал(а):
> Данная тема имеет религиозный характер - обсуждение ни к чему не приводит.В таком случае лучше сюда не соваться.
> -- Геннадий Тышов писал(а):
> Ответ на вопрос тема есть у каждого свой.Мне бывает интересно чужое мнение.
> -- Геннадий Тышов писал(а):
> Перед программистом этот вопрос не возникает, т.к. у него есть знания и наработаная личная и в коллективе практика.Наработанная практика имеет право на эволюцию, она не высечена в камне (впрочем, у кого как). Чтобы найти более хорошую практику, бывает полезно услышать чужое мнение, посмотреть на чужой опыт, тем более если этот опыт обращается к общезначимым основам.
> -- Геннадий Тышов писал(а):
> Он должен:Далее пункты списка объединены союзом "И" или "ИЛИ"?
> -- Геннадий Тышов писал(а):
> 1. добиться реальных сроков выполнения, 2. добиться формулировки конкретного задания, 3. выполнить декомпозицию задачи, 4. решить вопросы интеграции с существующим комплексом проблемного прикладного программного обеспечения и с существующими данными, 5. должен составить алгоритм, 6. выполнить программирование, 7. выполнить отладку и тестирование, 8. предъявить и повторить этот (2-8) цикл с учетом замечаний, 9. установить созданное у пользователей, 10. решить вопросы прав доступа пользователей, 11. выпустить документацию, 12. обучить пользователей, 13. инициализировать наборы данных, 14. обеспечить восстановление при возможных сбоях, 15. демонтировать выведенное при этом из использования программное обеспечение,16. осуществить авторский надзор.Первые 8 пунктов относятся к любой сознательно планируемой деятельности, и не отражают специфику программирования вообще никак. Из вторых 8 пунктов мне за всю программистскую карьеру приходилось заниматься только пунктом 14 - обеспечением отказоустойчивости системы - но и он являлся частью техзадания, так что не должен бы стоять особняком. Пункт 9 кажется относящимся к программированию, но на самом деле не отличается от пункта 4 и заключается в создании дистрибутива (инсталляционного пакета, т.е. программы или алгоритма для установки ПО). Собственно,установку ПОпользователь производит сам либо нанимает для этогосистемного администратора(который вовсе не обязательно является программистом, хотя может и совмещать). Тот же системный администратор должен заниматься и пунктом 10. Пункты 11 и 12 тоже имеют крайне мало отношения к программированию. Более того, требуют совершенно иного рода знаний и умений. Демонтаж выведенного из строя ПО - спасибо, посмеялся. Важно не выбрасывать отработанное ПО куда попало и не загромождать им проходы в коридорах, а обеспечить максимальноеповторное использованиеи утилизацию.

У некоторых программистов так бывает, что когда его нет на месте, ПО глючит и всячески отказывается работать, а когда он стоит рядом и наблюдает, то всё работает как часы.  : ) Пункт 16 - это требование обеспечить "эффект присутствия"? Или это надзор за ненарушением авторских прав? Если всё же имеется в виду банальная техподдержка, то мне не понятно, чем это отличается от пунктов 7 и 8 (отладка по выявленным замечаниям).
> -- Геннадий Тышов писал(а):
> Как видите,  - это не проблема, о которой болит голова.Нет, не вижу. Именно о структурности программы у меня как программиста голова болит в первую очередь. Именно структура стоит во главе угла.

У иных программистов так бывает, что пока одно сделает, другое сломает, пока то чинит, третье перестанет работать. И так пока не найдёт какой-то хрупкий баланс, назвать который надёжной программой язык не поворачивается, даже страшно его попросить что-то доработать. А почему так происходит? Потому что сложность его программы превышает его собственные возможности восприятия и обработки. Почему? Потому, что нет структуры.
> -- Геннадий Тышов писал(а):
> Как у преподавателей, я не знаю.Я тоже.
> -- Геннадий Тышов писал(а):
> Уверяю Вас, когда ПО сдано, Вас поблагодарят и никто не спросит как это сделано. Вам доверяют.Я 5 лет вёл проект, который до меня пару лет вёл другой человек. До сих пор хвалят и обращаются за добавлением новых возможностей. Да, у меня не спрашивают, как я там чего сделал. Да, мне доверяют. Но это доверие мною было заработано путём резкого повышения стабильности работы программы и полным отсутствием "исправлений результатов исправлений". Отсутствие побочных эффектов есть прямое следствие тщательного структурирования программы сверху донизу.

Или думаете, мне также доверяли бы доработку, если бы после добавления чего-то нового каждый раз переставало работать что-то старое? Нет, очевидно, вы этого утверждать не станете.

Если вам поручают нечто простое и одноразовое - сделал и забыл - то из одной точки можно экстраполировать любые графики: хоть про доверие, хоть про божественное озарение. А вот если работаешь долго над одной и той же программой, и становится она всё сложнее и сложнее год от года, то без продуманной структуры (от макро- домикроуровня, о котором данная тема) долго не протянешь.

Это как спортивная техника. Что есть признак мастерства? Постоянство. Если техника не поставлена, то постоянство становится всё призрачнее с каждой новой попыткой. Один раз можно вдарить и попасть по боксёру. Один раз можно увернуться от его удара. Но результат 12 раундов определяется прежде всего разницей в технике.