隨著AI輔助程式碼撰寫的日益依賴，我們已經很少看到有人拿出筆記本勾勒出演算法或計畫來解決給定的問題了。 在過去，流程圖是人們可以用來繪製和視覺化解決方案的基本方法之一！它確實需要時間，但從長遠來看，它產生較少有錯誤的解決方案，所以也許，只是也許，它值得再次拿起來！
以下是取自James W. Coffron所著「programming the 8086/8088」一書的片段，我對其內容不負任何功勞。這本書出版於1983年，當時人們還在他們幾乎像冰箱一樣大的IBM PC上用單純的老式組合語言撰寫程式碼，在記憶體中摸索著找到通過程式碼邏輯的方法。
那是多麼不同的時代…
流程圖
流程圖只是演算法的符號表示，通常表達為矩形和菱形的序列。在流程圖上，矩形用於表示命令（或可執行語句），菱形用於測試，例如：如果資訊X為真，則採取行動A；如果不是，則採取行動B。
圖1.1顯示了一個流程圖範例。 流程圖是演算法規格和實際編碼解決方案之間高度推薦的中間步驟。值得注意的是，據觀察，也許10%的程式設計人口可以在不準備流程圖的情況下成功撰寫程式。不幸的是，也觀察到90%的人口認為自己屬於這10%！結果是，平均而言，80%的程式在第一次在電腦上運行時失敗。（這些百分比自然不是要精確的。）簡而言之，大多數新手程式設計師很少看到繪製流程圖的必要性。
圖表來自James W. Coffron所著Programming the 8086/8088一書
忽略流程圖步驟通常會導致錯誤的程式，程式設計師必須花很長時間測試和修正他或她的程式。（這被稱為除錯階段。）
因此，在所有情況下都高度推薦流程圖的紀律。流程圖通常需要在編碼之前花少量額外時間，通常會產生清晰的程式，在短時間內正確執行。一旦流程圖的程序被很好地理解，一小部分程式設計師可以在心理上執行這一步驟，而不使用紙張。不幸的是，在這種情況下，他們撰寫的程式通常對其他人來說難以理解，因為通常與流程圖一起提供的文件不可用。普遍建議流程圖作為任何超過十或十五條指令的程式的嚴格紀律使用。
雖然這種做法可能不再是交付穩健運作程式碼所必需的，但當即興發揮有時感覺不可能時，它可能仍然是一個想出好解決方案的好工具。