Когда я впервые начал программировать, я сильно полагался на блок-схемы (и диаграммы интервалов между принтерами). Пока я учился в классе COBOL, я не мог начать писать код, пока инструктор не подписал мою потоковую диаграмму. Тогда я должен был сделать блок-схему для всего.

Сегодня, двадцать пять лет спустя, я обнаруживаю только блок-схему двух типов вещей. Очень специфические алгоритмы, где логика хитрая или очень общие понятия, чтобы гарантировать, что я получу все большие шаги, определенные и в правильном порядке.

Есть ли другие варианты использования для блок-схем, которые я просто пропустил?

Абсолютно.

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

• Меньше "ой крэпс", потому что я продумал весь алгоритм
• Устраняет любые потенциальные проблемы, которые могут возникнуть в остальной части системы
• Позволяет мне легко пройти кого-то еще через алгоритм

Два разных случая, где я на самом деле использую это:

• Алгоритмы низкого (ish) уровня. Я имею в виду очень конкретное решение очень конкретной проблемы. Обычно я передаю их коллегам до реализации.
• Пользовательский поток. Я не только могу использовать это для прохождения через одноранговый узел, но я также буду использовать его для объяснения (очень нетехническим образом) потока специалисту по юзабилити.

Сказав все это, я не создаю потоковые диаграммы ежедневно (и даже когда они сделаны, это, как правило, сеанс доски, если я не пишу документ по техническому проектированию).

Никогда

Блок-схемы - особенно те, которые практиковались более 25 лет назад - были заменены гораздо более выразительными методами построения диаграмм (см. Диаграммы действий, Диаграммы последовательности, Диаграммы состояний и др.).

Собственные исследования IBM показали, что использование потоковых диаграмм не влияло на качество проектирования или реализации системы (хотя они были незначительно полезны для общения с пользователями и другими разработчиками) [точная ссылка не всегда доступна, но была процитирована в Методиках диаграмм Джеймса Мартина для аналитиков и программистов .

Я не рисовал классическую блок-схему с моего первого урока программирования в 1976 году, и не видел, чтобы кто-то еще создавал его с начала 80-х. Блок-схемы были полезны для передачи логики программы, когда код был на языке ассемблера. К концу 1960-х программисты на ассемблере использовали псевдокод. При программировании на современных ОО-языках ни блок-схемы, ни псевдокод не имеют никакого значения. Вы также можете написать высокоуровневый код на языке реализации.

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

Я использую потоковые диаграммы все время по ряду причин:

1. По моему мнению, они лучше диаграмм вариантов использования UML. Они могут отражать ряд различных вариантов использования и то, как они взаимодействуют, и в целом они работают лучше, объединяя пользовательский опыт и решения.

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

3. Они универсальны. Мало кто за пределами разработки программного обеспечения знает и понимает диаграммы UML, где диаграммы потоковых диаграмм гораздо более узнаваемы пользователями и бизнес-аналитиками. Я пытаюсь донести до клиентов сложные варианты использования, и они иногда пытаются понять, я рисую им блок-схему, и они понимают, почему, наконец, понимают все нюансы, которые делают его намного более сложным, чем они думали.

Блок-схемы полезны, когда все должно быть сделано в определенном порядке. Где они действительно сияют в моей голове - это показать, где принимаются решения, и убедиться, что у каждого возможного решения есть свой путь. Это предотвращает создание программ, в которых требуется одобрение mamager, но они не могут с этим справиться, если менеджер (который утверждает 98% времени) говорит «нет». Они напоминают нам, что самый распространенный путь - это не единственный путь. Я нахожу их полезными в разговоре с пользователями о требованиях, потому что часто они сообщают вам только самый распространенный путь.

Блок-схемы могут быть полезны для обратного проектирования очень плохо структурированного кода. Особенно, если у него есть gotos. К счастью, в последнее время я не встречал много кода с гото-загадками.

Как и другие, отметили общение с конечными пользователями. Я сортирую запуск телевизионного передатчика, задокументированного блок-схемой. Специалисты по аппаратному и программному обеспечению имели общую спецификацию для работы.

Диаграмма активности UML и блок-схема полезны для демонстрации сложности процесса или алгоритма от низкого до среднего.

Они очень хороши при общении с бизнес-пользователями о бизнес-правилах.

Существует разновидность BPMN 2.0, которая очень полезна в моделировании бизнес-процессов.

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

Так что да, у блок-схем есть место, но их нужно использовать с умом.

Я не программист. Я инженер по аппаратному обеспечению.

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

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

Я не вижу, как эффективный код может быть написан в программе размером 15 КБ или 15 МБ без большого количества подготовительной работы перед началом реального кодирования.