Кто использует блок схемы при программировании в 1с? #655053

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

сижу рисую временами

ну как бэ их в голове обычно рисуешь, практически всегда, а тебя именно на бумажке интересуют?

В уме рисуются сами.

когда надо заказчику через чур умному объяснить как и что работает

Иногда сложные задачи попадаются, на уме не могу, слишком объемно

Сейчас в школе, на математике, рекомендуют рисовать. Любой рисунок, что бы понять лучше.

пока в ВУЗе учился, делал в первых лабораторных работах все наоборот - сначала писал программу, а потом рисовал блок-схему.

Только чтобы показать заказчику схему работы продукта...

UML лучше, а блок схемы слишком муторно

Хочется IDF3 иногда порисовать, но руки не доходят и инструмента нет...

ErWin -- можно рисовать диаграммы БД.

$3900. Нет уж спасибо =)

мыслю кодом

Блок-схемы уже устарели. Они не позволяют полностью со всех точек зрения представить поведение программы. На смену блок-схемам сейчас используется UML. UML - современный язык для проектирования и моделирования программных систем. ORD - диаграммы для представления структуры БД. Подробнее - в интернете. Человеческий мозг так устроен, что структуры, состоящие из 7 - 10 элементов, он удержать и одновременно выполнять с ними мысленные манипуляции не может. Величайшие шахматные гроссмейстеры могут рассчитывать ходы вперед только на 20-25 полу-ходов. Поэтому моделирование нужно обязательно. Ведь моделируют везде: в строительстве, в машиностроении и т.д. Где-то читал, что перед тем как строить подводную лодку составляют документацию и чертежи, которые по объему занимают объем как несколько грузовиков. Для простых задач - модель необязательно рисовать на бумаге или в какой-то программе. Модель имеется в голове. Но когда возможностей мозга уже не хватает, такие задачи человек называет "сложными". Сложность - это и означает - сложность для восприятия человеком. В таких случаях средства для построения моделей (архитектуры программы, поведения программы) просто необходимы. Причем сейчас есть бесплатные пакеты и для UML, и для проектирования структуры БД. Например, Visual UML, если не ошибаюсь. Большинство моих задач требуют моделирования, хотя и не все. Но моделировать приходиться чаще чем "иногда". Поэтому я отвечаю "всегда".

Если сложные условия в кучу, то рисую. Чтобы ветви разделить без ошибок. Как-то более по нраву, чем потом ошибку вылавливать, которая может еще и не сразу проявиться :)

Полезная штука

Машинным? :)

Еще и логические матрицы.

Настоящий программер использует реверсивные блок схемы - это когда они составляются по коду и служат декорацией.

UML - такая же фигня, как и блок-схемы.

При проектном подходе к внедрениям всегда используем блок-схемы для описания всех бизнес-процессов. При мелких доработках уже нет. Хотя в правы, не всегда блок-схема способно наглядно описать сложный процесс. Надо будет изучить что такое UML.

Если делать без них получается овнокод

что это ?

Ты в слове "когда нужно впарить" допустил дофига ошибок.

обоснуй!

За 6 лет практики они пригодились лишь однажды - когда оформлял ПЗ.

только для сложных условий

ну многие и ООП не используют, это не значит, что ООП не нужно

Рисовал пару раз. А вообще для документации полезная штука, наверное!

рисуешь блок-схемы ?

рисую UML, не для 1С правда

