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

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

Чи є інші випадки використання для блок-схем, які я просто не помітив?

Абсолютно.

Щоразу, коли я впроваджую щось, чого раніше не робив (і алгоритм займає більше декількох кроків), я буду це схему. Я вважаю, що це насправді змушує мене проаналізувати все рішення на більш атомному рівні і більш ретельно, ніж якби воно не було зафіксовано. Я вважаю, що є три основні переваги цієї практики:

• Менше "о, лайно", тому що я продумав весь алгоритм
• Вимиває будь-який потенційний стукіт проблем, які можуть виникнути в іншій частині системи
• Дозволяє мені легко пройти когось іншого за алгоритмом

Два різних випадки, коли я їх фактично використовую, це:

• Алгоритми низького рівня. Я маю на увазі дуже специфічне рішення дуже конкретної проблеми. Як правило, я передаю їх одноліткам перед впровадженням.
• Потік користувачів. Я не тільки можу це використати, щоб пройти повз однолітків, але я також використаю це, щоб пояснити (дуже нетехнічним чином) потік експерту з юзабіліті.

Сказавши все це, я не випускаю блок-схеми щодня (і навіть коли вони закінчені, це взагалі сесія на дошці, якщо я не пишу документацію технічного проектування).

Ніколи

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

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

Я не малював класичну схему руху з мого першого класу програмування в 1976 році, і ще не бачив, щоб хтось створив її з початку 80-х. Діаграми потоків були корисні для передачі логіки програми, коли код був мовою асемблера. До кінця 1960-х програмісти з мовної збірки використовували псевдо-код. При програмуванні на сучасних мовах OO ні діаграми потоку, ні псевдо-код не мають значення. Ви також можете добре написати код високого рівня мовою реалізації.

Я час від часу малюю діаграми UML, переважно на папері, щоб висловити дизайнерські ідеї, але ці діаграми живуть лише до кінця дискусії. Я також час від часу малюю схеми переходу стану, після чого перетворюю їх у таблицю стану мовою реалізації.

Я постійно використовую блок-схеми з кількох причин:

1. На мій погляд, вони краще, ніж UML використовують діаграми випадків. Вони можуть відображати ряд різних випадків використання та способів їх взаємодії, і вони роблять кращу роботу в цілому, поєднуючи досвід та рішення користувачів.

2. Вони легші для розуміння та інтуїтивніші. Ваш розум природно слідкує за стрілками як лабіринт від початку до кінця. Ви можете використовувати блок-схеми потоків для завершення та посилання іншої блок-схеми для іншої історії користувача. Я, як правило, можу надрукувати їх у книжці, пронумерованій на сторінці, і швидко гортати сторінки, щоб перейти до наступної схеми потоку.

3. Вони універсальні. Мало хто за межами програмної інженерії знає і розуміє діаграми UML, де діаграми блок-схеми набагато більше впізнавані користувачами та бізнес-аналітиками. Я намагаюся донести до клієнта складні випадки використання, і вони іноді намагаються зрозуміти, я малюю їм блок-схему, і вони розуміють, чому нарешті розуміють усі нюанси, які роблять МНОГО БОЛЬШІ складними, ніж вони думали.

Блок-схеми корисні, коли справи потрібно робити в певному порядку. Де вони справді світять мені в думці, показує, де приймаються рішення, і переконайтесь, що кожне можливе рішення має шлях. Це запобігає створенню програм, де потрібне схвалення mamager, але немає можливості з цим впоратися, якщо менеджер (який затверджує 98% часу) каже "ні". Вони нагадують нам, що найпоширеніший шлях - це не єдиний шлях. Я вважаю їх корисними в розмові з користувачами про вимоги, оскільки часто вони розкажуть вам лише про найпоширеніший шлях.

Діаграми потоків можуть бути корисні для зворотної інженерії дуже погано структурованого коду. Особливо, якщо він має готос. На щастя, останнім часом я не бачив багато гот-скриптованого коду.

Як зазначали інші для спілкування з кінцевими споживачами. Я сортую запуск телевізійного передавача, задокументованого блок-схемою. Для апаратних та програмних засобів люди мали спільну специфікацію, з якою працювати.

Діаграма діяльності та діаграма UML корисна для показу низької та середньої складності процесу чи алгоритму.

Вони дуже добре спілкуються з діловими користувачами щодо правил бізнесу.

Існує варіант у формі BPMN 2.0, що дуже корисно в моделюванні бізнес-процесів.

Деякі інструменти BPMN можуть генерувати запущені веб-програми із графіків.

Так, так, блок-схеми все ще мають місце, але їх потрібно використовувати розумно.

Я не програміст. Я технік апаратної інженерії.

Мені є сенс почати хоча б з коментарів, що пояснюють логічні блоки, які будуть використовуватися. Після цього розробляємо скелет програми з фактичним кодом. Це схоже на те, щоб почати сценарій фільму з дошкою історії, а потім заповнити деталі дії та діалогове вікно після цього.

Чи не варто ретельно планувати будь-які гідні зусилля? У апаратній царині ми починаємо з вимоги доктора клієнта, потім виписуємо документ із специфікацією обладнання, потім розгортаємо схематичне, потім малюємо макет плати, потім придумуємо монтажну документацію. Ми не просто починаємо захоплювати деталі і паяти їх разом, коли придумуємо ідеї зробити кінцевий продукт.

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