论服务器程序设计编写的KISS法则

本文主要是介绍论服务器程序设计编写的KISS法则，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

论服务器程序设计编写的KISS法则

以简单明了为荣，以晦涩难懂为耻。
　　　　－写好注释，精炼代码
　　　　
以文本交互为荣，以二进制流为耻。
　　　　－文本数据，接口规范
　　　　
以封装隐蔽为荣，以暴露裸奔为耻。
　　　　－提供机制，隐蔽细节
　　　　
以命令参数为荣，以图形界面为耻。
　　　　－直入主题，不搞形式
　　　　
以小巧专一为荣，以画蛇添足为耻。
　　　　－专题专解，以期重用
　　　　
以规范标准为荣，以五花八门为耻。
　　　　－大众标准，不言自明
　　　　
以分工明晰为荣，以庞杂混沌为耻。
　　　　－明确任务，思路清楚
　　　　
以应用开放为荣，以闭门造车为耻。
　　　　－借力打力，如有神助

–写在2018年10月1日

服务器程序的典型应用是在UNIX/LINUX系统上的，也有在Windows上度用的，现代网络系统的成熟和广泛应用，使传统单机应用程序越来越少，而基于浏览器-服务器模式的软件应用成为主流。浏览器负责用户交互界面，服务器负责后台的数据检索、处理。可以说，现代软件设计技术主要分为前端和后端两大部分。人机交互的艺术是前端要考虑的事，我们称为可视化部分；而算法服务的技术核心则集中于后端。

本文也C语言开发为例，简述后端程序设计的基本要求和要遵循的基本原则。

所有这些原则，是UNIX系统创制的大师们所推崇和遵循的，可简单地称为KISS法则。KISS来自谚语Kiss Is Simple, Stupid，或全写为Keep It Simple, Stupid，好的代码应保持代码的简单性，傻瓜性，短小，易于理解。用C语言写成的Unix/Linux系统就是典型的代表。将KISS展开讲，大致有八个方面：

一切都是文件；
以文本的形式保存配置数据；
提供机制，而非策略；
尽可能避免与用户交互；
单一目的的小程序；
组合小程序完成复杂任务
前端后台，各司其职
站在巨人的肩膀上，充分利用软件的杠杆效应

一、一切都是文件

在这里插入图片描述
一切皆文件，就是将程序交互的对像，不论是真正的磁盘文件，还是标准输入输出设备，还是打印机，通信接口，一切都视为文件来统一处理。通常，程序运行所需的数据、参数要从文件中取出（也可以键盘、通信接口等特殊文件输入），需程序运行的输出结果要保存到文件中（显未屏幕、通信接口等也视为特殊的文件输出）。因此，一个标准控制台程序，其输入应来自文件（含标准输入设备stdin），其输出应写入文件（含标准输出设备stdout）。

程序与程序之间，通过数据文件进行数据交换和通信，这里，数据文件可以是磁盘上的文件，也可以是标准输入输出设备等特殊文件。通过操作系统的管道和重定向方式，可将上一程序执行的结果通过管道操作符|送入下一程序，作为其输入，这样一一相连，完成多道操作工序。而每道工序则是简单的，易于调式和相错，只要保持输入输出的数据格式不变，则更易于升级。

优雅而简洁的代码，不易破裂且让修改者很容易维护。这点非常重要，特别是当这个维护者是几年后的你。为了一点点儿性能上的优势，而增加大量的复杂性是一桩糟糕的买卖。复杂的代码容易窝赃bug。一般来讲，程序员思考要复杂度是与代码文件 行数的平方成正比的，当一个文件中代码量大于５００行左右，就应该考虑分解为多个文件来处理了。对于初学者，我建议单文件的代码量（含注释在内）应保持在２００行以内为好。

要以简单为荣，以晦涩为耻。

二、以文本的形式保存和交流数据

在这里插入图片描述
Unix传统强烈期望程序可以读、写简单的、基于文本和流式以及设备无关的格式。经典的Unix中，有大量的程序作为过滤器（filter）出现，过滤器从一个程序获得文本输入处理后再将文本输出。并不是Unix程序员都不喜欢图形用户界面。而是因为如果不用字符流，程序间很难挂钩。以 字符流 作为消息传递的Unix工具天然具备了面向对象的性质（封装、隐蔽、可重用、多态）。

