探索外包开发的极限：一个精品App诞生的全过程(11)

Onenote文档中不光得有Visio原型，还需要很多的附加文档，从性质上看，主要包括“宏”、“系统文档”和“集中说明”。它们并不是我一开始就明白要去单独做的，而是做原型的过程中，遇到了用Visio无法说清的问题，或是即使说清了，也会让Visio图形变得太过臃肿，于是就自然而然地想到要另起炉灶了。

（1/3）附加文档：宏

（1）首先说“宏”

“宏”一般用来归纳那些App中零散出现的，但是不便于统一成某个模块的东西。上图是一个用来归纳「the App」中所有后期可能要变动的数值的Excel表格，例如，打孔器的冷却时间是多少个小时？打一次孔的加分是多少？每个信念最多能容纳的感悟数量是多少？……这些数值我无法一次确定下来，需要在试用过程中不断调整，显然，如果我今天在A文档里去改数值α，明天在B文档里去改数值β，我和智超之间至少有一个人会疯掉的。

当我写一个宏文档，智超就会在代码里写一个宏，在这个宏里他就能直接修改这些数值，并能自动应用到所有关联的代码，只需要几秒钟就搞定了。而在后期测试的时候，我显然不能像数值中要求的那样：一个感悟写下来之后，隔9小时才能淬火——我只有1分钟的耐心。那么很简单，我在表格中多加入一列“测试数值”，写上“1分钟”，到时要个测试版就行了。

（2/3）附加文档：系统文档

（2）“系统文档”

Visio原型比较善于表达前端的流程或状态机的逻辑，而如果你想要详细阐述某个系统的原理就比较难了。「the App」中“文件夹”这个概念，在Visio中主要描述的是看得到的部分，而看不到的细节就要用Word文档来描述了（上图左），例如：文件夹是否可以重名？是否可以为空？两个栏目的文件排序规则分别是什么？这些东西在Word文档中用论文的结构可以很轻松地交代明白。

「the App」的文件夹都有封面，这些封面包括3种，第1种是特殊文件夹的固定封面（包括不设置封面时的默认代图），第2种是用户自己拍摄或导入照片，第3种是系统自带的封面。那么这就带来一些问题，例如：固定封面是否属于系统自带封面可供选择？用户自己拍摄的照片被替换掉之后，是否继续保存？……

这些问题很难用简洁的文字来概括，所以我做了一些“伪数据结构”（例如上图右），虽然这个数据结构设计得很外行，直接采用可能会引起手机爆炸，但文档的意义在于沟通，伪数据结构的表达方式在这里能用最少的废话讲清楚我要干什么，那么它就是最好的沟通方式。同理，你甚至可以用伪代码的方式来描述一些文字不便形容的逻辑，只要程序员能轻松理解到跟你完全一样的想法，何乐而不为呢？

（3/3）附加文档：集中说明

最后一种情况是“集中说明”，顾名思义，「the App」中很多东西是零散的，不便于在主文档中出现的。例如左图归纳了App中所有出现的文本输入窗口的具体属性，包括它们的窗口名、初始文本……这样我在原型中就不必列举每个文本输入页面的具体属性；再例如右图归纳了App中所有教程的出现时机、地点、展现方式，同理，这些凌乱的东西根本不应该出现在主文档不是吗？

（编辑：ASP站长网）