用什么样的心态去做开发

一直听闻开发是被不断变化的需求搞死的，不过实际上还没有具体经历过。但是，不知是不是因为我记忆力越来越不好的原因，一直感觉开发过程中一直不能做到有据可循。讨论的结果大都是口头协议或者草稿的形式，好不容易写出一个相对好些的文档，又束之高阁了，开发、维护的过程中很少去看，更不用说去更新了。

 

今天在看protobuf的文档的时候，突然感觉，其实写文档的思路要和新学习一个东西的思路使一致的。很多人只想到这一层，但是很少去想这在种“新学习”的思路具体是什么思路呢。protobuf的目录结构给了一个很好的答案：

1. Overview：是什么，能干什么，解决什么问题
2. Language Guide：语法。语言的语法，命令行的用法，工具的用法、步骤
3. Style Guide：行家都是怎么用的。语言的编码规范，命令行的通用脚本
4. Tutorials：例子。通过例子的学习是最好的学习
5. Techniques：具体列出一个个常见的问题和解决方法，类似于FAQ，也可以理解为类似设计模式的东西
6. Encoding：具体的技术细节，背后的设计思想，等等深入的东西
7. API Reference：参考手册吧
8. Add-ons：更多资源的链接，主要是外部资源，借助他人之力吗

这是一个很好的步步深入的过程。有些过程还是记住比较好，遇到问题可以直接有条不紊的上手，不必忍受提笔忘字的尴尬。这不只是写文档的思路，也是学习新技术，阅读他人文档的思路。

 

对于只有口头协议的怎么办呢？口头的是可以反悔的，口头的也代表灵活和多种可能性。这时其实也是协商的双方没有真正的向好，不然可以很轻松的落到书面上，没能固化下来肯定是还有没想清楚的地方。

可以借鉴下苹果的经验，苹果是很注重“原型”的。很多时候，员工花很大的力气建立一个原型，就是为了让jobs否认它。这种生来就是为了被彻底否认的原型都尤其价值，何况有可能被选上的。其实，很多时候，只有当很多的原型摆在面前时，我们才真正知道想要的是什么，然后很可能时多个原型的组合才是最后的产品。就凭这个，就要在心理记住这种情况，放心大胆的去构建多个模型。