文章来源：https://www.codelast.com/

我前公司的CTO是从Google跳槽出来的，我记得TA曾经在一次会议上聊到TA刚进Google的那段时间，写了一些代码，提交给上级review的时候，对方在一些无关代码逻辑正确性的“小事”上纠缠不休，不断地让TA修改代码再重新提交review，TA当时就很不理解为什么要搞那么严格，但多年过去以后TA终于感慨Google那段经历带给了TA一个好习惯，对人生是一笔宝贵财富。
但是换成现实世界，有几个公司有这底气这样做？
对不起，逼得太紧的话，骄傲的程序员们会嫌你太烦，然后离职跳槽到另一家。
文章来源：https://www.codelast.com/
人情世故，同事关系，你好意思当面diss天天坐在你旁边的那些人吗？
“你这一行缩进多了两个空格”
“你这里应该用驼峰形式命名变量，不应该用下划线形式”
“你这里有两个函数一模一样，应该合并成一个”
“你这里有一句多余的代码没作用，可以删掉”
“你这里是给别人埋坑，你离职了别人怎么办”
就这些看上去微不足道却又乱七八糟的问题，没几个程序员会真的关心，通常大家关心的是：只要功能达成，其他一切都不重要。
文章来源：https://www.codelast.com/
根据我这么多年的观察，团队或者公司里的code review已经越来越没有人仔细去看了，尽管我不能充分了解全部情况，但就我周围的人来说，确实如此。
每个人对自己写的代码负责，出了问题开发者自己担就行。审核代码的人基本只起到一个merge代码的作用，在80%以上的场合下失去了“review”的功能。
code review没有KPI，哪怕你一天review十份代码，也无法改变你在领导眼里“什么事都没做”的印象。所以，也越来越没有人愿意花时间去用心review，都是蜻蜓点水扫一眼，只要天不塌下来，没有把JAVA代码写成Python语法，那都不叫个事！
如果每个人几乎都习惯于这样做，你就会发现，你若真的花时间去认真纠正code committer的各种大小问题，那真的会引得“天怒人怨”，让你再也无法在公司立足。
文章来源：https://www.codelast.com/
这让我又想起来一件事：我曾经就一个明显有缺陷的问题向一位前同事提过一个代码改进意见，结果TA十分抗拒、十分不愉快，因为TA觉得TA当时还在职，出问题也是TA去处理，或许我向TA提出意见的行为被TA认为是向TA发难。事情的结局就是我对TA说：你不愿改就算了吧。
我还记得多年以前，当我一个前同事离职并且把一个项目留给我的时候，我就知道我根本“接不下来”，因为其代码不仅几乎零注释，而且结构非常乱，而且毫无编码规范可言。举个例子，里面的多个目录下有多份非常相似的代码，但逻辑又稍有区别，如果不到生产环境去找，根本不知道代码库里的哪一份代码是有用的、哪一份是废弃的。
文章来源：https://www.codelast.com/
想当年，百度内部使用的gcc由于错综复杂的依赖关系被锁死在了3.4.5版本，一堆高管尝试推动升级都以失败告终，直到陆奇博士去百度当了总裁，以铁腕作风下线了3.4.5的gcc，才让gcc升级不再是镜花水月。
人微言轻，我无法改变任何现状，权当发牢骚了。毕竟，想让一个公司的程序员全部遵循严格的编码规则，比让百度升级gcc版本还要不现实。
又或者，我才是应该被社会淘汰的那部分人吧，毕竟99%的人几乎都不会主动遵守规则，而我又太执念于它。
文章来源：https://www.codelast.com/
面对现实吧。几乎在所有情况下，只有接受混乱才能达到内心的解脱，否则只会让自己活在一个十分狭窄难受的空间中。
文档混乱，代码混乱，从“心”开始，你会感觉到人生都变得轻松了许多。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

以及我的微信视频号：