文章目录
编码向量
软件上，“向量”指代同时表达大小和方向的原则。在这种情况下，我们认为方向比大小优先。对于这里提到的原则，我们应该关注它们指出的方向而不是引入代码库的具体模式。这些原则用于整个软件项目而不仅仅是类和算法。
KISS-Keep It Simple,Stupid
这个原则认为不必要的复杂性对于给定的系统需求而言都是附加的逻辑。
在软件里，经常有很多开发者倾向于过渡设计；因此，KISS很明显是在提醒你带有
全局观的自下而上构建是创建软件的理想方式。
KISS定理的两个推论。
-
完美不是没有东西可以增加，而是没有东西可以减少。
-
保持简单一一尽可能简单，但不能太简单。我们对此补充了一个原因，太简单通常可能是过分简单。而过分简单的软件肯定不是一个好东西。
YAGNI——You Ain’t Gonna Need It
这个原则认为实现需求上没有提到的任何功能都是有问题的。
多余的功能意味着更多编码、调试以及测试、文档。既然YAGNI是一个向量，它就有一个固有的值（即大小），也会给你指导（即给你指明方向）。如果盲目地把YAGNI用到项目，可能会无法提前规划特性当一个相关特性不得不在最后一刻实现时，它需要的工作量可能比提前规划的多。
DRY——Don’t Repeat Yourself
不要草率地把DRY看作避免代码重复的简单建议。它有着更广的含义。软件开发流程的每个方面以及每个可交付成果都应该只有一个可信的明确的表现。
DRY肯定与代码重复有关，但它也涉及数据模型、服务、存储、测试以及文档。
DRY教会你一种处事方法。你应该避免保持系统不同部分同步的麻烦。如果你要改变任何地方，你应该只做一次，一次就够了。
用到代码时，DRY就变成某种有且只有一次的建议了。在应用程序里完成给定操作的代码你只写一次。换句话说，它在概念上类似于关系型数据模型的范式。一块代码只有一个明确的实现是重构的首要目标；也因为这样，实际上做到的要比看起来的难。
说，别问——Tell,Don’t Ask
说，别问是对象建模的启蒙原则。
就OOP的基础而言，创建的软件实体可以包含数据并暴露某些行为。这正是“说，别问”背后的观点。
在设计一个接口时，避免请求数据并在某个外围逻辑容器处理；相反，告诉接口基于某些明确的数据执行某个行为。把数据和行为绑在一起可以帮助你建模，因为它更贴近观察到的现实。
例如：“亲爱的，你正在做什么呢？忙吗？”不如“亲爱的，我需要你把垃圾倒掉。”更简单直接。