提交代码时,详细准确的 comments,能不能让一个项目在多次换人之后依然不烂,可控.

[sunnysign]

我在想一个问题:
如果我们提交代码的时候把所涉及的 bug 或需求的来龙去脉,修改情况,提交文件数量和说明.....等等很多信息都说的十分清楚.

那么在这个项目换了几次人后,能否避免出现积重难返最后无法维护的状况.

仅通过这种方式能不能有效避免日久项目维护困难的问题.

大家谁还有更好的办法,欢迎讨论..

[overflow]

从来没有听说能单单通过管理 commit message 达到项目管理目的的。

[ming2281]

如果遇到猪队友,任你做得怎么好...

[joyeblue]

给几条可行建议（以前我们组就是这样实行的）：
1. 提交时必须写详细说明，长度少于50字不能提交
2. 在发布之前必须做代码 review, review代码需附上需求或者bug单,另外要对修改代码做简短说明
3. 发布前需要提交发布申请，包括需求，或者bug单，代码review通过邮件，测试报告等
4. leader或者总监回复发布申请后，才可进行正式发布

以上基本可以解决lz提出的问题。

但lz真是要把流程做的这么长这么复杂么。

[sunnysign]

@overflow 我觉得comments对于coder来说最直观，反正我很不愿意去翻文档或jira去找修改历史。

[sunnysign]

@ming2281 假设队友中没有猪，或者说项目经理对所有comments都有审核，保证其清楚 正确

[overflow]

@sunnysign 那是你没做过项目管理的原因。完全是小白。

[sunnysign]

@joyeblue 很nice 我觉得这不长 也不麻烦。其实这就是规则，只是新加入的同学需要学习规则。还有个难点就是如何保证所有人都能认真的，富有工匠精神的完成每一次提交。

[randyzhao]

我们现在用的方法:
git commit 里必须包含 reviewboard 的 reviewid 和 bugzillia 的 bugid.
用 hook 去处理.
比如: 缺少 reviewid 或 bugid
又比如: reviewid 对应的 review 没有被 ship.

所有的 commits 都能跟踪到 reviewboard 和 bugzillia.

PS. feature branch 我们是没有 hook 的, 但是 merge 到主分支的时候, 会有要求.

[GuangXiN]

解决代码可读性问题的方法基本上只能靠CodeReview。
CodeReview常常被项目赶工而忽视。我以前公司的要求是CodeReview在代码提交测试前进行，没有Review的代码不能提测。程序员在估时间的时候就要估进去Review的时间，如果delay了就自己负责。

[merlinran]

日清原则，保持当下干净，别管什么历史，除非某段代码是为了某个bug的workaround。

code review顶顶重要，没有之一。