编程艺术

最近几天啃了一本书，关于RTOS的书，了解了一些他的知识。最近看了一下自己DIY的作品，但还没有善后的平衡车，鲁棒性不好。反正还没善后，所以等我过段时间，我把算法移植到RTOS上。

http://mpvideo.qpic.cn/0bf234aaeaaaemacaw3onvpfbx6dalpqaaqa.f10002.mp4?dis_k=dc90659188c45b1775ea297a91269fe2&dis_t=1652166809&vid=wxv_1252988756890648579&format_id=10002&support_redirect=0&mmversion=false

看完RTOS的书之后，最近我又找了一本书关于《编程艺术》。了解编程之美。自己也学到一些思路，编程遵守17个原则：

• 模块原则（使用简洁的接口拼合简单的部件）

要编写复杂软件而又不至于一败涂地唯一方法就是降低其整体复杂度--用清晰的接口把若干简单的模块组合成一个复杂软件。如此一来，多数问题只会局限于某个局部，那么就还有希望对局部进行改进而不至牵动全身。

• 清晰原则（清晰胜于机巧）

维护如此重要而成本如此之高，在写程序时，要想到你的代码不是写给计算机看，而是给人方便阅读维护。

这意味着代码注释。在选择算法和实现时就应该考虑到将来的可扩展性。而不要为了取得程序的一丁点性能提升就大幅度增加技术的复杂度和晦涩性，不能做这种买卖。这不仅仅是因为复杂的代码容易产生bug，也因为它会是日后的阅读和维护工作更加艰难。

• 组合原则（设计时考虑拼接组合）

如果程序之间不能有效通信，那么软件就难免会陷入复杂度的泥淖。

要让程序具有组合性，就要是程序彼此分离。在程序的一端尽可能不要考虑另外一端的程序。而完全不惊扰另一端。

设计时代码是，应该想想如何把复杂的交互程序跟粗活的算法程序分离开，使每个部分单独成一块，通过简单的命令或者协议将其组合起来。

当程序无法自然地使用序列化、协议形式的借口是，应该尽可能多的编程元素组织为一套定义好良好的API。至少可以通过链接调用程序或者可以根据不用任务的需求粘合使用不用的接口。

• 分离原则（策略同机制分离，接口同引擎分离）

策略和机制揉成一团会带来两个负面影响：一来会使策略变得死板，难以适应用户需求的改变，二来也意味这任何策略的改变都极有可能动摇策略。

把程序分为可以协作的前后端，前端实现策略，后端实现机制。

• 简洁原则（设计要简洁，复杂度能低则低）

软件以简洁为美，人人对庞大复杂的东西群起而攻之--这是一个非常看重简单解决方案的工程传统，总是设法将程序系统分解为几个能够协作的小部分，并本能抵制任何过多噱头来粉饰程序的企图。

• 吝啬原则（除非却无它法，不要编写庞大的程序）

“大”有两重含义：体较大，复杂程度高。程序大，维护起来困难。对于花费大量精力设计出来的东西难以割舍，结果导致在庞大的程序中把投资浪费在注定要失败或者并非最佳的方案中。

• 透明性原则（设计要可见，以便审查和调试）

往往调试的时间占据了开发的大部分时间，所以一开始就多做点工作以减少日后的调试的工作量会很划算。一个有效的减少调试工作量的方法就是设计时充分考虑吧透明性和显见性。

透明性：一眼能看出软件是在做什么以及怎么做。

显见性：程序带有监视和显示内部状态的功能。

• 健壮原则（健壮源于透明与简洁）

软件健壮指软件不仅能在正常的情况下运行良好，而且在超出设计这设想的意外条件下也能够正常运行。

大多数软件经不起磕碰，毛病很多，就是因为过于复杂，很难盘通考虑。如果不能正确理解一个程序的逻辑，就不能确信其是否正确，也不能在出错的时候修复它。

要让程序变得健壮，就是让程序的内部逻辑更易于理解。要做到这一点主要有两种方法：透明化和简洁化。

• 表示原则（把知识叠入数据以求逻辑质朴而健壮）

数据要比编程逻辑更容易驾驭，所以，如果要在复杂数据和复杂代码中选择一个，宁愿选择前者。在设计中，应该主动将代码的复杂度转移到数据之中去。

• 通俗原则（接口设计避免标新立异）

最易用的程序就是用户需要学习新的东西最少的的程序，最易用的程序就是最切合用户已有知识的程序。接口设计应该避免毫无来由的标新立异和自作聪明。

• 缄默原则（如果一个程序没什么好说的，就保持沉默）

若程序没有什么特别之处可讲，就保持沉默。行为良好的程序应该默默工作，决不唠唠叨叨，碍手碍脚。沉默是金。

• 补救原则（出现异常时，马上退出并给出足量错误信息）

软件在发生错误的时候也应该与在正常操作的情况下一样，有透明的逻辑。最理想的情况当然是软件能够适应和应付非正常操作。如果没有补救措施，却悄无声息的埋下奔溃的隐患，直到很久才显示出来，这就是最坏的一种情况。

• 经济原则（宁花机器一分，不花程序员一秒）

通俗的说，教会机器如何做更多低层次的编程工作。

• 生成原则（避免手工hack，尽量编写程序去生成程序）

任何手写的代码都是滋生错误和延误的温床，由程序生成代码总是比手写代码廉价而且更值得信赖。这也就为什么会有编译器、解析器的原因。

• 优化原则（雕琢前先得有原型，跑之前先学会走）

先制作原型，在精雕细琢。

不要不知道瓶颈所在就匆忙进行优化，这可能是唯一一个比乱加功能更加损坏设计的错误，从畸形的代码到杂乱无章的数据布局，牺牲透明性和简洁性而片面追求速度。很容易滋生无数的bug。

• 多样原则（决不相信所谓“不二之门”的断言）

不要设计一个僵化、封闭、不愿与外界沟通的软件。

• 扩展原则（设计着眼未来，未来总比预想快）

要为数据格式和代码留下扩展的空间，否则就会发现自己常常被原先的不明智选择捆住了手脚，因为你无法既要改变他们又要维持对原来的兼容性。