一个臃肿的老项目,强制 CODE REVIEW 没有按照规定执行 不能提交代码，团队成员强烈反弹抱怨
pence2019 · 2019-12-04 18:07:30 +08:00 · 5820 次点击这是一个创建于 1817 天前的主题，其中的信息可能已经有所发展或是发生改变。
作为 top leader 安排 我是执行者。
要求 所有路过的方法增加方法 Java 注释
iBatis 方法 加注释
类加注释
一个老员工强烈反弹 情绪化 说 我不提交代码了，浪费多少时间 等等等。。。。
要求 所有路过的方法增加方法 Java 注释
iBatis 方法 加注释
类加注释
一个老员工强烈反弹 情绪化 说 我不提交代码了，浪费多少时间 等等等。。。。
 |
1
woodensail 2019-12-04 18:14:15 +08:00
对于老项目，一般原则是保持原有风格，尽量少动，同时新增代码也要尽量贴近原有风格。要不然一个项目经手几回就乱成一团糟了。
当然要是想当做一个长期项目来做，建议重构，不仅仅是代码风格，连项目架构一起按自己想要的方式来调。 |
 |
2
pence2019 OP @woodensail 原有风格是 java 类 和方法 代码没有注释 iBatis 没有注释，那我们也要按照原风格走,
现在就是一个焦油坑 没有碰，但是 top leader 不懂技术 把这个作为长期项目对待， 你公司有 code review 吗? |
 |
3
KentY 2019-12-04 18:18:47 +08:00
所有路过的方法... 什么叫"路过"的方法?
如果是指所有方法, 强制所有方法都加 javadoc 是不明智的. |
|
4
woodensail 2019-12-04 18:20:26 +08:00
@pence2019 有，但是看具体项目，这边 code review 的第一追求是减少无用改动，其次才是代码风格。特别是对于老项目，不允许在不经测试的情况下私自改动。
实在忍不了就提重构，自己重新做，测试重新测。 |
 |
6
Justin13 2019-12-04 18:20:51 +08:00 via Android  1
加点注释就不行了?
我们这还要补 Spec,写 Requirement,本来的 JS 转 TS，漏的单元测试要补上。 |
|
7
KentY 2019-12-04 18:21:52 +08:00
|
 |
8
eGlhb2Jhb2Jhbw 2019-12-04 18:21:53 +08:00 2
不愿意可以，但是也要给个合理的理由啊，什么叫浪费时间？公司给他发的工资难道不就是买他时间的么，公司都没嫌他浪费时间，他自己先急了。不想一起玩就滚蛋，最烦这种事精了。
|
|
9
pence2019 OP @woodensail 目标:增加 注释 优化代码结构 提高方法重用性 多使用设计模式
|
|
10
woodensail 2019-12-04 18:24:53 +08:00
@pence2019 注释基本上强制推行没问题，写注释基本不会翻车。
但是后面几个就算是重构级别的了，动到哪儿了都得全面回归测试。事前也得做全面的分析，确定影响范围。 |
 |
11
bxb100 2019-12-04 18:25:54 +08:00
估计没算进工时
|
|
12
woodensail 2019-12-04 18:31:05 +08:00
其实我感觉楼主的公司就是想做重构又没时间，只好搞这种渐进式重构。但是渐进式重构需要对项目有很强的掌控能力，要不然各种翻车。比如遗漏影响范围导致依赖方挂了，忽略特殊场景导致部分业务场景异常等。
|
 |
13
hehheh 2019-12-04 18:31:14 +08:00
算进工时里就好了，注释也算代码量。
|
 |
14
winterbells 2019-12-04 18:33:36 +08:00 via Android 1
我之前也想对这个项目做各种更新
后来发现自己太天真了。。 1、你提出来的，那就你来改吧 2、你改的，出问题找你 折腾了我一星期，现在谁爱干嘛干嘛去，我不会多说一句话。 |
 |
