一个臃肿的老项目,强制 CODE REVIEW 没有按照规定执行 不能提交代码，团队成员强烈反弹抱怨

[pence2019]

作为 top leader 安排 我是执行者。

要求 所有路过的方法增加方法 Java 注释
iBatis 方法 加注释
类加注释

一个老员工强烈反弹 情绪化 说 我不提交代码了，浪费多少时间 等等等。。。。

[bk201]

所以给时间了吗？

[tianshilei1992]

既然是 tech leader，那个不提交代码的人可以让他滚蛋了…我从来都觉得，为了提高代码质量而做的一些所谓的“浪费时间”的工作长远看起来都不是浪费时间。我以前组的那群毛子都可以因为 feature 实现的不漂亮而 delay release…他们从来都不允许一个代码能 work 就先进去，然后后面再改…

[tianshilei1992]

@tianshilei1992 *一个代码能 work 但是实现很丑陋

[rockyou12]

@tianshilei1992 老项目重构优化了时间花了，公司出钱出成本不？不然优化干嘛，工资从你的嘴炮里出？

[scukmh]

首先要把自动化的测试搞起来。

[pence2019]

@scukmh 自动化的测试搞起来 ,现在公司没有测试...........
@rockyou12 乙方公司 多个公司使用这个项目，代码都不懂什么逻辑
@tianshilei1992 UI 和实现都丑陋 you are dream 那群毛子都可以因为 feature 实现的不漂亮而 delay release…他们从来都不允许一个代码能 work 就先进去，然后后面再改
@bk201 给时间了呀

[pence2019]

@Justin13 在米国 ？ 什么公司?

[chaleaochexist]

@woodensail 原有项目瞎比写咋办...

[server]

这时候，不得买个 251 笔（手动狗头）, 代码是翔是金子 老板不管，top leader 要这个就是 KPI，你当天真心搞代码？
转化 KPI 就完了，锅给离职的同学，

[woodensail]

@chaleaochexist 是时候重构了

[FrankHB]

存在清晰的对得上号的设计文档的部分，可以不需要加注释。
如果要重构，预计被重构掉的部分可以不动，先统一整理模块清单，安排重构计划。
剩下的注释按便于维护者和使用者理解为基准，能加多少加多少，力度看着办。
重构的工作量必须计算工时。
不配合的，要求提出替代方案和工作计划，被项目技术负责人和 PM 认可之前搁置计算该项目内的有效工作量；否则，可以自愿调岗。

[FrankHB]

@pence2019 ……没测试。。。那就先写测试对付其中看起来比较靠谱的部分当 KPI 吧，顺便可以辅助逆向出文档了。