记于 2020.10：
文章写于 16 年 1 月，想法积累大概在 15 年工作后。那时刚毕业文章很粗糙（笑）。但至少对我却非常重要。
这篇文章出来后，我才开始觉得，我建立了能弄清楚一个程序 所有元素 的思维方式
其意义在于：如果我要谈代码设计，前提必然要知道程序有什么，可谓 我代码设计的基础
如果一个程序，我没有办法弄清楚里面**所有**元素，那组织好这些元素并做设计就无从谈起
如何描述一个程序
核心内容现在看起来很简单，可以这么概括：
- 程序有三要素： 状态， 事件（所有执行函数）， 表现（界面，数据库，内部某一刻呈现（不一定是可视界面））
（上图记于 2016，现在的想法已多有改变，但暂未做新的总结更新）
（程序中的所有变量就是状态，直观的比如isLogin：boolean，不直观的比如 Array 多了个元素） - 对一段逻辑详细描述是： 基于什么状态下，触发的哪个行为，会导致哪些状态变化，新状态下的表现是怎么样的
- 所以实现一段代码时考虑下面的因素， 我认为基本算考虑全面：
- 当前处于什么状态
- 在这个状态下触发的函数，应该执行怎样的行为
- 这个行为发生后，会修改哪些状态
- 这个新的状态，对应此时程序的表现应该如何
如果您是面试官，或者刚好看到这篇文章又感兴趣的朋友。我将16 年的笔记放在这（one note 加载比较慢），里面详细介绍我想表的思路
Microsoft OneDrive - 从任何位置访问文件。使用免费的 Office Online 创建文档。
ps. 在我接触了响应式编程， 更准确的说 React 后，那种界面直接与状态绑定的方式, 让我意识到,描述界面时, 以前那种通过函数去描述的那种别扭之处在哪
从拿到需求开始
彼时刚毕业，面对拿到手的 “产品需求” 和 “界面交互”， 比较懵的一点是
“我怎么将这些东西变成程序“
对照静态的纸面需求和界面，搭出界面不是难事。但表面的需求和界面，后面是隐藏着的时序和逻辑。
开始的做法是对照着界面，顺着产品的文档， 一条条列出涉及的点
但这么做，不久就发现了弊端，照着静态的东西考虑， 始终会有遗漏：
同一条行为，同一个界面，在不同条件下表现不同
这里面有一个很重要的概念：
状态
产品和设计通常意识不到：”他们所写的需求和 UI，默认都处于某个 状态 “，看似承接的行为或先后的两个页面， 背后实际可能发生过状态转换
这里面问题在于： 需求文档，和设计稿，并没有显式（或者他们没意识到）的提到状态
纸面上看似通常的流程， 在实际实现时，逻辑上难以自洽
因为没有意识到，就没办法写出当一件事情发生时所有分支情况，UI 上没法体现 所有 界面样式。
而这些， 在程序实现时都是必须考虑的，几乎需求评审或开发时遇到的逻辑问题，根源都是某个状态没考虑到
于是早期，我描述程序时，就借用树结构，尝试描述界面和事件在不同状态下的情况
（下图是 15 年所画，已经很久的程序版本，不涉密）
较为成熟的版本在 17 年：
这之后，我自己认为，只要有充足的时间，这个思路能帮助我把纸面的需求想的比较清楚。
一方面对我把我程序，对程序做设计提供了不少帮助。
实际工作中，有些多年经验的开发，预估功能时也常会说我只能给个粗略的预估,提供一些很粗的模块作为预估点；
并且在我多组合作经验中，部分同事并不能把要做的事情很细致的拆分出来。18~19 年的项目，曾遭遇很严重近 1 年的 delay。而即使在后期，也没人能说清楚，完成了多少功能，待验收哪些功能。我们是否对剩余的工作量有信心（我记录在这个专题中： 我尝试改进软件组迭代 ）
这时候我意识到，能清晰描述一个程序是很重要的。
最后：原文在：Microsoft OneDrive - 从任何位置访问文件。使用免费的 Office Online 创建文档。
这是导出的文件：
分享用笔记本 - Microsoft OneNote Online.pdf