遇上一个对Code Quality 超级执着的组员，快被逼疯了，经验

遇上贵人了……两三年回头看吧

有好处，但并不是都是有帮助的idea，耗时耗力。对付这种人，就是把他的话都留下记录，或者让他留下记录。他很容易改变主意的，要按照他的书面意思去改，没书面的意见，可以放放。他也许以此刷存在感的。要纠别人的错太容易了，工作这东西，做的越多漏洞越多，就看有没有人想抓

公司让你提高productivity尽快出东西，可没有批准你降低标准啊，不要拿法律和常理当挡箭牌 （狗头）

匿名用户 发表于 2023-03-18 13:04:14
哈哈哈 公司考核改革了 这种trivial的code review用处不大哦 除非老板特意算credit 尤其这个组的老板不会因为这种code review多算这个senior的credit的

您是该senior本人？

微信用户_212ja 发表于 2023-03-18 11:36:18
同意！职场新人应该专注于发展一个好的工作习惯而不是图一时的工作快
好的工作习惯会帮你走的更远！

当大环境本身就有毒时，好的工作习惯只会让新人越来越confused。况且，这种所谓的对code quality执着真的是好习惯？到底什么是好的code quality？是容易看懂容易维护的，还是符合clean code这本书的要求的？

idealmaster 发表于 2023-03-18 11:31:34
看最新的评论终于正常点了，只能说因为软件行业门槛越来越低，来钱又快又相对轻松，导致一大批本身对CS毫无兴趣，单纯只是为了赚钱轻松的人涌进这个行业。这点本身无可厚非，有钱为什么不赚，但这样的动机也从决定

科班出身的大神们，如果你们真的觉得自己水平过硬，对CS又有兴趣，那就麻烦多提一些有真正的business impact的idea，为公司多打造几款好的产品，为你们的客户创造更多价值。就算没这个本事，也多花点时间为组里争取更多budget，为工程师们fight back那些PM提出的不合理的要求。再再不济，也多参加参加junior们的doc review，在架构和软件设计方面多提些有用的意见，而不是执着于用豆腐雕花的技术，在一个没有确切标准的code quality上为难自己人。只要代码命名规范，逻辑清晰，测试完整，基本就可以了，别扯什么狗屁重构，封装和设计模式。一个class上面封装8层你开心啊？真有洁癖的，要么引入jacoco之类的代码审查工具，自动化审查流程，build的时候不符合一定规范的代码就build不了。要么晚上自己辛苦点加加班，自己把代码重构成自己想要的样子。有些人自己写代码的时候乱来，到junior加代码时keep the highest standard，要求人家这个clean那个重构。你们学CS的初心想必是用技术让世界变得更美好，而不是把技术作为行业壁垒，让你们把握话语权的工具吧。

donnice 发表于 2023-03-18 16:59:06
科班出身的大神们，如果你们真的觉得自己水平过硬，对CS又有兴趣，那就麻烦多提一些有真正的business impact的idea，为公司多打造几款好的产品，为你们的客户创造更多价值。就算没这个本事，也

不要怨念这么大啊 设计模式以及你说的什么封装的很多情况就是解决很多可扩展性的问题啊 哪怕最低的sde1升2你都要有例子证明自己代码质量高啊 追求代码质量跟business impact不冲突啊 而且本来business impact idea就要靠学商科学市场的pm来drive 程序员最重要的工作就是保正架构好 代码质量好啊

匿名用户 发表于 2023-3-19 08:06
不要怨念这么大啊 设计模式以及你说的什么封装的很多情况就是解决很多可扩展性的问题啊 哪怕最低的sde1升2 ...

关键是代码质量到底有没有标准？是clean code那本书里的吗？是自动代码审查能过吗？还是code reviewer说啥是啥呢？

我亲历过一个对code quality很高的组，结果一个很简单的应用，愣是被整成了百八十个文件，重构来重构去，设计模式一层套一层，你套我他套你，层层叠叠，追查一个小的UI bug要走十几个文件，deliver又慢，reorg后director看着这个进度气死，要求move fast，然后就省心了。

都说没有clean code会造成屎山，我想说clean的code才会真正造成屎山，而且是没地方继续拉的那种。

我不是支持那些乱写的，命名不清，依赖混乱，没有测试，啥都堆在一个文件里。在我看来，好的代码质量只要（有）做到2点就能保证：有充分的注释和详细的文档。有些人这两点不抓，偏偏在设计模式上大做文章，这不是**是什么？

“代码质量”和business impact确实不冲突，但如果此人一直把时间花在和组员纠结代码质量，而且还是错误的代码质量上的话，除非这人一天工作25个小时，不然想必其他地方是没有长进的。以及纠正你一个我认为错误的观念，business impact是由程序员drive的，尤其是高级程序员。PM最大的作用是把控项目进度，而只有程序员才真正了解自己能做什么，以及应该做什么。这不需要商学院的训练就应该能做到，事实上商学院也训练不了这方面的能力。

donnice 发表于 2023-03-18 16:40:07
当大环境本身就有毒时，好的工作习惯只会让新人越来越confused。况且，这种所谓的对code quality执着真的是好习惯？到底什么是好的code quality？是容易看懂容易维护的，还是符合c

说真的你说的新人更confused的这个gap要怪只能怪美国只面刷题 那些前人总结下来的好的设计要么是可以让扩展/变更代码更容易 要么是避免你犯错（例如null，或者要改三个地方最后只改了两个导致不一致） 稍微花两周看一看相关的例子就可以了 退一万步 那么多前人总结的best practice为什么不follow呢？

donnice 发表于 2023-03-18 17:17:23
关键是代码质量到底有没有标准？是clean code那本书里的吗？是自动代码审查能过吗？还是code reviewer说啥是啥呢？

我亲历过一个对code quality很高的组，结果一个很简单

设计模式跟文档也不矛盾啊 设计模式写了以后加新功能修改功能都方便很多 例如写个10个if else还是改成了策略模式 差别还是打很多吧 而且你不要举极端例子 我不了解你那个项目 over engineering肯定不对 但是用几个设计模式算什么over engineering 你说的时间不够的问题是tech lead的责任 他们必须push back说需要更多的时间来保证项目的代码质量以后更方便维护扩展