只有需求和概要设计文档，甚至这也没有，只是口头讨论了功能和技术路线和方式；
先实现个基础原型功能，然后再在这个代码基础上讨论，提出完善意见，增加功能，修改特性等，直到完成。

以上方式好处有：
1. 写文档很烦人，大部分coder都不喜欢写文档，往往写文档时间比开发更费精力和时间；
2. 写文档是设计过程，减少代码开发问题和无用功，但实际是写文档工作比用代码来设计和验证工作还大；
2. 就算写出来文档，还得学习了解和讨论，然后再去落地，gap过程照样不少；
3. 越细的文档往往不能一步到位，后面也得各种修改，到后来都懒得改，最后实际代码跟文档差异很大，没了参考价值；
4. 很多实际情况是，看半天文档，还不知所以然，翻开代码说两句就清楚了；

坏处是：
代码再也没有文档了，如果出现人力断档，那么这块代码接手和维护很麻烦；
--
FROM 107.182.187.*