Programlamaya ilk başladığımda, akış şemalarına (ve yazıcı aralık şemalarına) büyük ölçüde güveniyordum. COBOL sınıfındayken akış şemam eğitmen tarafından kapatılana kadar herhangi bir kod yazmaya başlayamadım. O zamanlar her şey için akış şeması yapmak zorunda kaldım.

Bugün, yirmi beş yıl sonra kendimi sadece iki tür akış şeması olarak görüyorum. Tüm büyük adımları tanımladığım ve doğru sırayla almamı sağlamak için mantığın zor veya çok genel kavramlar olduğu çok spesifik algoritmalar.

Basitçe gözden kaçırdığım akış şemaları için başka kullanım durumları var mı?

Kesinlikle.

Daha önce yapmadığım bir şeyi her uyguladığımda (ve algoritma birkaç adımdan fazla sürüyorsa), bunu grafik olarak göstereceğim. Beni tüm çözümü, daha iyi bir atomik seviyede ve belirtilmemiş olandan daha kapsamlı bir şekilde analiz etmeye zorladığını görüyorum. Bu uygulamanın üç önemli faydası olduğunu düşünüyorum:

• Daha az "oh craps" çünkü tüm algoritmayı düşündüm
• Sistemin geri kalanında oluşabilecek sorunları ortadan kaldırır
• Algoritma ile başka birini kolayca gezebilmemi sağlar

Bunları aslında kullandığım iki farklı durum:

• Düşük (ish) seviye algoritmaları. Çok özel bir soruna çok özel bir çözüm demek istiyorum. Bunları genellikle uygulamadan önce akranlar tarafından ileteceğim.
• Kullanıcı akışı. Bunu sadece bir akrandan geçirmek için değil, aynı zamanda bir kullanılabilirlik uzmanına (çok teknik olmayan bir şekilde) akışı açıklamak için de kullanacağım.

Tüm bunları söyledikten sonra, günlük akış şemaları üretmiyorum (ve bittiğinde bile, teknik bir tasarım dokümanı yazmadıkça genellikle bir beyaz tahta oturumu).

Asla

Akış şemaları - özellikle 25+ yıl önce uygulandığı üzere - çok daha etkileyici diyagramlama teknikleri (cf Eylem Diyagramları, Dizi Grafikleri, Durum Grafikleri ve diğerleri) ile değiştirilmiştir.

IBM'in kendi çalışmaları, akış şemalarının kullanımının, bir sistemin tasarım veya uygulamasının kalitesi üzerinde hiçbir etkisi olmadığını göstermiştir (kullanıcılar ve diğer geliştiricilerle iletişim kurmak için marjinal olarak yararlı olsalar da) [kesin referans halihazırda mevcut değildir, ancak James Martin'in Diyagram Tekniklerinde belirtilmiştir Analistler ve Programcılar için ].

1976'daki ilk programlama sınıfımdan bu yana klasik bir akış şeması çizmedim ve 80'lerin başından beri kimsenin bir tane yarattığını görmedim. Akış şemaları, kod montaj dilinde iken program mantığını iletmek için kullanışlıdır. 1960'ların sonunda, montaj dili programcıları sahte kod kullanıyordu. Modern OO dillerinde programlama yaparken, ne akış şemalarının ne de sahte kodun herhangi bir değeri yoktur. Uygulama dilinde üst düzey kod da yazabilirsiniz.

Tasarım fikirlerini ifade etmek için zaman zaman çoğunlukla kağıt üzerine UML diyagramları çiziyorum, ancak bu diyagramlar sadece tartışmanın sonuna kadar yaşıyor. Ayrıca zaman zaman durum geçiş diyagramları çiziyorum, ardından bunları uygulama dilinde bir durum tablosuna dönüştürüyorum.

Akış şemalarını çeşitli nedenlerle her zaman kullanıyorum:

1. Bence UML kullanım senaryolarından daha iyi. Bir dizi farklı kullanım durumunu ve nasıl etkileştiklerini yansıtabilirler ve genel olarak kullanıcı deneyimini ve kararlarını bir araya getirerek daha iyi bir iş çıkarırlar.

