OberonCore
https://forum.oberoncore.ru/

Почему программа должна быть структурной
https://forum.oberoncore.ru/viewtopic.php?f=82&t=2348
Страница 1 из 8

Автор:  Илья Ермаков [ Суббота, 13 Февраль, 2010 18:28 ]
Заголовок сообщения:  Почему программа должна быть структурной

Выделено: viewtopic.php?p=42549#p42549

Вы использовали следующую композицию:

if cond1 then A;
if cond2 then B;
if cond3 then C;
...
Анализ поведения данной конструкции требует знания внутреннего устройства A, B и С.
Из свойств конструкции охраны я делаю вывод, что будет выполнено 0 или более блоков A..C, для которых истинна охрана.
А Вы мне во внутреннем устройстве этих A, B, C такую свинью подкладываете. Нарушаете свойства объемлющей конструкции.

Программа - это не литературный текст, извините. Оправдания вида "ну, вы читайте подряд - всё понятно ведь" не принимаются. Основная операция над программой - её развитие. Поэтому следует использовать строгий набор преобразований, который строгим образом меняет свойства (выход от постановки задачи на реализацию путём чётких шагов-схем).

Автор:  Илья Ермаков [ Суббота, 13 Февраль, 2010 20:59 ]
Заголовок сообщения:  Re: Песни партизан: "Ява после Оберона"

Да, вот внезапно чётко понял, с примером, что меня раздражает в досрочном выходе. Концептуально.

Вот есть процедуры:

Код:
PROCEDURE P1 (...);
BEGIN
  BlockA
END P1;

PROCEDURE P2 (...);
BEGIN
  BlockB
END P2;

...


Я хочу выполнить вполне безобидное преобразование - добавить в P1 и P2 в конец по операции. (Например, логирование. Да что угодно. Какое-то освобождение. Не суть.)

Скажите мне, я имею право это сделать? Если BlockA и BlockB - это нормальные блоки, то я имею право применить последовательную композицию и получить таким преобразованием новые процедуры, какие мне надо (с семантикой "сначала происходит BlockA, потом NewBlock")? Имею право? Да. Это право мне гарантировано свойствами структурных конструкций. Любой блок программы должен допускать последовательную композицию с другими блоками. И не только последовательную, но и вкладывание в объемлющие конструкции. И я не обязан изучать внутреннее устройство этого блока, если нет связей по потокам данных.

Т.е. блоки, в которых использована инструкция выхода из процедуры, являются дефектными, неполноценными, потому что не поддерживают вполне законную композицию в объемлющем блоке.

Если говорить юридически, то оказывается, что требование не использовать досрочные выходы - это не "глупая буква закона", а как раз вполне в терминах "гражданских прав", так сказать. Свобода программиста ставить EXIT-ы ограничивается в силу того, что эта свобода ограничила бы свободу других (осуществлять ЗАКОННУЮ композицию этого блока).
Технически же говоря (ну да, придираясь, но тем не менее...), это ухудшает свойства объемлющей системы в плане возможностей развития.

Мелочь? Само по себе (в отличие от циклов) - может быть, и да. Но если мы вообще принимаем инженерную культуру, как внимание к свойствам своих систем, то непонятно, почему в данном случае нам тоже ей не следовать. Внимание к мелочам - одно из качеств профессионала. Следующее из опыта, что мелочей в серьёзном деле нет...

Автор:  Александр Шостак [ Суббота, 13 Февраль, 2010 21:00 ]
Заголовок сообщения:  Re: Песни партизан: "Ява после Оберона"

Попробовал переписать код метода (Delphi), следуя парадигме: "Нет break-ам, нет return-ам из середины" и разбив код на подфункции, оставив основную часть в виде простого цикла while.
Было: http://files.heroes35.net/html/ExprManager_OLD.html
Стало: http://files.heroes35.net/html/ExprManager_NEW.html

Смысл метода: выполнение операторов подвыражения с последующим удалением аргументов из списка и заменой оператора возвращённым значением. Пример подвыражения: a + b * 3 - 777/2. Подвыражение поступает в виде объекта-списка с распарсенными элементами. Для вышеуказанного примера:

0: TExprIdent a
1: TExprOper +
2: TExprIdent b
3: TExprOper *
4: TExprValue 3
5: TExprOper -
6: TExprValue 777
7: TExprOper /
8: TExprValue 2

После выполнения должно остаться одно значение в списке.

Определённая избыточность появляется в коде в рамках 15-20%. Но возрастает стабильность, повышается структурированность. Легче изменять отдельные части, не трогая другие. Переменные разнесены по локальным подфункциям. Код выполняется последовательно.

С уважением.

Автор:  Илья Ермаков [ Суббота, 13 Февраль, 2010 21:04 ]
Заголовок сообщения:  Re: Песни партизан: "Ява после Оберона"