数据流只要可能就应该是文本的（即字符流：这样才可以用标准的工具阅读和过滤），数据库规划和应用协议只要可能应该是文本的（文本可读、文本可编辑）。如无特别要求，数据的保存形式应是自解释的，应使用人能读懂的格式化文本来保存数据，不建议使用二进制格式的数据（除非有特别的理由，如音视频，大的图像等文件需要压缩和效率，但在做算法研究时仍建议使用可读的文本来表示）。对于程序运行的参数，建议写为一种文本的形式保存配置数据，如通常的*.ini文件。方便随时修改，参数文件也要是自明的，或依据注释能直接理解。如Tomcat,MySQL等都是以配置文件来更改运行初始参数的。写注册表，以可视化界面配置参数都会导致程序骓以移植。

要以字符流为荣，以二进流为耻。

三、提供机制，而非策略

在这里插入图片描述

Unix/Linux的接口设计有一句通用的格言“提供机制而不是策略”。区别对待机制（mechanism）和策略（policy）是Unix设计中的一大亮点。大部分的编程问题都可以被切割成两个部分：“需要提供什么功能”（机制）和“怎样实现这些功能”（策略）。将程序的数据接口（输入或输出）标准化，实行数据接口的封装，可以减少开发量，而专注于算法（策略）的实现。如果由程序中的独立部分分别负责机制和策略的实现，那么开发软件就更容易，也更容易适应不同的需求。

让机制与策略分离；让接口同引擎分离。

要以封装为荣，以暴露为耻。

四、尽可能避免与用户交互

在这里插入图片描述

服务器程序注重的是自动运行的算法和机制，服务器一般不直接与用户交互，否则就不能实现全自动运行了。这里再次看到，对服务器程序，可视化界面决不是好的选择。

以命令行为荣，以图形界面为耻。

五、单一目的的小程序

在这里插入图片描述

一个程序，只专注一个功能，把这一个功能做好。不要大而全。功能越单一，可重用性也就越好。Unix/Linux就是以千千万万个这样一些目的单一的小程序组成的。时刻记得，小就是好的，小即是美，写程序时做到刚好能够完成你的任务为佳。

以小巧专一为荣，以画蛇添足为耻。

六、组合小程序完成复杂任务

在这里插入图片描述

有简单的统一数据接口，有自解释的文本文件格式，有单一功能的小程序，那么，通过文件数据传递的脚本（如批处理）或管道和重定向机制，很容易把多个小程序组装起来，完成更复杂的任务。小程序就像一个个电子元件，合理的组装就成了各种电子设备了。Unix系统本身就是以这种方式构成和不断进化的。
操作系统中管道的发明者Doug McIlroy也是Unix传统的奠基人之一，他这样说：

– 让每一个程序只很好得做一件事情。当出现新工作的时候应该重组已有的程序而不是通过添加新特性使得原有程序变得复杂。

他还说过：

– 每个程序的输出应该可以成为另一个程序的输入，甚至一个未知程序。不让让彼此无关的消息混乱你的输出。尽量避免二进制输入格式。不要强求交互式输入方式。

总之，就是要模块化：编写简单的模块组件，以整齐的接口让它们互相连通。

以规范标准为荣，以五花八门为耻。

七、前端后台，各司其职

在这里插入图片描述
复杂的前端（用户界面）和负责的后端之间应该被清晰分离。信息的表现形式和信息内容的处理过程应该被清晰分离。服务器后台专司数据处理，前端与用户界面交互的事情交给浏览器处理。这样做容易保持软件的跨平台应用能力。

以分工明晰为荣，以庞杂混沌为耻。

八、站在巨人的肩膀上，充分利用软件的杠杆效应

在这里插入图片描述
充分利用软件的功能复用，在Unix/Linux以及移植在Windows上，都有一些非常优秀的命令行工具程序，如音频处理和格式转换的SoX，多媒体文件处理工具FFmpeg，图像处理工具ImageMagick等等，又如功能极为强悍的作图工具Gnuplot，Graphviz等，还有如超好用的文档处理工具pandoc，latex等等，善于充分利用（如在C语言中通过命令行直接调用）这些优秀软件的功能，可能带给你意外的惊喜。总之，善用开源，我为人人。