被理解，而不是聪明

在技术挑战面前，尤其是在源代码方面，我们经常会希望把事情做得精致、漂亮，甚至像有些人说的那样 "性感"。这是完全正常的—​因为代码是我们开发人员生活的重要组成部分，所以我们有时会想展示自己的能力。虽然有时这样做是有道理的，但想要完全展示自己的才能往往不是一个好主意。显然，我们的自尊心会受到打击，有时我们必须忍住。你刚刚学会了新的做事方法、新的编码方式和新的原则，你对这些都深信不疑。你花了一个周末的时间来学习这种组织代码和项目的新方法，你将它视为一种启示，而且你确信：你必须向你的同事和团队展示这个新发现；它将彻底改变项目，并带来美好的事物。此外，你还将为这一新事物立下汗马功劳，成为它的参照物。然而，这根本不是正确的做法。

不要搞错了。无论是否利用自己的时间，每天学习都是一件非常了不起的事情。如果你有机会这样做，你会做得更好。顺便说一句：这绝不是强制性的！任何事情都不能强迫自己在业余时间编码。为了工作而继续编码和编程是完全没问题的。

渴望与同伴分享自己的发现和经验是正常的，甚至是健康的。分享知识让你所爱的人得到提升是最美好的事情，而解释一些东西是你自己学习的最好方式。错误在于想要立即、无处不在、无时不在地应用知识。每种方式都有其优缺点。绝对有必要认识到它所带来的弊端。一般来说，最常见的是在当前项目中的应用，以及项目中其它相关人员对变革的抵制。仅以著名的 SOLID 原则为例：虽然其有效性已得到证实，但对于新手来说却很难理解。

抵制变革对所有人来说都是正常和自然的。我们的大脑喜欢规律，喜欢循环，不喜欢意外。这不仅体现在工作环境中，也体现在饮食、运动和睡眠等生活的方方面面。代码和我们的工作习惯也是如此。同样，一致性和规律性是关键。

如果你把你的新发现带入项目，你就必须考虑对现有人员的培训。如果已有的习惯是合适的，而且已经满足了需求，他们就不一定想改变自己的习惯。新的习惯也意味着要培训所有不知道这些做事方法的人。这就需要个人投资，在某些情况下甚至需要大量投资。这就涉及到利用个人时间或工作时间进行学习的问题，因此，不可否认的是，这些时间会降低工作效率。有时这样做是必要的，有时甚至是一个很有前途的想法。但这样一来，你必须能够向所有人，包括项目中的非技术人员证明这样做是合理的，而这显然是至关重要的一环，尤其是在时间紧迫的情况下。

此外，有些编程方法可以创造奇迹，经过验证，可以让生活变得更轻松。然而，它们也有一个巨大的缺点：项目的入职时间。以 "无 if 编程 "为例。这种编程方法要求在代码中绝对绝对不要使用 if 和条件分支。这就需要大量、纯粹地使用面向对象编程（OOP）。从纸面上看，这看起来不错，而且这种技术在智力上的满足感也一定非同一般。一旦掌握了这种技术，其效率是显而易见的。一切都变得更加智能，代码也明显变得清晰。简而言之，你的下一个项目从一开始就可以采用无 if 编程。

然而，当有一天有人来到你的项目中帮助你，并试图理解你正在做的事情（甚至与你一起维护和发展项目）时，你会发现：如果这个人不知道这种编程技术（这种技术远非通用技术），那么引入项目的整个过程将是痛苦的。除了要培训项目的功能限制外，还必须培训他们掌握一种他们肯定不习惯的新编程技术。这意味着要了解项目、了解利害关系、改变习惯、改变做事和工作方式，以及重塑思维方式。我们很快就明白了这种行动的成本。它可以是合理的，但你必须对自己非常有把握，并事先了解所有的风险。

我们在这里讨论的是无 if 编程，但其它非一般规则的方法也是如此。测试驱动开发（TDD）就是其中之一！正如我们之前所见，将 TDD 整合到一个项目中可能是痛苦而复杂的。然而，TDD 主要影响的是做事的顺序，而不是学习一种完整的编码方式。至于这些风险在多大程度上值得承担，这取决于你，取决于你的环境和限制条件。

无论如何，如果你选择了一种可以说是奇特的新编程技术，你可能会拥有堪称典范的代码，干净、高效、可维护性超强。问题是，没有人能理解它。请记住上一节的内容：代码是用来表达和传递思想的。它是用来被机器理解的，尤其是被人类理解。如果牺牲了第二点，那就太可惜了，而这正是发明高级编程语言的原因。