Кстати, касательно повторного использования блоков. На самом деле, не такая это утрированная ситуация. Хорошо написанный блок программы, содержащий некий паттерн, действительно может быть использован иногда в режиме "copy-paste". А если говорить о некотором генерационном случае, формальном из более высокоуровневой модели, то вообще интересный поворот получается.

Автор:  Димыч [ Суббота, 13 Февраль, 2010 21:13 ]
Заголовок сообщения:  Re: Песни партизан: "Ява после Оберона"

Илья Ермаков писал(а):
Да, вот внезапно чётко понял, с примером, что меня раздражает в досрочном выходе. Концептуально.

Супер!

Илья, вы правы совершенно. Пока ты не можешь утверждать, что процедура - это "кирпич", то вся кухня по передаче управления неявно размазывается выходами из середины.

Пошел перечитывать Дейкстру

Автор:  Александр Ильин [ Суббота, 13 Февраль, 2010 21:32 ]
Заголовок сообщения:  Re: Песни партизан: "Ява после Оберона"

ain писал(а):
Только откуда вы увидели ненадежность в моем примере?
Мне кажется, тут речь идёт о потенциальной проблеме забытого Exit. Аналогичной проблемой страдает Сишный switch: забыли break - "провалитесь" в следующий блок.

Илья Ермаков писал(а):
Да, вот внезапно чётко понял, с примером, что меня раздражает в досрочном выходе. Концептуально.
Илья, респект! Жму руку. : ) Сам тоже обожаю такие прозрения, когда они у меня бывают.