2. Anlamaları daha kolay ve daha sezgisel. Zihniniz doğal olarak okları baştan sona labirent gibi takip eder. Farklı bir kullanıcı hikayesi için başka bir akış şemasını sonlandırmak ve referans vermek için akış şemalarını kullanabilirsiniz. Bunları genellikle bir sayfa numaralı kitapta yazdırabilir ve bir sonraki akış şemasına gitmek için sayfaları hızlıca çevirebilirim.

3. Evrenseldirler. Yazılım mühendisliği dışındaki çok az insan, Akış Şeması diyagramlarının kullanıcılar ve iş analistleri tarafından çok daha tanınabildiği UML diyagramlarını bilir ve anlar. Karmaşık kullanım örneklerini bir müşteriyle paylaşmaya çalışıyorum ve bazen kavramak için mücadele ediyorlar, onlara bir akış şeması çiziyorum ve nihayet neden onu düşündüğünden daha karmaşık hale getiren tüm nüansları anladığını anlıyorlar.

Akış şemaları, işlerin belirli bir sırada yapılması gerektiğinde yararlıdır. Aklımda gerçekten parladıkları yer, kararların nerede verildiğini gösteriyor ve her olası kararın bir yolu olduğundan emin olmak. Bu, bir yönetici onayının gerekli olduğu, ancak yöneticinin (zamanın% 98'ini onaylayan) hayır diyorsa, bununla başa çıkmanın bir yolu olmayan programlar oluşturmayı önler. Bize en yaygın yolun tek yol olmadığını hatırlatırlar. Kullanıcılarla gereksinimler hakkında konuşurken onları yararlı buluyorum çünkü çoğu zaman size yalnızca en yaygın yolu söyleyeceklerdir.

Akış Şemaları, çok kötü yapılandırılmış kodların tersine mühendislik için yararlı olabilir. Özellikle de gotos varsa. Neyse ki son zamanlarda çok goto-riddden kodu görmedim.

Diğerlerinin belirttiği gibi son kullanıcılarla iletişim kurduk. Akış şemasında belgelenen bir TV vericisinin başlatılmasını sıralıyorum. Donanım ve yazılım çalışanlarının ortak bir şartnamesi vardı.

UML Etkinlik Diyagramı ve Akış Şeması, bir işlem veya algoritmanın düşük ila orta karmaşıklığını göstermek için kullanışlıdır.

İş kullanıcılarıyla iş kuralları hakkında iletişim kurarken çok iyidirler.

İş Süreci Modellemesinde çok yararlı olan BPMN 2.0 formunda bir varyasyon bulunmaktadır.

Bazı BPMN araçları grafiklerden çalışan web uygulamaları oluşturabilir.

Bu yüzden evet, akış şemalarının hala bir yeri var, ancak akıllıca kullanılmaları gerekiyor.

Ben programcı değilim. Ben bir donanım mühendisliği teknolojisiyim.

En azından kullanılacak mantıksal blokları açıklayan yorumlarla başlamak bana mantıklı geliyor. Bundan sonra, program iskeletini gerçek kodla temizleyin. Bir film senaryosunu bir hikaye panosuyla başlatmaya ve daha sonra eylem ayrıntılarını ve iletişim kutusunu doldurmaya benzer.

Değerli bir çaba dikkatle planlanmamalı mı? Donanım alanında, bir müşteri gereksinim belgesiyle başlıyoruz, daha sonra bir donanım spesifikasyon belgesi yazıyoruz, daha sonra şemayı alıyoruz, daha sonra bir tahta düzeni çiziyoruz, ardından montaj belgeleri ile geliyoruz. Son ürünü yapmak için fikirler ürettiğimiz için sadece parçaları tutmaya ve lehimlemeye başlamıyoruz.

Ben gerçek kodlama başlamadan önce hazırlık çalışmaları bol olmadan 15KB veya 15MB programında kod ne kadar verimli yazılabilir görmüyorum.