为什么简洁的代码并非主流？

为什么在很多公司里，#CleanCode 仍然是例外而不是常态？

当时担任红帽公司开发者体验总监的马库斯·比尔在领英上提出了一个非常有趣的问题。当时我没有时间深入研究这个问题，但几个月后我重新阅读了那些回答。

就是他们！

人们主要指向两类人：

• 项目经理
• 初级开发人员

项目经理之所以难辞其咎，是因为他们只想着一件事：把新功能和项目一股脑地扔出软件工厂。他们根本不在乎代码是否整洁，甚至不理解什么是技术债务，而缺乏这种深入的理解，编写“整洁的代码”（无论我们如何定义）都是代价高昂的。

此外，“新开发人员的数量每五年翻一番”，他们显然不知道如何编写简洁的代码，而且数学计算表明，根本没有足够的资深开发人员来指导他们。

这些说法虽然属实，但他们只是把责任推卸给别人和环境。这种解释很幼稚，因为他们缺乏自我责任感。

但我还发现了一些更有趣的答案。

是我们！

我们必须说不

Eloy提到，在他看来，作为开发者，有时候最好说“不”。或者至少委婉地提醒对方，如果他们继续这样做，最终会搬起石头砸自己的脚。我完全同意他的观点。不出所料，这引发了一场关于开发者，尤其是个人贡献者，缺乏说“不”的权利的讨论。再一次，把责任推卸给环境和他人总是更容易的。

但正如埃洛伊和其他人指出的那样，拒绝的方式不止一种。一种方法是，如果你觉得自己的专业技能不被需要，就主动退出，转到其他项目。或者，你可以更强硬一些，提醒你的管理层，如果他们不信任你，他们有权解雇你。如果你是一位经验丰富的开发人员，找到另一份工作有多难？这并不容易，但总比待在一个不被重视和信任的岗位上要好得多。

我很喜欢这个子话题，因为它强调了个人的责任，也提到了职业精神。在我看来，如果你是一个真正的专业人士，你就必须能够说“不”。不仅如此，当你觉得合适的时候，说“不”是你的责任！我知道第一次说“不”很难。但一个好老板会欣赏你的这种精神。即使因为某些原因他让你走弯路，他也会理解你的理由，不会因此惩罚你。当然，如果他不是一个好老板，他可能只会生气。我已经说过了，总会有其他项目/公司可以选择。

编写简洁的代码很难

说到专业性和难点，我喜欢的另一个回复是说#CleanCode很难。因为它需要付出巨大的努力（至少在初期是这样），并且需要自律，只追求卓越。它并非主流。我喜欢这个回复的地方在于它没有推卸责任。人——我们——都懒惰且缺乏条理。人——我们——倾向于选择阻力最小的方案，如果团队接受了平庸的表现，那么我们个人也就只能达到平庸的水平。

如果你想持续保持高水平发挥，就必须建立一套机制，迫使自己达到更高的标准。大多数人的水平都处于平均水平——这并不奇怪，这是不争的事实。如果你能帮助他人进步，那就更好了，但你也要对自己负责。你必须不断鞭策自己，让自己变得更好。

我们必须引领技术变革，或许其他人会跟随。或者至少会有几个人跟随。

让我们开始工作吧！

虽然很多项目经理确实不了解技术债务或整洁代码，但我并不认为这是个问题。他们理解继承、不可变性或不同内存分配方式的区别吗？有些人当然理解，但很多人不理解，但这也不是什么大问题。我们做好自己的工作，必要时再解释和回答问题。

作为专业人士，我们必须有理有据，有话直说。希望你受聘是为了发挥所长，分享专业知识，而不是仅仅充当只会写代码的程序员。看看叶戈尔·布加延科是如何憎恨他的理发师的，仅仅因为那理发师一味讨好他。

我发现很多人害怕展现专业素养。有时是因为疏忽大意，有时则是因为根本不在乎。你还记得电影《上班一条虫》吗？“我还能再赚一分钱吗？”这种想法在某些方面可以理解，但很可能意味着你要么不够专业，要么选错了地方。

有时候，这是由于冒名顶替综合症引起的，这很正常。但你必须克服它。其他人曾用引人入胜的文字描述过这一点。

有时候，这并非疏忽，而是恐惧和经验不足。资深人士必须树立榜样，必须展现出敢于坚持己见的能力。有经验的人必须营造一个安全的环境，让大家可以畅所欲言，捍卫自己的专业意见。有时，引入技术债务是可以接受的，但如果你持续感到自己的意见不被尊重，债务却不断累积，那么或许你应该考虑退出。

项目经理不了解我们工作的全部细节，甚至也不关心——这可以理解，他们为什么要关心呢？——但我们有责任用他们能理解的方式阐述我们的观点。这无关乎难看的变量名，也无关乎Vim里混乱的缩进。这无关乎类中的代码行数，也无关乎函数的圈复杂度。关键在于维护成本。《代码简洁性：软件基础》一书对此有非常精彩的解释。

这很难，我失败过很多次，以后还会失败很多次，但我们应该尝试，然后坚持下去。我们有责任让管理层明白，如果他们一开始多投入一点，从长远来看，他们的支出会少得多。当然，这其中也存在市场压力等因素。有时候这种做法更适用，有时候则不太适用。但他们愿意看到自己的产品因为糟糕的代码而失败吗？如果这意味着数百万美元的收入和市值损失呢？如果这意味着数百人的生命呢？

结论

很难定义什么是干净的代码。但它或许就像重口味色情片一样，你无法真正定义它，但当你看到它时，你自然而然就会明白。很难准确地描述干净的代码，但如果你遇到一个干净的 pull request，你会情不自禁地露出满意的微笑。

我们必须牢记，责任永远在我们自己，而不是他们。我们必须发出自己的声音，我们必须解释和教育。必要时，我们必须退居幕后。这是构建更易于维护和更可靠的代码库的唯一途径。你今天可能觉得这是夸张之词，但明天你或许会明白，这关乎生死，而不仅仅是职业尊严！

本文最初发表于我的博客。如果您有兴趣接收我的最新文章，请订阅我的电子报并关注我的推特账号。