具有情境感知能力

在这里，我们进入了谈及简洁代码时最重要的部分之一。如果只需要记住一件事，那就是：我们可以经常谈论其它开发人员定义的规则、对象原则和清洁代码原则。我们可能会经常谈论其它开发人员定义的规则、对象原则和清洁代码的原则，但任何东西都比不上我们在这里要谈论的：这就是要注意你的上下文。许多关于简洁代码的书籍和文章都缺少一点，即：让人感觉它与日常生活息息相关。开发人员的生活由突发事件、技术限制、不可能做的事情或被迫做的事情组成。

项目有多少，做事的方法就有多少。每个项目都有自己的历史、技术决策和制约因素。因此，我们最终会发现许多理论原则并不适用，或者会破坏项目的连贯性。好的做法可能会规定如何命名变量、如何命名类和方法、如何命名文件，或者如何构成项目的树形结构。但是，如果这与项目中的设置相悖怎么办？这是一个经常出现的问题，尤其是在所谓的 "传统" 项目中。

答案既简单又复杂。说它简单，是因为它可以用一句话概括：与你的团队和其它参与项目的人员进行讨论。这就是答案变得复杂的地方，因为它很可能会在团队内部引发争论（有时是激烈的争论），这很正常。但重要的是：你不仅要找到大家都会尊重的共同点，与项目保持一致，还要找到最适合你和你的团队的方法。

这可能是所有这些讨论的基石：你可能有良好的实践和清洁代码原则，但也许有些规则值得调整，因为这对你和你的团队来说效果更好。这完全是偏离某些原则的正当理由（当然不是所有原则，否则就是完全的无政府状态）。有时，找不到共同点，这时候，最佳实践和其它原则就可以占上风，规定每个人都必须遵守的规则，即使不是对每个人都有效的规则。

这时，我们又回到了前面提到的一点。在开发人员团队中制定共同的规则有助于让大家更容易理解。项目导航和文件导航都会变得更容易。大家说着同样的语言，就能更好地相互理解。无论是帮助别人还是被别人帮助，都是同样的道理。如果大家都遵守共同的命名和缩进规则，不仅可以避免无谓的争论，使你偏离最初的目标，而且如果你觉得队友写的代码就是你写的代码，那就是双赢。

我们可以这样总结选择决定良好实践和 "经典" 的清洁代码原则：

你的情况过去在项目中出现过吗？

在这里，我们再次清楚地看到，成功的关键在于沟通和辩论。每个人都有自己的观点和处理问题的方法，所以问题永远不会非黑即白。但有一点要牢记：你应该避免单独就可能引起争论的做法做出决定。避免单独做决定并不意味着你不应该做决定。相反，我们的意思是要仔细考虑各种选择，权衡每种选择的利弊。同样，要能够向参与项目的其它人证明你提出的每项建议的合理性。如果你能提出几种解决问题的方案，并很好地说明这些方案为什么合适，以及这些方案所带来的风险，那么你一定会得到团队的高度赞赏。你很快就会意识到，单独完成这项工作可能会很复杂，因此与团队讨论这项工作就显得尤为重要。每个人都有自己的工作方式。

顺便说一句，所有这些不仅适用于 IT、简洁代码和 PHP。这就是为什么上一章提到，简洁代码不仅仅是一套规则：它是一种存在方式，是一种思维方式。