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

[pence2019]

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

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

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

[beastk]

维护屎山的即视感

[winterbells]

@pence2019 这种口气好像当老板了一样，你白发我工资了？
还提升？你能力是有多差要从这种远古代码里学习

[KentY]

@pence2019

我还是重复, 强制所有 method 加 javadoc 是不明智的.
当然, 如果你们的产品是个 library, 那么至少所有的 public methods 都应该有 javadoc
我猜大概率你们的也是 enterprise application 这种东西, 那么 javadoc 就是给自己人看的, 尤其是以前的程序, 自己人再修改过程中也就体会了哪些比较难理解, 读懂加个注释为什么这些代码这么做, 就好了. 至于那些很明显的就不用再写 javadoc. 作为一个好的项目, 除了代码精妙以外, 没有没用的注释, 而且存在的注释都有存在的价值, 也是个特征.
举个例子, vim 编辑器的代码就不是好代码.

[wccc]

错误注释 最为致命

[daozhihun]

每个方法都强制加注释没有必要，很容易搞出“凑数”的注释。
比如一个方法名是 getUserById，你要加详细的注释，就是写按 id 获取用户，返回值：用户，参数：id，这种写了一点用也没有。
个人建议是比较复杂的方法才加，有调用规范之类的也应该加，不是所有的都无脑加。

[akira]

老项目别折腾了啊。。。没出问题我们都不会去碰的

[Pastsong]

强制写注释不如强制命名规范

[719465553]

作为一个三年在维护一个老项目的说几句，真的没法所有都加，有些逻辑完全不敢改，你看着改了没啥毛病，实际上问题一堆，有些逻辑的意思和你想象的完全不一样

[wangyzj]


[jugelizi]

彼此彼此
所以后来我放弃了
代码 能跑就行 老板可不管你写的多差

[xsen]

简单点吧，就是一些人很闲，就以为所有人都跟他一样闲；不带来额外价值的事情不要作，
什么叫有价值？手下可以带来技术提升，可以减少后期维护工作量，可以带来稳定性与性能

————lz 说的这个有什么用？屁用都没有。为了注释而注释，为了设计而设计，为了 oo 而 oo

对于老项目，
1. 能不改就不改，风格与已有一致
2. 关键是核心的接口与流程梳理

3. 与其要求所有接口加注释，不如要求逐步、渐进式重构
对大多数接口，只要保证命名规范（函数、参数、变量这些），就已经是足够好的注释
当然，对外接口（子系统或子模块之间）要提供接口文档

[learnshare]

老项目动刀子很难，老人动刀子更难

[optional]

哈哈，我们是不允许加注释，方法名必须自注释

[airfling]

改动要合理循序渐进的改，你不可能一起把全部的项目都重新加一遍吧

[passerbytiny]

@pence2019 自己列目标然后让副手执行；高危目标只列目标不列计划；为了注释而注释：你这领导也许是一个合格的 ZZ 领导，但绝对是一个垃圾的技术领导。再加上，都全员反弹了副手还要到网上找出路（而不是高层），能跑路就抓紧跑路吧。

[laike9m]

直接重写（

[abcdexx]

@pence2019 真不明白为什么安排不懂技术的管技术部，直接管技术部老大不就好了？

[cxh116]

注释有毛用,要加也是加单元测试.

[llllboy]

重构吧

[mazyi]

注释不是万能的，甚至大部分的代码应该是自注释的，写了注释没写对反而也是坑人，请问你们 review 的时候会管注释写得对不对么？你们缺少的是测试驱动，请问改了一行代码是需要人测还是跑一套测试代码呢？