Есть задачи, когда это нужно использовать, есть задачи, когда это возможно использовать, есть задачи, когда это не нужно использовать, есть задачи, когда это вредно с точки зрения воровства времени, есть задачи, когда это не нужно совсем. Блок - схема не единственный и не обязательный способ представления алгоритмического решения задачи. У любого представления есть существенный недостаток: это представление необходимо регулярно использовать, чтобы это был действительно рабочим инструментом. Только "анафига"?! Чаще всего неясна не задача целиком, какие-то отдельные моменты-подзадачи. Их можно набросать отдельно на клочке экрана монитора или на салфетке от бутерброда. А вот если нужно выпендриться и показать себя с необычной стороны, то графическое представление проекта, даже если он пустяковый, делает из программиста бога программирования. И еще один момент, если всю вариативность хотелок представлять графически, то ты только и будешь этим заниматься. И графическое представление удобно использовать тогда, когда задача ясна на 90-95 процентов. Если ты будешь рисовать блок схему той задачи, в которой ты не в теме ты поймешь, что пустяковая мысль в твоей схеме занимает большую площадь, старательно пряча общую идею и концептуальную суть. А если учесть, что сегодняшняя хотелка заказчика - дальнейшая реализация и доработка хотелки такой динамичный процесс, что ты своими стрелочками все сроки внредрения сорвешь. Вывод: графическое рисование или для временного самовыпендрежа, или для эпизодического выпендрежа перед зазчиком или у тебя времени дофига. Да есть еще вариант, что ты тупой на ровном месте, но я его не рассматриваю.

Дерзко однако! Не с той ноги?

Допустим у меня задача переписать с нуля расчет индивидуального подоходного налога и пенсионных отчислений. Задача имеет повороты, условия. Если все это держать в голове, то обязательно что-нибудь пропущу. Тогда придется заново переписать код или надо будет дохрена допилить. А если перед тобой тщательно проработанная блок-схема, то танцы на бубенцах уменьшатся в разы. Ща перед мной стоит дилемма именно в контексте жанной задачи. Поэтому интересно мнения большинства.

Рисую когда в голове решение не укладывается.

Не обязательно прям блок схемы рисовать, запиши моменты которые нужно учесть.

Если ты ноль в задаче, то ты даже пустяковую мысль размажешь на большую площадь "старательно пряча общую идею и концептуальную суть". Если у тебя сроки, то ты завалишь проект. Какая разница как ты будешь это "держать в голове". Способов уйма! Еще раз повторяю, если ты ноль в задаче, если ты регулярно не используешь в своей работе графическое представление, по сути не владея инструментом берешься решать задачу, в которой ты не смыслишь, то мне грустно...

Спокойно, попей чайку с мятой! ;)

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

Как я уже указал, "когда задача ясна на 90-95 процентов" то это (графическое представление) уместно, с нуля ... грустно ...

Тогда ты полностью со мной согласен. Множество деталей в графическом детальном представлении будут выглядеть просто страх как ужасТТТно!!! Ты глянь как выглядит решение на языке программирования такой банальности как квадратное уравнение и глянь блок-схему, как это рисуют в учбниках. И это при том, что на блок-схемах чаще всего опустают моменты ввода-вывода, нет нюансов интерфейсной сути. Если еще и блок-схемировать интерфейсы с нюансами /прятать показывать кнопочки/галочки, какие вплывающие подсзки выводить и тд и тп. Я полагаю, что про блок-схеммирование интерфейса ты и не подумал.

"графическое представление" Чо-та не понял в чем сложность, взять ручку, лист бумаги и поводить ручкой по бумаге.

Мечты, мечты... а время диктует свои условия :)

Ну, это -- CASE-средство, оно еще много чего умеет. Кроме того, есть специальная бесплатная российская версия на рутракере :) Еще как вариант, в Visio наклепать пользовательских контролов и их использовать.

Ты можешь и не "выводить" блок-схему.

> в Visio наклепать пользовательских контролов и их использовать Не лучше тогда уж в каком-то специализированном средстве, может и в бесплатном каком нибудь...

Не использую.

в своё время изучал нотации, прочитал книгу по UML, юзал десяток кейсов... фигня это всё реляционная модель - вот это вещь

Лучше бы в 1С было что-то типа JavaDoc - генерация пакета документации кода по комментариям. А то сидишь пишешь велосипед, а потом выясняется что в каком то общем модуле это уже реализовано

Если процесс сложный, то обязательно.