Kiedy zaczynałem programować, polegałem głównie na schematach blokowych (i schematach odstępów między drukarkami). Gdy byłem w klasie COBOL, nie mogłem zacząć pisać żadnego kodu, dopóki mój schemat blokowy nie zostanie podpisany przez instruktora. Wtedy musiałem stworzyć schemat blokowy dla wszystkiego.

Dzisiaj, dwadzieścia pięć lat później, odkrywam, że wykreślam tylko dwa rodzaje rzeczy. Bardzo specyficzne algorytmy, w których logika jest trudna, lub bardzo ogólne pojęcia, aby zapewnić, że wszystkie duże kroki zostaną zdefiniowane i we właściwej kolejności.

Czy są inne przypadki użycia schematów blokowych, które po prostu przeoczyłem?

Absolutnie.

Ilekroć implementuję coś, czego wcześniej nie robiłem (a algorytm zajmuje więcej niż kilka kroków), wykreślę to. Uważam, że naprawdę zmusza mnie to do przeanalizowania całego rozwiązania na poziomie atomowym i dokładniej, niż gdyby nie zostało to przedstawione na wykresie. Uważam, że ta praktyka ma trzy główne zalety:

• Mniej „o cholera”, bo przemyślałem cały algorytm
• Usuwa wszelkie potencjalne powalenia na problemy, które mogą wystąpić w pozostałej części systemu
• Pozwala mi łatwo przeprowadzić algorytm przez kogoś innego

Dwie różne sytuacje, w których faktycznie ich używam, to:

• Algorytmy niskiego poziomu (ish). Mam na myśli bardzo konkretne rozwiązanie bardzo konkretnego problemu. Zazwyczaj przekażę je innym użytkownikom przed wdrożeniem.
• Przepływ użytkowników. Nie tylko mogę tego użyć, aby ominąć równorzędnego użytkownika, ale również użyję go do wyjaśnienia (w bardzo nietechniczny sposób) przepływu ekspertowi ds. Użyteczności.

Powiedziawszy to wszystko, nie tworzę schematów blokowych codziennie (a nawet po ich zakończeniu, jest to zazwyczaj sesja na tablicy, chyba że piszę dokumentację dotyczącą projektu technicznego).

Nigdy

Schematy blokowe - zwłaszcza praktykowane ponad 25 lat temu - zostały zastąpione o wiele bardziej ekspresyjnymi technikami tworzenia diagramów (por. Diagramy akcji, tabele sekwencji, tabele stanu i in.).

Własne badania IBM wykazały, że wykorzystanie schematów blokowych nie miało wpływu na jakość projektu lub implementacji systemu (choć były one nieznacznie przydatne w komunikacji z użytkownikami i innymi programistami) [dokładne odniesienie nie jest łatwo dostępne, ale zostało cytowane w technikach diagramowych Jamesa Martina dla analityków i programistów ].

Nie rysowałem klasycznego schematu od czasu mojej pierwszej klasy programowania w 1976 roku i nie widziałem, żeby ktoś inny go tworzył od wczesnych lat 80-tych. Schematy blokowe były przydatne do komunikowania się z logiką programu, gdy kod był w języku asemblera. Pod koniec lat sześćdziesiątych programiści w asemblerze używali pseudokodu. Podczas programowania we współczesnych językach OO, ani schematy blokowe, ani pseudokod nie mają żadnej wartości. Równie dobrze możesz napisać kod wysokiego poziomu w języku implementacji.

Od czasu do czasu rysuję diagramy UML, głównie na papierze, aby wyrazić pomysły projektowe, ale te diagramy istnieją tylko do końca dyskusji. Od czasu do czasu rysuję również diagramy przejścia stanu, a następnie przekształcam je w tabelę stanów w języku implementacyjnym.

Ciągle używam schematów blokowych z wielu powodów:

