一直听闻开发是被不断变化的需求搞死的,不过实际上还没有具体经历过。但是,不知是不是因为我记忆力越来越不好的原因,一直感觉开发过程中一直不能做到有据可循。讨论的结果大都是口头协议或者草稿的形式,好不容易写出一个相对好些的文档,又束之高阁了,开发、维护的过程中很少去看,更不用说去更新了。
今天在看protobuf的文档的时候,突然感觉,其实写文档的思路要和新学习一个东西的思路使一致的。很多人只想到这一层,但是很少去想这在种“新学习”的思路具体是什么思路呢。protobuf的目录结构给了一个很好的答案:
- Overview:是什么,能干什么,解决什么问题
- Language Guide:语法。语言的语法,命令行的用法,工具的用法、步骤
- Style Guide:行家都是怎么用的。语言的编码规范,命令行的通用脚本
- Tutorials:例子。通过例子的学习是最好的学习
- Techniques:具体列出一个个常见的问题和解决方法,类似于FAQ,也可以理解为类似设计模式的东西
- Encoding:具体的技术细节,背后的设计思想,等等深入的东西
- API Reference:参考手册吧
- Add-ons:更多资源的链接,主要是外部资源,借助他人之力吗
这是一个很好的步步深入的过程。有些过程还是记住比较好,遇到问题可以直接有条不紊的上手,不必忍受提笔忘字的尴尬。这不只是写文档的思路,也是学习新技术,阅读他人文档的思路。
对于只有口头协议的怎么办呢?口头的是可以反悔的,口头的也代表灵活和多种可能性。这时其实也是协商的双方没有真正的向好,不然可以很轻松的落到书面上,没能固化下来肯定是还有没想清楚的地方。
可以借鉴下苹果的经验,苹果是很注重“原型”的。很多时候,员工花很大的力气建立一个原型,就是为了让jobs否认它。这种生来就是为了被彻底否认的原型都尤其价值,何况有可能被选上的。其实,很多时候,只有当很多的原型摆在面前时,我们才真正知道想要的是什么,然后很可能时多个原型的组合才是最后的产品。就凭这个,就要在心理记住这种情况,放心大胆的去构建多个模型。