你必须理解的三大软件原则2_KISS

正文

原文标题：3 Key Software Principles You Must Understand 

原作者信息：2012年9月7日Chris Peters

原文地址：http://net.tutsplus.com/tutorials/tools-and-tips/3-key-software-principles-you-must-understand/

原则1：不做重复的事（Don't Repeat Yourself）

译文地址：http://blog.csdn.net/zj_show/article/details/8065836

原则2：保持简单直接（Keep it Simple Stupid）

19世纪后叶，物理学家们纠结于解释当物体达到很远的距离，就像整个太阳系的距离时，他们间的引力，磁力，和光磁力是如何相互影响的。正因如此，一种称作以太的中间物质被假设出来了。据说，光就是通过这种中间物质传播的，并且一些其他无法解释的现象也被归结到它的身上。多年以后，一种假设扩充了这个理论，这种假设将以太的假定条件调整为实验结果。一些假设是武断的，一些还会导致其他的问题，总之整个理论异常复杂。

       瑞士专利局的一名雇员，Albert Einstein，提出了解决整个以太理论的革命性想法：如果我们接受“时间并不是连续的而是相对的”这个观点后，那在计算超长距离时产生的奇怪问题都将烟消云散。他在相互竞争的情况下选用最少的假设给出最简洁的解释，这种难以置信的创新思维被引用作Ockhams’s Razor。

       很多行业都有相似的思想。软件开发（还有其他行业）中，我们将其称作KISS原则。对于这个缩写还有很多不同版本，但主旨只有一个，那就是你应该以最简洁的方式做好某件事。

人类历史的实质性进展都是那些极具横向思维的人们推动的

       HTTP

       超文本传输协议是一个作为精简方案而广受传播的完美实例：它是为了基于文件的超文本传输而设计的，也是当前高交互性应用和桌面应用的基石。也许我们不得不找寻出解决这种协议内诸多限制的方案，甚至，或许在将来的某一天它会被其他事物取而代之。但不管怎样，现状是：基于多种请求方式（GET或者POST）、状态码或者纯文本参数，HTTP已被证明是兼具伸缩性和健壮性的。这就是为什么HTTP被WEB开发者不断推向至高的极限位置并且岿然不倒的原因。

我们认为这种方法是理所当然的，但软件开发及其标准化的历史上到处充斥着过度复杂与半途而废的解决方案。甚至于还有一个专有的短语来形容这种失败：膨胀软件（bloatware）。这样的软件通常也被描述为DOD，胎死腹中（dead onarrival）。讲到膨胀软件，我有一个与非DRY理论非常相似的理论。不管怎样，互联网的成功可以被描述为简单而高效的的成功案例。

那么要想取得最简洁的方案都需要些什么呢？在软件开发中，这都归结为可维护性与可读性。因此，KISS原则应该在需求阶段就被引入。当你正在考虑如何将客户需求转变为可实现的组件时，请试着确认以下几个部分：

• 功能在付出与收益之间往往达不到很合适的比例
• 功能间会高度依赖
• 功能往往会变的更复杂

我曾经参与过一个项目，这个项目的客户希望将Excel表格导入到他的员工管理软件中。Excel是一个拥有复杂文件格式的第三方软件。格式相当复杂，因为它富文本的：你可以向其添加图表或者其他一些内容，这些特性却并不是客户所需要的，他仅仅关注数据。所以，实现Excel导入功能需要实现一些并不是必须的功能。另外，Excel已经有好多个版本，同时微软每年都在发布新版本。这将会变得异常难于维护，并且将会带来不菲的开销。

我们最终实现了以逗号分隔的文本导入功能，这只需要几行代码就可以完成。数据头真的很小（等同于EXCEL工作表的CSV格式），并且这个方案是可维护的且具有前瞻性。反正EXCEL可以导出CSV（将来客户希望使用的其他程序也可以）。由于这个方案是低成本的，它是KISS规则的好实践。

总结：如果你觉得一个任务看起来很复杂，请尝试一些跳出思维定势的想法。如果某人正在向你阐述他的需求，而你觉得实现起来会很困难，这种情况下往往你是正确的。当一些功能只是很难实现时，超复杂的解决方案便会很平常的接踵而来。这就是事实，因为在整个流程中有很多人参与，而这些人根本不具备给出一个可信赖的得失分析的专业技术。因此，他们看不到问题所在。反复考量需求，看看将他们剥离到本质后还是不是客户真正想要的。花时间去讨论关键点，再解释下为什么其他的解决方案可能会更合适。