- 主题:用代码做详细设计和文档
只有需求和概要设计文档，甚至这也没有，只是口头讨论了功能和技术路线和方式；
先实现个基础原型功能，然后再在这个代码基础上讨论，提出完善意见，增加功能，修改特性等，直到完成。
以上方式好处有：
1. 写文档很烦人，大部分coder都不喜欢写文档，往往写文档时间比开发更费精力和时间；
2. 写文档是设计过程，减少代码开发问题和无用功，但实际是写文档工作比用代码来设计和验证工作还大；
2. 就算写出来文档，还得学习了解和讨论，然后再去落地，gap过程照样不少；
3. 越细的文档往往不能一步到位，后面也得各种修改，到后来都懒得改，最后实际代码跟文档差异很大，没了参考价值；
4. 很多实际情况是，看半天文档，还不知所以然，翻开代码说两句就清楚了；
坏处是：
代码再也没有文档了，如果出现人力断档，那么这块代码接手和维护很麻烦；
--
FROM 107.182.187.*
小公司或者小的项目为了快速上线问题不大，但是大的项目或者大的公司需要多个小组配合，还是要有详细规范的文档的。
另外，文档也是又标准的又规范的，也是需要学习的，随便画个脑图列个几条那是不行的。。。
【 在 wjhtingerx 的大作中提到: 】
: 只有需求和概要设计文档，甚至这也没有，只是口头讨论了功能和技术路线和方式；
: 先实现个基础原型功能，然后再在这个代码基础上讨论，提出完善意见，增加功能，修改特性等，直到完成。
: 以上方式好处有：
: ...................
--
FROM 36.161.235.*
基于API声明和规格化注释自动生成文档这套已经挺成熟了
API/数据规格之外的详细文档……实话说意义不大
【 在 foxknox 的大作中提到: 】
: 小公司或者小的项目为了快速上线问题不大，但是大的项目或者大的公司需要多个小组配合，还是要有详细规范的文档的。
: 另外，文档也是又标准的又规范的，也是需要学习的，随便画个脑图列个几条那是不行的。。。
--
FROM 61.170.180.*
【 在 oldwatch 的大作中提到: 】
: 基于API声明和规格化注释自动生成文档这套已经挺成熟了
~~这个现在用啥工具了？还是docygen吗？
: API/数据规格之外的详细文档……实话说意义不大
:
--
FROM 107.182.187.*
CPP圈子这个就真不熟了……
【 在 wjhtingerx 的大作中提到: 】
: ~~这个现在用啥工具了？还是docygen吗？
--
FROM 61.170.180.*
不是不愿意写文档
是不愿意不给时间 不给钱的白票文档
想要两边都满意，感觉没希望了
项目管理和实际实施已经不是一波人，大家各玩各的就行的。记得结帐就行
【 在 wjhtingerx 的大作中提到: 】
: 只有需求和概要设计文档，甚至这也没有，只是口头讨论了功能和技术路线和方式；
: 先实现个基础原型功能，然后再在这个代码基础上讨论，提出完善意见，增加功能，修改特性等，直到完成。
: 以上方式好处有：
: ...................
--
FROM 111.204.200.*
re
如果单独的人只负责写文档，我觉得挺好的。让程序员负责程序最终出结果。还不给时间，还让程序员写，还说文档很重要，就有点不要脸了。程序员写完文档还不拿文档当工作成功，最终还是要程序。那干嘛还要去写？
【 在 hothail 的大作中提到: 】
: 不是不愿意写文档
: 是不愿意不给时间 不给钱的白票文档
: 想要两边都满意，感觉没希望了
: ...................
--
FROM 117.133.52.*
人脑在思考问题的时候，是存在大量的关于“意图”的信息的，而转变成代码之后，这部分“意图”的信息就丢失了，所以，编码是一个“有损”的转换过程，当其他程序员接受这部分代码时，实际上做的事情是根据代码“反向推断”出原作者的“意图”，这个从代码“复原”原作者“意图”的过程非常取决于第二个程序员的能力，如果后者能力比较差，那么大部分的“意图”都会丢失，而且是永久性地丢失。
令人遗憾的是，这种“意图”只能以文档和注释的方式存在，代码能用来“实现”“意图”，但无法“表达”“意图”。
【 在 wjhtingerx 的大作中提到: 】
: 只有需求和概要设计文档，甚至这也没有，只是口头讨论了功能和技术路线和方式；
: 先实现个基础原型功能，然后再在这个代码基础上讨论，提出完善意见，增加功能，修改特性等，直到完成。
: 以上方式好处有：
: ...................
--
FROM 175.164.22.*
这就是关键点所在啊。
实际上那个思路和意图更重要更值钱。但是这部分没有付钱啊，所以大部分人就是写个代码implementation。鱼和渔的关系。
【 在 heideggerr 的大作中提到: 】
: 人脑在思考问题的时候，是存在大量的关于“意图”的信息的，而转变成代码之后，这部分“意图”的信息就丢失了，所以，编码是一个“有损”的转换过程，当其他程序员接受这部分代码时，实际上做的事情是根据代码“反向推断”出原作者的“意图”，这个从代码“复原”原作者“意图”的过程非常取决于第二个程序员的能力，如果后者能力比较差，那么大部分的“意图”都会丢失，而且是永久性地丢失。
: 令人遗憾的是，这种“意图”只能以文档和注释的方式存在，代码能用来“实现”“意图”，但无法“表达”“意图”。
:
--
FROM 222.131.243.*
什么叫做“没付钱”？ 公司给你的薪水就是包括 提交代码的同时提交文档的啊！哪个公司会说他们只为代码提供付费而对于文档不提供payment的？
【 在 RaZRo 的大作中提到: 】
: 这就是关键点所在啊。
: 实际上那个思路和意图更重要更值钱。但是这部分没有付钱啊，所以大部分人就是写个代码implementation。鱼和渔的关系。
:
--
FROM 175.164.22.*