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

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

This topic created in 4089 days ago, the information mentioned may be changed or developed.

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

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

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

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

提交

积重难返

项目

10 replies • 2015-03-12 12:42:32 +08:00

overflow

Mar 11, 2015

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

ming2281

Mar 11, 2015

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

joyeblue

Mar 11, 2015

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

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

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

sunnysign

Mar 11, 2015 via iPhone

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

sunnysign

Mar 11, 2015 via iPhone

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

overflow

Mar 11, 2015

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

sunnysign

Mar 11, 2015 via iPhone

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

randyzhao

Mar 11, 2015

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

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

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

GuangXiN

Mar 12, 2015

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

merlinran

Mar 12, 2015 via Android

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

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