真正的KISS解决方案有多“简单”？[关闭]

我承认：大多数时候我都存在“保持简单和简短”的问题，因为尝试根据我读过的书，听说过的设计模式等使它变得如此热情-一种热情来自感觉到我在实现完美的正确道路上。

另一方面，是的，这有时会给我最后期限带来压力。

但是，每当我对自己说：“下次再简单一点，你就是愚蠢的！” 我觉得很难在下次出现时使其变得“简单”，因为它开始变得怪异……并且在一点之后变得不舒服。

然后我开始判断我对“简单”的理解...

SIMPLE是否意味着它太短了，但是它很难维护和扩展？

SIMPLE是否意味着打破许多OOP原则？

SIMPLE是否意味着作弊？

SIMPLE是否意味着只保留截止日期而没有交易？等等

其实是什么

问题是：可以根据KISS原理写出SIMPLE的确切定义吗？-如果有。

谢谢！

让我们学习一个法语的吻：

完美无缺，不享有任何权利，不享有任何权利。—圣艾修伯里安托万

转换为：

达到完美，不是在没有其他可添加的东西时，而是在没有其他东西可取的时候。—圣艾修伯里安托万

情境

您需要削减和捏。

解决方案A：不设吻

解决方案B：吻

至于确切的定义：很难为测量简单性定义绝对比例。主要是因为真正的简单性妨碍了对当前问题的真正理解，而这几乎是不可能实现的。但是，假设解决方案A和B分别说明了倾向于过度复杂化和简单化的解决方案之间的差异。

“使事情尽可能简单，但不要简单”-爱因斯坦

使代码尽可能简单而不是更简单取决于要解决的问题。只要要解决的问题趋于改变，KISS也会改变。

在过度工程（哦，这看起来像是炫耀我的设计模式技能的好地方！）和工程不足（如果仅使用工厂的情况下，这种耦合不会导致我赚20分）之间是一个平衡。代码更改...）。目标是可维护性。

简单并不意味着打破良好的编程原则。实际上，这意味着更多的相反情况。

SIMPLE是否意味着它太短了，但是它很难维护和扩展？

不能。难以维护和扩展是复杂性的一大征兆。实际上，我发现使代码可扩展导致代码更简单，因为您不必一开始就处理每个案例，就可以使基本代码更简单。

SIMPLE是否意味着打破许多OOP原则？

否。大多数OOP原则旨在使代码保持更整洁和更有条理，最终使代码更简单。

SIMPLE是否意味着作弊？

不，以保持期限为幌子，努力编写代码以维护代码和黑客行为。

SIMPLE是否意味着只保留截止日期而没有交易？等等

截止日期和代码的简单性是两个独立的问题。编写简单的代码无需花费任何时间（尽管这是一种常见的误解）。

解释起来非常棘手，因为简单并不意味着每个人都有相同的意思。

例。有些开发人员认为这?:很简单，但其他开发人员认为if声明更好。当它下降到这个水平时，您不能取悦所有人。

通常，简单意味着没有复杂性。为了了解简单性，我们需要了解复杂性。

有两种类型的复杂度：

本质复杂性是指由于“简单”的解决方案无法充分解决问题而必须对所有合理的解决方案进行复杂处理（并可能造成混淆）的情况。-维基百科

偶然的复杂性是在计算机程序或其开发过程（计算机编程）中出现的复杂性，它对要解决的问题不是必需的。-维基百科

您可以通过以下问题检查基本的复杂性：

这个解决方案简单吗？我可以在几分钟内向同伴解释一下，他们会明白吗？有没有更简单的解决方案？如果是，那么复杂的解决方案与简单的解决方案之间是否需要权衡？我们可以忍受这些折衷吗？例如，许多程序员犯了一个错误，那就是对所有事物进行微优化，并且他们的解决方案（以及代码）变得过于复杂。

检查您的意外复杂性：

代码简单吗？如果我在三个月后回到这个问题上，我需要花多长时间在脑海中建立背景，以便我做出需要做的改变？我的源代码中的所有内容是否都有明确的目的，并将该目的有效传达给我和其他开发人员？测试我的代码有多难？通常，您的代码越复杂，单元测试就越困难，因此我通常将其用作衡量复杂度的方法。通常，您需要小型，名称明确且重点突出的类和方法。设计模式通常也可以帮助您实现这些目标。

如果您只是因为阅读了它而想要使用设计模式，则可能会带来意外的复杂性。如果您发现自己想放东西是因为您认为“它很聪明”，则可能会带来意外的复杂性。

我希望这会有所帮助，并且不要忘记：简单并不意味着EASY。

我一直觉得X11（http://en.wikipedia.org/wiki/X_Window_System#Principles）背后的原理值得关注。我并非总是能成功实现这一目标。

具体来说，我一直在提醒自己……“除非您知道某些真正的应用程序将需要的功能，否则请不要添加新功能。”和“如果在10％的工作中可以获得90％的预期效果，使用更简单的解决方案。”

问题是：您能根据KISS原则写出SIMPLE的确切定义吗？-如果有。

没有。

简单-在此特定情况下，与复杂完全相反。简单并不一定意味着：每个愚蠢的人都必须理解它-但是您必须确保即使您自己没有自己写，也可以理解。

通过艰苦的理解，可以实现复杂性-摆脱那些！许多文件/类彼此链接-没办法！以及复杂的代码（意味着：链式循环，多个ITE层等）-没人愿意读。

我认为：添加另一个函数非常容易，在类中还可以添加私有函数，因此您不会弄乱接口。那么，为什么不利用此优势，而将您的功能/过程限制为50行。甚至更少。获取一些有意义的名称。这样，您可以使大多数注释过时。这样，您的功能易于阅读，易于修改/扩展。

当然...最后几句话的用法如下：在类中，可以定义私有函数，只需使用这种可能性将函数拆分为50个内衬即可，因此可读性更高（不要忘记好名声，因此您无需多加评论）。

但是：如果有句号显示，则阅读所有内容要简单得多（！）：我完成了一个想法，让我们继续下一个想法。

那就是我所定义的简单。