[原创] 在99%的情况下，接受混乱才能解脱

我昨天参加了一个分享会议，公司里另一个团队的一个同事在讲解某项目历史的时候提到，关于某个逻辑复杂的模块，由于前一个开发者离职好久了，他到现在也没有理清全部的逻辑。我曾经粗看过一下他们留下的文档，简直已经不能用“凌乱”来形容了，那真是乱得比垃圾堆还乱。
但是领导们可能只看到他们文档写得多，却不知道他们文档质量有多差。
如果你想找到某个具体的问题关联到的文档，恐怕你只能一个人一个人地去问，而你问到的人，很可能会告诉你“这一块没有文档，我也是接手来的，我要去看一下代码再告诉你答案”，口口相传。

这种事情我都不知道在公司里遇到过多少次了，我的心都麻木了，也不想为此再去争辩什么。
文章来源：https://www.codelast.com/
这也是为什么我自己写了大量文档去记录代码相关的问题。因为我怕有一天，当我已经记不起曾经写过的那么多代码的逻辑的时候，有个人突然跑来问我里面的细节，我甚至无法想起来里面的一点逻辑，然后又陷入耗费更多时间去温习旧功课的流程中。
但是我却不想把自己写过的大量文档全部记录在公司的文档系统里，我更愿意保存在自己的文件夹里。
因为基于我平常的工作习惯，如果我知道一个文档有问题，我会忍不住去更新它，不让它停留在一种不完善的状态。
但是如果我每次更新自己的文档，都费时间去更新公司里的文档，有何意义？
——消耗自己的时间，却对KPI没有促进。因为根本没人会关心，就算知道的人，也不会认为你花了多少时间写出了一篇十分耗时的文档。
其结果就是，你花了很多时间的事情，变成了拖累你工作进度的东西。
文章来源：https://www.codelast.com/
我是一个有代码洁癖的人。对公司官方制定好的代码编写规则，我不仅会遵守，而且会严格遵守。
我眼里见不得沙子，由我接手维护的代码，除非隐藏着较大的修改风险（例如修改后会导致业务逻辑不确定）、或者修改工作耗时多无法轻易下手，否则我是一定会去顺手修改一下那些不遵循规范的代码的。
文章来源：https://www.codelast.com/
能拯救一点代码就救一点。尽管公司不是我开的，以后就算我离职了我也不用关心接手人的死活，但是，作为一个有良心的人，我有时候还是会花时间在这些对KPI、OKR毫无正面作用的事情上。哪怕是为了内心的安宁，我都不想把走过路过看到的每一个问题都随手扔给别人。

文章来源：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 
感谢关注我的微信公众号（微信扫一扫）：

以及我的微信视频号：