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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 3581 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

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

提交

积重难返

项目

10 条回复 • 2015-03-12 12:42:32 +08:00

overflow

2015-03-11 18:52:25 +08:00

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

ming2281

2015-03-11 18:53:57 +08:00

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

joyeblue

2015-03-11 19:06:06 +08:00

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

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

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

sunnysign

2015-03-11 19:06:49 +08:00 via iPhone

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

sunnysign

2015-03-11 19:07:58 +08:00 via iPhone

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

overflow

2015-03-11 19:08:51 +08:00

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

sunnysign

2015-03-11 19:13:08 +08:00 via iPhone

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

randyzhao

2015-03-11 19:16:43 +08:00

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

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

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

GuangXiN

2015-03-12 11:01:14 +08:00

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

merlinran

2015-03-12 12:42:32 +08:00 via Android

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

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