15
zarte 2019-12-04 18:33:56 +08:00 1
给时间都好说，应该是只算开发时间，然后做这些的时间加上就要义务加班了。
|
|
16
pence2019 OP @KentY 没有注释 焦油坑呀
@eGlhb2Jhb2Jhbw 一个女技术组长的情绪化反应，我表示很无语，你是技术组长呀，。。。可能人家就是想当农民 @woodensail 现在大家的场景就是修复 BUG 的时候 增加相关方法和类的注释 这都不行。 @hehheh 一个女技术组长的情绪化反应，我表示很无语，你是技术组长呀，。。。可能人家就是想当农民。 @bxb100 和工时没有关系，只是情绪化反应 |
|
17
pence2019 OP @winterbells 不负责任的态度，你每天给你白发工资吧，你怎么提升，？？？
|
|
19
woodensail 2019-12-04 18:42:37 +08:00
@pence2019 加注释都不肯就比较麻烦了，没有威信的后果(doge)
|
|
20
zarte 2019-12-04 18:44:50 +08:00
@pence2019 你有跟他们说这个的时间可以算进工时么？可以根据实际情况加？你没说的话换我也不会提，等下被怼加个注释要这么久时间？
|
 |
21
beastk 2019-12-04 18:45:38 +08:00 via iPhone
维护屎山的即视感
|
|
22
winterbells 2019-12-04 18:54:18 +08:00 via Android 3
@pence2019 这种口气好像当老板了一样，你白发我工资了？
还提升？你能力是有多差要从这种远古代码里学习 |
|
23
KentY 2019-12-04 20:31:25 +08:00
@pence2019
我还是重复, 强制所有 method 加 javadoc 是不明智的. 当然, 如果你们的产品是个 library, 那么至少所有的 public methods 都应该有 javadoc 我猜大概率你们的也是 enterprise application 这种东西, 那么 javadoc 就是给自己人看的, 尤其是以前的程序, 自己人再修改过程中也就体会了哪些比较难理解, 读懂加个注释为什么这些代码这么做, 就好了. 至于那些很明显的就不用再写 javadoc. 作为一个好的项目, 除了代码精妙以外, 没有没用的注释, 而且存在的注释都有存在的价值, 也是个特征. 举个例子, vim 编辑器的代码就不是好代码. |
 |
24
wccc 2019-12-04 20:42:42 +08:00
错误注释 最为致命
|
 |
25
daozhihun 2019-12-04 21:29:56 +08:00
每个方法都强制加注释没有必要，很容易搞出“凑数”的注释。
比如一个方法名是 getUserById，你要加详细的注释，就是写按 id 获取用户，返回值：用户，参数：id，这种写了一点用也没有。 个人建议是比较复杂的方法才加，有调用规范之类的也应该加，不是所有的都无脑加。 |
 |
26
akira 2019-12-04 21:44:26 +08:00
老项目别折腾了啊。。。没出问题我们都不会去碰的
|
 |
27
Pastsong 2019-12-04 21:47:19 +08:00
强制写注释不如强制命名规范
|
 |
28
719465553 2019-12-04 22:16:47 +08:00 1
作为一个三年在维护一个老项目的说几句，真的没法所有都加，有些逻辑完全不敢改，你看着改了没啥毛病，实际上问题一堆，有些逻辑的意思和你想象的完全不一样
|
 |
29
wangyzj 2019-12-04 23:48:20 +08:00
|
 |
30
jugelizi 2019-12-05 00:11:36 +08:00
彼此彼此
所以后来我放弃了 代码 能跑就行 老板可不管你写的多差 |
 |
31
xsen 2019-12-05 07:19:12 +08:00
简单点吧，就是一些人很闲，就以为所有人都跟他一样闲；不带来额外价值的事情不要作，
什么叫有价值？手下可以带来技术提升，可以减少后期维护工作量，可以带来稳定性与性能 ————lz 说的这个有什么用？屁用都没有。为了注释而注释，为了设计而设计，为了 oo 而 oo 对于老项目， 1. 能不改就不改，风格与已有一致 2. 关键是核心的接口与流程梳理 3. 与其要求所有接口加注释，不如要求逐步、渐进式重构 对大多数接口，只要保证命名规范（函数、参数、变量这些），就已经是足够好的注释 当然，对外接口（子系统或子模块之间）要提供接口文档 |
 |
