自觉使用KISS

前一阵子我写了一些设计范例，在设计和实现某个组件时要牢记。 其中，著名的KISS （Keep It Simple，Stupid）一直是有效而合理的。 然后，我意识到，当初级开发人员或更广泛地将其用作宗教时，使用KISS会有多么危险：它被假装成真是对的，没有进一步的解释，因此以KISS的名义我们可以证明几乎所有东西都是合理的。 通常是错误的。 主要关注的是在某种情况下 简单的含义是什么，以及该含义是否破坏了任何其他有效的范式，或更确切地说，是打破了您的（技术） 常识 。

我们可能也会对其他范式应用相同的推理，确实正确的设计模式和范式设备始终取决于给定的上下文，但是KISS似乎是一种特例 ，因为我们实际上可以在任何时候，以简化事情。 但是，我们真的简化了吗？

简单示例：以KISS的名义，开发人员希望将所有业务逻辑都放在一个类中（这更简单 -您可能听说过-不需要维护多个类！）； 以KISS的名义，SQL select语句都将具有*字段选择器（可能更简单 -他们可能会说–您不需要列出七个必填列！）； 以KISS的名义……等等。 当然，我正在将其推到某个极限，但是很显然， 简单并不总是意味着更好 。 因此，每次听到有人声称使用KISS时，我都会感到怀疑，这里有一些有效的争论点，以找出错误的KISS或至少着眼于在特定情况下的（误）理解。

吻可能会打破其他良好做法

与其他好的做法冲突简单吗？ 这可能是第一个也是最重要的问题。 一个简单的解决方案仍应与常见的面向对象的实践兼容，也就是说，它不应破坏例如单一责任原则（ SRP ）或告诉，不要问（ TDA ）实践； 此外，在提供预期的行为和功能的同时，它还应确保良好的可测试性（因此，也很容易测试，对吗？）。 因此，在与KISS打交道时，请尝试将其与其他众所周知的实践和准则进行比较（或加强），无视它，不要仅仅出于简单性就认为它是正确的。

吻可能会破坏表现

简单意味着慢吗？ 简单性并不总是与出色的表现相匹配，当KISS出现时，这肯定是一个危险信号。 考虑简单的 SQL查询，然后执行性能较差的算法或简单的算法实现，从而不必要地需要大量的内存或部署，而这些内存或部署不会根据请求或用户的数量进行适当扩展。 我们常常不能简单地做到这一点，而且我们确实不会愚蠢 。

吻可能又快又脏

简单意味着对变通方法的授权吗？ 您可能仍然符合OO惯例并提供合理的性能，但是以KISS的名义，您还可以添加方法或参数，因为它可以轻松，快速地（以一种简单的方式）解决某个问题。 没错，只要我们不违反合约原则或不引入意外的耦合，只要我们也遵守最小惊讶原则，只要我们不破坏合同的一致性或引入不必要的未来兼容性，就没有什么不对（ PLA ），即不会降低用户体验。 因此，当心简单 快捷的方法 。

吻可以证明任何解决方案

简单真的有意义吗？ 总体而言，您甚至可能会怀疑应如何在给定的方式和上下文中应用简单性，以及为什么应优先选择某种简单性 。 是的，根据最终目标（您真正想要实现的目标， 简单意味着您可以立即看到解决方案），时间（ 简单意味着您没有时间寻求其他解决方案），约束条件（ 简单意味着简单 ），简单性可能具有多种面Kong和含义。您没有其他解决方案），技能（ 简单意味着您不知道其他解决方案）。 此外，当KISS是唯一的理由或优势时，请尝试至少寻找第二个理由或优势，不要盲目地信任纯粹的KISS解决方案。

像往常一样，我们的常识和经验应指导最佳选择的使用，设计模式和范例不是灵丹妙药，应始终有意识地使用。 当然，简单性是要实现的一个重要目标，并且在可维护性，可读性，清洁性和美观性方面都值得提供一个属性，但是绝对不应该意味着质量下降 。 因此，当KISS闻起来像上述情况之一时，您应该不信任它，因为确实它的歧义可能导致完全相反的结果：复杂性和麻烦。 它也发生在现实生活中，您可能会想找到一个KISS，但最终得到了SLAP （简单性留下了尴尬的问题）。

参考：在Refactoring Ideas博客上，可以从我们的JCG合作伙伴 Antonio Di Matteo中有意识地使用KISS 。

翻译自: https://www.javacodegeeks.com/2014/03/use-kiss-consciously.html