求助 ， 有 没有 什么 C / C + + 的 方法 ， 可以 直接 把 数据 流程图 映射 为 可 执行 模块 。
请 牢记 ： 源代码 本身 的 书写 是否 结构化 或 面向 对象 或 符合 设计 模式 或 敏捷 … 并 不 重要 ， 重要 的 是 你 是否 使用 结构化 或 面向 对象 或 符合 设计 模式 或 敏捷 … 的 方法 命名 标识符 、 阅读 、 修改 、 检查 、 测试 源代码 。 意思 是 你 程序 结构 看上去 再 合理 ， 再 简洁 ， 也 不 一定 比 看上去 一 团 乱麻 的 程序 结构 在 运行 或 修改 时 更 不 易 出错 ， 更 方便 修改 ， 出错 了 更 容易 找到 哪里 出错 和 具体 出错 的 原因 ， 更 容易 改正 错误 。 试 对比 图书馆 （ 对 图书 的 分类 够 结构化 了 吧 ） 和 搜索 引擎 （ 可 看作 是 扁平化 任何 结构 数据 ， 仅 支持 全 文 检索 ） 哪个 处理 信息 更 方便 、 更 高效 。 所以 与其 费劲 去 重构 代码 让 其 看 上去 更 简洁 、 更 合理 不 如 费劲 学习 grep 、 sed 、 awk 、 … … 这 类 全 文 搜索 和 批 处理 编辑 的 工具 。 结构 越 复杂 ， 越 难 修改 ， 越 难 除错 。 有时 （ 甚至 大多数 时候 ） ， 看上去 越 合理 、 越 简洁 的 代码 ， 运行 起来 性能 越 差 ， 出错 时 查找 原因 越 难 ， 找到 出错 原因 后 改正 越 费劲 。 程序员 要 做 的 不 是 尽力 避免 错误 ， 而 是 聚焦 在 快速 发现 并 改正 错误 。 真正 以 快速 方式 轻易 解决 错误 ， “ 快速 的 失败 ” 远 胜过 “ 预防 错误 ” 。 Fred George