Автор:  ==== [ Воскресенье, 14 Февраль, 2010 14:48 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Странное название темы "Почему программа должна быть структурной" - без знака вопроса.

Модератор выделил тему и ему вопрос - "Кому, в связи с чем, для чего надо дать ответ?".

Данная тема имеет религиозный характер - обсуждение ни к чему не приводит.
В лучшем случае сделают предположение, что не читал Дейкстру, Грисса или еще какие-нибудь первоисточники основоположников.

Ответ на вопрос тема есть у каждого свой.

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

Как видите, "Почему программа должна быть структурной" - это не проблема, о которой болит голова.

Как у преподавателей, я не знаю.

Автор:  Info21 [ Воскресенье, 14 Февраль, 2010 15:01 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Геннадий Тышов писал(а):
Данная тема имеет религиозный характер - обсуждение ни к чему не приводит.
В лучшем случае сделают предположение, что не читал Дейкстру, Грисса или еще какие-нибудь первоисточники основоположников.
Разве ИЕЕ у Дейкстры аргумент слямзил?

Характер темы не более религиозный, чем у темы преимущества, скажем, позиционной системы счисления перед римской.

Легкость (пере)композиции программы -- разве не облегчает цикл 2-8?

Автор:  ==== [ Воскресенье, 14 Февраль, 2010 15:26 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Info21 писал(а):
Легкость (пере)композиции программы -- разве не облегчает цикл 2-8?

Да, облегчает. Для этого и был предложен стиль "Скульптор".
У меня и Вас может быть различное понимание композиции программы, ведь мы работаем в различных условиях и прошли различный путь к программированию.

Хочу еще добавить:
2а. Изучить законодательные нормативные документы.
2б. Создать соответствующие структуры наборов данных.
изменить:
4. решить вопросы интеграции с существующим комплексом проблемного прикладного программного обеспечения и с существующими данными, с учетом структуры предприятия по подразделениям.

Info21 писал(а):
Характер темы не более религиозный, чем у темы преимущества, скажем, позиционной системы счисления перед римской.
Утверждение о религиозности этой тема не предусматривало сравнение степени религиозности других тем.

Автор:  Илья Ермаков [ Воскресенье, 14 Февраль, 2010 16:23 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Геннадий Тышов писал(а):
Как видите, "Почему программа должна быть структурной" - это не проблема, о которой болит голова.


Когда в типа "промышленном" софте (в частности, в open-source) сталкиваешься с такими кошмарными кусками кода, какой был разобран (и перепроектирован) в соседней ветке - viewtopic.php?p=42414#p42414, то голова ещё как болит.

Автор:  Илья Ермаков [ Воскресенье, 14 Февраль, 2010 16:33 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Ещё, как ответ, начата вот эта тема:
viewtopic.php?f=67&t=2351

Автор:  ==== [ Воскресенье, 14 Февраль, 2010 16:52 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Я вернулся.

Илья Ермаков писал(а):
Программист должен создать систему.

Программист должен создать ПО, иначе ему скажу "Зачем ты нужен?". Если он готов работать, то будьте уверены у него нет проблемы с Вашим вопросом "Почему программа должна быть структурной".

Автор:  ==== [ Воскресенье, 14 Февраль, 2010 16:56 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Уверяю Вас, когда ПО сдано, Вас поблагодарят и никто не спросит как это сделано. Вам доверяют.

Автор:  Илья Ермаков [ Воскресенье, 14 Февраль, 2010 17:16 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Потрясающий ответ!

Прекрасно всё иллюструет, ну прямо, как есть.

Ладно. На пользователя... забудем. Он нам доверяет, бедный. Верит, что лучше нельзя.
Ну а ну как программке расти придётся? Или когда уволимся, пусть работодатель сам думает, что делать?

Я тут у одного знакомца спросил, с какого перепуга он решил финансовую систему на Перле писать; ибо язык для крупных систем совершенно невменяемый. Так он ответил: "А мне и не нужно, чтобы был вменяемый. Тогда кто-то, кроме меня, сможет разобраться в этом. И меня могут уволить."

Автор:  Info21 [ Воскресенье, 14 Февраль, 2010 17:18 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Геннадий Тышов писал(а):
Info21 писал(а):
Характер темы не более религиозный, чем у темы преимущества, скажем, позиционной системы счисления перед римской.
Утверждение о религиозности этой тема не предусматривало сравнение степени религиозности других тем.
Сравнение религиозности двух тем -- мягкий способ сделать утверждение об абсурдности первого из сделанных здесь утверждений, использовавших слово "религигозность".

Автор:  Info21 [ Воскресенье, 14 Февраль, 2010 17:24 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Илья Ермаков писал(а):
Потрясающий ответ!
Да уж... давайте по этой же логике вообще всякое профессиональное обучение отменим.

Илья Ермаков писал(а):
Я тут у одного знакомца спросил, с какого перепуга он решил финансовую систему на Перле писать; ибо язык для крупных систем совершенно невменяемый. Так он ответил: "А мне и не нужно, чтобы был вменяемый. Тогда кто-то, кроме меня, сможет разобраться в этом. И меня могут уволить."
Это правда? Вот так совершенно сознательно?

По опыту общения со спецами по С++ из физиков ощущение, что они все-таки верят в то, что С++ это круто etc. Не значит, конечно, что не может быть вытеснения, так сказать, в подсознание. Но все-таки не вот так откровенно.

Автор:  Peter Almazov [ Воскресенье, 14 Февраль, 2010 17:54 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Геннадий Тышов писал(а):
В лучшем случае сделают предположение, что не читал Дейкстру, Грисса или еще какие-нибудь первоисточники основоположников.
Похоже, Геннадий Тышов уверен, что изучение указанных источников не просто бесполезно, но еще и наносит ощутимый вред пунктам 1..16.
Случай тяжелый.

Автор:  Александр Ильин [ Воскресенье, 14 Февраль, 2010 18:23 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Геннадий Тышов писал(а):
Странное название темы "Почему программа должна быть структурной" - без знака вопроса.
Очевидно, это не вопрос, а вариант ответа.
Геннадий Тышов писал(а):
Данная тема имеет религиозный характер - обсуждение ни к чему не приводит.
В таком случае лучше сюда не соваться.
Геннадий Тышов писал(а):
Ответ на вопрос тема есть у каждого свой.
Мне бывает интересно чужое мнение.
Геннадий Тышов писал(а):
Перед программистом этот вопрос не возникает, т.к. у него есть знания и наработаная личная и в коллективе практика.
Наработанная практика имеет право на эволюцию, она не высечена в камне (впрочем, у кого как). Чтобы найти более хорошую практику, бывает полезно услышать чужое мнение, посмотреть на чужой опыт, тем более если этот опыт обращается к общезначимым основам.
Геннадий Тышов писал(а):
Он должен:
Далее пункты списка объединены союзом "И" или "ИЛИ"?
Геннадий Тышов писал(а):
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 раундов определяется прежде всего разницей в технике.

Автор:  Axcel [ Воскресенье, 14 Февраль, 2010 18:25 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Если я правильно понял, Геннадий Тышов пытался сказать, что удельный вес собственно стиля программирования (на фоне других проблем) довольно мал. Кстати ИЕЕ это косвенно подтвердил рассказом о мотиве разработки системы на "Перл".

Автор:  ==== [ Воскресенье, 14 Февраль, 2010 18:36 ]
Заголовок сообщения:  Re: Почему программа должна быть структурной

Ваша работа в коллективе получить дружескую оценку, как положительную так и отрицательную и безусловно вы прислушаетесь.

Peter Almazov писал(а):
Похоже, Геннадий Тышов уверен, что изучение указанных источников не просто бесполезно, но еще и наносит ощутимый вред пунктам 1..16.
Случай тяжелый.

У Peter Almazov, вот еще одно предположение. Есть время обучения и время работы, все должно быть сделано во время. Ну, а в общем, надо учится всю жизнь.

Страница 1 из 8 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/