作为程序员，你可能是烂代码的受害者，如果你觉得技术欠佳、人生失意的话。
前一篇文章讲了烂代码的根源。作为有追求的程序员，如果发现产品里有烂代码，自然是要想办法解决掉。我相信，有追求的程序员们对代码质量都有着不懈的追求。可现实却是，为了实现这点追求，不得不从原本的 996 变成 997——程序员们利用周末时间继续优化公司的代码是非常常见的事。最糟糕的是，周末处理这些代码客观上占据了程序员们做其他事的时间和精力，比如学点新的东西，或者找对象。于是，我们意识到，处理烂代码的过程也是要花时间和精力的，而且经常还要花不少时间和精力。
如果不想在周末偷偷加班，唯一的选择就是要在工作日进行。要在日常工作中优化代码（即重构），首先要过的就是项目经理这一关：使用这些时间精力来获得代码改进的同时，同时也就失去了利用它们来给产品添加新功能的机会——这就是机会成本。项目经理们最讨厌的就是那些需要花费额外成本去做的事。既然同样是完成开发，能以最简单快速有效的方法实现，就算实现恶心一点又怎么样呢？
遇到这样的项目经理，程序员们如何说服他们呢？我想，程序员们在说服项目经理之前，首先要做的是说服自己。不出意外地话，包括作者我在内的绝大多数程序员，我们要么（曾）是烂代码的缔造者，要么（曾）是烂代码的卫道士。（这一点在上一篇文章中已有足够的讨论）毫不夸张地说，我们一动键盘，一写代码就在写烂代码。不信的话，一起来做个很简单的一个实验，你现在就找出你一年之前自己曾经引以为豪的那段代码，看看是不是觉得写的很烂？如果还是觉得它很好，那有两个可能：
- 这一年里你的代码水平毫无长进
- 去年的你，代码水平就已经登丰造极了
你觉得哪一项更有可能是事实呢？
所以我们自己要真正建立对整洁代码的追求，成为整洁代码的践行者，才有可能去说服别人重视这件事。 成为了整洁代码的践行者有什么好处呢？我有位朋友说，他有写单元测试的习惯。一开始，人们都笑话他，觉得是浪费时间。同样一份工作，写实现是一份时间，写测试又是一份时间，表面上是花了两倍成本。朋友说，过了一阵，大家开始各种加班修 Bug，而他却总是可以按时下班。要我说，上班的时间花的是老板的，省下来的下班时间却是自己的啊。这省下来的时间，做点什么不好呢？
当然，现实中也有的人比较悲催，明明是做的好还被认为是偷懒耍滑（比如下图）……这就是另一个话题了。
整洁的代码可以让我们早些下班。这是真的。
这是因为，整洁的代码能让我们在加新功能时更高效。通常，好的代码具有内聚的模块化设计，模块化之间的耦合又清晰直观，所以添加功能时只需要添加增加新的模块即可轻松实现。面向对象设计五原则 SOLID 中的开闭原则（Open-closed）就提到，好的代码设计应该对扩展开放，而对修改封闭。
另外，好的代码在需要修改逻辑时也能够更轻松安全。虽然好的封装设计对修改封闭，但作为不断迭代开发的软件项目，怎么可能不修改呢？修改已有逻辑的时候最担心的就是破坏现有的逻辑，也正因此，不少人宁可复制一遍旧的代码再改，也不要直接修改以前的代码。但设计良好的代码在修改时更容易掌控影响范围，即使出错也能在第一时间受到反馈。
好代码很简单，我们常说它易于阅读，便于维护。具体来说，也有一些更清晰的标准来帮助我们判定一份代码是不是好代码：有测试的代码能确保即使在我们犯错时，也能够在第一时间给到最直接的反馈；能够清晰表达其设计意图的代码可以确保修改时不会改错地方；没有重复的代码，因此不会需要担心修改逻辑时忘了几处没有改；不拖泥带水的代码让维护代码的人更直观地维护代码——而不是要像研习古文一样先读上几遍、对代码进行再抽象（比如，将 for 中的多层嵌套 if 抽象理解为过滤），再屏蔽掉过时的注释的干扰后才能明白其中的逻辑。上述四条规则被称之为“简单设计”四原则。就像上面我说好代码很简单一样，这几条规则也十分简单，很容易理解。
某次我在与一位开发人员讨论解决源代码合并冲突的问题的时候，他说他最讨厌别人重构了，一重构就会导致文件、符号找不到，合并都没法进行。
我反问他：“一般谁做重构？”
“大佬们哪，他们平常正事不干，就喜欢重构。”
“那么，你不想成为大佬吗？”
他愣了一下，一时不知如何回答。似乎，我的话有点不按套路出牌……
显然，如果写了烂代码，就无法享受上面那些好处了。更可怕的是，烂代码写多了之后，程序员就会形成习惯。“既然代码只要将就就可以了，那么第三库、IDE、电脑配置，以及服务器环境，一切一切也只要将就就行了”。这会让我们产生一种“将就”的习惯，久而久之，不光编程能力受限，各种其他方面也受限。请注意，这将直接限制了我们的发展空间。就像想象力会被贫穷限制住一样，一个程序员的未来也就此定格。
顺便稍微引申一下。有的人觉得，面对一个已经烂透了的代码库，最简单的挽救方法，就是从头重写一次，在重写过程中，注意好设计方法和代码质量就能避免重蹈覆辙。你觉得，实际情况真的会是这样吗？
所以，作为程序员，你可能是烂代码的受害者，如果你觉得技术欠佳、人生失意的话。
