随着AI辅助代码编写的日益普及，我们已经很少看到有人拿出笔记本，勾画算法或规划解决方案了。 在过去，流程图是人们用来映射和可视化解决方案的基本方法之一！它确实需要时间，但从长远来看，它能产生更少bug的解决方案，所以也许，只是也许，它值得重新拾起！
以下是摘自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》
忽略流程图步骤通常会导致错误的程序，程序员必须花费大量时间测试和纠正他或她的程序。（这被称为调试阶段。）
因此，在所有情况下都强烈推荐流程图的规范。流程图通常只需要在编码前花费少量额外时间，并且通常会在短时间内产生清晰且正确执行的程序。一旦流程图的程序被很好理解，少数程序员可以在心理上执行这一步骤，而不使用纸张。不幸的是，在这种情况下，他们编写的程序通常对其他人来说难以理解，因为通常与流程图一起提供的文档不可用。普遍建议对任何超过十或十五条指令的程序使用流程图作为严格的规范。
虽然这种做法可能不再是发布健壮工作代码所必需的，但当即兴创作有时感觉不可能时，它可能仍然是想出好解决方案的好工具。