大家对文档什么看法？

assiss

原帖由 flw 于 2007-4-25 15:54 发表
众位牛人不要再高来高去了好不好，讨论点儿具体的吧。
比如我知道有个公司，开发人员不能随便往 svn 上面 check-in 东西，非要写什么“修改请求单”，一并附上本地工作副本和基准代码之间的 diff，再找至少两个工 ...

够严谨……太牛了……

我用SVN，一天就能更新几十个版本号……你所说的公司，估计一天也就一个。

flw

原帖由 assiss 于 2007-4-25 16:27 发表

够严谨……太牛了……

我用SVN，一天就能更新几十个版本号……你所说的公司，估计一天也就一个。

一天一个算是快的。
他们公司北京和美国都有研发人员，
北京的研发人员写的代码，要有至少一位美国工程师 review 才行，
而中国和美国是有时差的……
也就是说，两天一个就算没偷懒。

flw

大家认为像这个公司的“工程修改请求单”这种文档到底有没有必要？
当然指的是日常研发，对待已发布或者快要发布的产品自然要小心一些。

MMMIX

原帖由 flw 于 2007-4-25 15:54 发表
众位牛人不要再高来高去了好不好，讨论点儿具体的吧。
比如我知道有个公司，开发人员不能随便往 svn 上面 check-in 东西，非要写什么“修改请求单”，一并附上本地工作副本和基准代码之间的 diff，再找至少两个工 ...

代码 review 是必要的，但这个公司做的好像有点走火入魔。一些简单的修改，例如说拼写错误的修改完全可以直接 check-in。如果三不管的这样搞，那么最后这一套要么成为走过场，要么严重影响效率，浪费资源。

converse

好的写文档习惯和好的命名习惯,好的注释习惯一样的重要.

flw

原帖由 MMMIX 于 2007-4-25 16:36 发表

代码 review 是必要的，但这个公司做的好像有点走火入魔。一些简单的修改，例如说拼写错误的修改完全可以直接 check-in。如果三不管的这样搞，那么最后这一套要么成为走过场，要么严重影响效率，浪费资源。

所以这里面就涉及到一个程序员的自律和公司的硬性制度两者的适用界限的问题：
到底什么样的修改可以走简单流程、什么样的修改要走复杂流程？这个界限如何界定？再或者不明确界定、依赖程序员的自律？

gnap

原帖由 flw 于 2007-4-25 16:30 发表
大家认为像这个公司的“工程修改请求单”这种文档到底有没有必要？
当然指的是日常研发，对待已发布或者快要发布的产品自然要小心一些。

对日志进行严格的评估不就行了？

redac

原帖由 gnap 于 2007-4-25 16:45 发表


对日志进行严格的评估不就行了？

不要小看管理,协调成本

redac

说个更搞笑的, 我在一家公司做一个项目时, 领导为了体现对"文档"的重视, 在一次
设计文档评审会上找到我画的几个流程图中画有一些错误, 结果是要求我周六加班改
这点小错误(事实上周五下班用半个小时就可搞定)

加班 写(or 改) 文档!!!

我不是不重视文档, 而是认为在当前环境下, 有远比文档重要的东西我们都不去重视,
非要死专牛脚尖就搞笑了

redac

还有最核心的一点:

目前来看好象领导似乎想以"文档"代替人与人之间的交流, 隐藏人与人之间交流的高度复杂,模糊性, "文档"不是工具, 反而"人"成了工具了

这才是最糟糕的, 我想这也是那些众多中国破公司之所以狂过cmm, cmmi, 而公司管理实际上没有什么实际进展的根本原因所在吧!