1. Są lepsze niż diagramy przypadków użycia UML. Mogą odzwierciedlać wiele różnych przypadków użycia i ich interakcji, a także wykonują lepszą pracę, łącząc wrażenia użytkowników i decyzje razem.

2. Są łatwiejsze do zrozumienia i bardziej intuicyjne. Twój umysł naturalnie podąża za strzałkami jak labirynt od początku do końca. Za pomocą schematów blokowych można zakończyć i odwołać się do innego schematu blokowego dla innej historii użytkownika. Zwykle mogę wydrukować je w książce z numerami stron i szybko przewracać strony, aby przejść do następnego schematu.

3. Są uniwersalne. Niewiele osób spoza inżynierii oprogramowania zna i rozumie diagramy UML, gdzie diagramy Flowchart są znacznie bardziej rozpoznawalne przez użytkowników i analityków biznesowych. Staram się przekazać klientowi skomplikowane przypadki użycia, a czasami próbują to zrozumieć, rysuję schemat blokowy i rozumieją, dlaczego w końcu rozumieją wszystkie niuanse, które sprawiają, że jest WIELE WIĘCEJ, niż im się wydawało.

Schematy blokowe są przydatne, gdy należy wykonać czynności w określonej kolejności. To, co naprawdę świeci w moich myślach, pokazuje, gdzie podejmowane są decyzje i upewnia się, że każda możliwa decyzja ma swoją ścieżkę. Zapobiega to tworzeniu programów, w których wymagana jest zgoda administratora, ale nie ma możliwości poradzenia sobie z tym, jeśli menedżer (który zatwierdza 98% czasu) odmówi. Przypominają nam, że najczęstsza ścieżka nie jest jedyną ścieżką. Uważam je za przydatne w rozmowach z użytkownikami na temat wymagań, ponieważ często podadzą ci tylko najczęstszą ścieżkę.

Schematy blokowe mogą być przydatne w przypadku bardzo źle ustrukturyzowanego kodu inżynierii wstecznej. Zwłaszcza jeśli ma problemy. Na szczęście ostatnio nie widziałem zbyt wielu zagadek.

Jak zauważyli inni, do komunikowania się z użytkownikami końcowymi. Sortuję uruchomienie nadajnika telewizyjnego udokumentowane schematem blokowym. Sprzęt i oprogramowanie miały wspólną specyfikację do pracy.

Diagram aktywności UML i schemat blokowy są przydatne do wykazania niskiej lub średniej złożoności procesu lub algorytmu.

Są bardzo dobre, gdy komunikują się z użytkownikami biznesowymi na temat reguł biznesowych.

Istnieje odmiana w postaci BPMN 2.0, która jest bardzo przydatna w modelowaniu procesów biznesowych.

Niektóre narzędzia BPMN mogą generować działające aplikacje internetowe z wykresów.

Tak więc, schematy blokowe wciąż mają swoje miejsce, ale należy z nich mądrze korzystać.

Nie jestem programistą. Jestem technikiem inżynierii sprzętu.

Ma dla mnie sens zacząć przynajmniej od komentarzy wyjaśniających logiczne bloki, które zostaną użyte. Następnie, dopracowując szkielet programu z rzeczywistym kodem. Jest to podobne do rozpoczęcia scenariusza filmowego z planszą, a następnie wypełnienia szczegółów akcji i dialogu.

Czy nie warto starannie zaplanować żadnego wartościowego przedsięwzięcia? W dziedzinie sprzętu zaczynamy od dokumentu wymagań klienta, a następnie wypisujemy dokument specyfikacji sprzętu, następnie opracowujemy schemat, następnie rysujemy układ płytki, a następnie opracowujemy dokumentację montażu. Nie tylko zaczynamy chwytać części i lutować je razem, ale wymyślamy pomysły na produkt końcowy.

Nie widzę, jak efektywny kod można napisać w programie 15 KB lub 15 MB bez dużej ilości pracy przygotowawczej przed rozpoczęciem właściwego kodowania.