32
learnshare 2019-12-05 07:39:26 +08:00 via Android 1
老项目动刀子很难，老人动刀子更难
|
 |
33
optional 2019-12-05 08:31:22 +08:00 via Android
哈哈，我们是不允许加注释，方法名必须自注释
|
 |
34
airfling 2019-12-05 08:36:04 +08:00
改动要合理循序渐进的改，你不可能一起把全部的项目都重新加一遍吧
|
 |
35
passerbytiny 2019-12-05 08:57:49 +08:00
@pence2019 自己列目标然后让副手执行；高危目标只列目标不列计划；为了注释而注释：你这领导也许是一个合格的 ZZ 领导，但绝对是一个垃圾的技术领导。再加上，都全员反弹了副手还要到网上找出路（而不是高层），能跑路就抓紧跑路吧。
|
 |
36
laike9m 2019-12-05 09:09:12 +08:00
直接重写（
|
 |
38
cxh116 2019-12-05 09:21:58 +08:00
注释有毛用,要加也是加单元测试.
|
 |
39
llllboy 2019-12-05 09:34:48 +08:00
重构吧
|
 |
40
mazyi 2019-12-05 09:39:50 +08:00
注释不是万能的，甚至大部分的代码应该是自注释的，写了注释没写对反而也是坑人，请问你们 review 的时候会管注释写得对不对么？你们缺少的是测试驱动，请问改了一行代码是需要人测还是跑一套测试代码呢？
|
 |
41
bk201 2019-12-05 09:44:10 +08:00
所以给时间了吗？
|
 |
42
tianshilei1992 2019-12-05 09:55:16 +08:00 1
既然是 tech leader，那个不提交代码的人可以让他滚蛋了…我从来都觉得，为了提高代码质量而做的一些所谓的“浪费时间”的工作长远看起来都不是浪费时间。我以前组的那群毛子都可以因为 feature 实现的不漂亮而 delay release…他们从来都不允许一个代码能 work 就先进去，然后后面再改…
|
|
43
tianshilei1992 2019-12-05 09:57:16 +08:00
@tianshilei1992 *一个代码能 work 但是实现很丑陋
|
 |
44
rockyou12 2019-12-05 10:00:50 +08:00
@tianshilei1992 老项目重构优化了时间花了，公司出钱出成本不？不然优化干嘛，工资从你的嘴炮里出？
|
 |
45
scukmh 2019-12-05 10:10:57 +08:00
首先要把自动化的测试搞起来。
|
|
46
pence2019 OP @scukmh 自动化的测试搞起来 ,现在公司没有测试...........
@rockyou12 乙方公司 多个公司使用这个项目，代码都不懂什么逻辑 @tianshilei1992 UI 和实现都丑陋 you are dream 那群毛子都可以因为 feature 实现的不漂亮而 delay release…他们从来都不允许一个代码能 work 就先进去，然后后面再改 @bk201 给时间了呀 |
 |
48
chaleaochexist 2019-12-05 11:21:24 +08:00
@woodensail 原有项目瞎比写咋办...
|
 |
49
server 2019-12-05 11:41:57 +08:00
这时候，不得买个 251 笔（手动狗头）, 代码是翔是金子 老板不管，top leader 要这个就是 KPI，你当天真心搞代码？
转化 KPI 就完了，锅给离职的同学， |
|
50
woodensail 2019-12-05 12:43:28 +08:00
@chaleaochexist 是时候重构了
|
 |
51
FrankHB 2019-12-06 21:10:40 +08:00
存在清晰的对得上号的设计文档的部分，可以不需要加注释。
如果要重构，预计被重构掉的部分可以不动，先统一整理模块清单，安排重构计划。 剩下的注释按便于维护者和使用者理解为基准，能加多少加多少，力度看着办。 重构的工作量必须计算工时。 不配合的，要求提出替代方案和工作计划，被项目技术负责人和 PM 认可之前搁置计算该项目内的有效工作量；否则，可以自愿调岗。 |
Select Language