代码整洁实践经验
1.用多态代替if/else或者switch/case 2.不要出现重复代码 3.函数行为通过名字表达，不要做隐藏的额外事情 4.一个函数只做一件事，而且应该保持短小，并在一个抽象层级上 5.实现业务逻辑才是关键，为核心业务逻辑的可扩展性留下接口，其他地方保持简单 6.整个系统应该是一个一个的小组件拼凑而成的，需要定义好组件之间的边界，把共同发布或功能耦合强的组件凑成一个模块，各个模块组成分布式系统。需要谨记的是，整个系统是由一个个组件组成的，写好没一个组件，定义好组件间的边界，系统才能简洁 7.保障好系统行为价值的基础上，尽量追求系统的架构价值 8.写代码的时候，先专注业务逻辑，用接口定义好底层实现和三方依赖，实现核心逻辑以后再完善底层实现
整体设计思路
做新功能时，调研一下同类产品的其他扩展功能，也猜想一下未来可能的扩展方向，需要留好口子。
编程范式
结构化编程：结构化编程范式中最有价值的地方就是，它赋予了我们创造可证伪程序单元的能力。这就是为什么现代编程语言一般不支持无限制的 goto 语句。更重要的是，这也是为什么在架构设计领域，功能性降解拆分仍然是最佳实践之一。
面向对象编程：：面向对象编程就是以对象为手段来对源代码中的依赖关系进行控制的能力，这种能力让软件架构师可以构建出某种插件式架构，让高层策略性组件与底层实现性组件相分离，底层组件可必编译成插件，实现独立于高层组件的开发和部署。
函数式编程：限制赋值操作，保障数据安全。
结构化编程是多对程序控制权的直接转移的限制。 面向对象编程是对程序控制权的间接转移的限制。 函数式编程是对程序中赋值操作的限制。
架构
采用好的软件架构可以大大节省软件项目构建与维护的人力成本。让每次变更都短小简单，易于实施，并且避免缺陷，用最小的成本，最大程度地满足功能性和灵活性的要求。
软件架构的终极目标就是最大化程序员的生产力，同时最小化系统的总运营成本。
在通常情况下，一个系统的部署成本越高，可用性就越低。因此，实现一键式的轻松部署应该是我们设计软件架构的一个目标。
系统维护的主要成本集中在“探秘”和“风险”这两件事上。其中，“探秘（spelunking）”的成本主要来自我们对于现有软件系统的挖掘，目的是确定新增功能或被修复问题的最佳位置和最佳方式。而“风险（risk）”，则是指当我们进行上述修改时，总是有可能衍生出新的问题，这种可能性就是风险成本。
优秀的架构师会小心地将软件的高层策略与其底层实现隔离开，让高层策略与实现细节脱钩，使其策略部分完全不需要关心底层细节，当然也不会对这些细节有任何形式的依赖。另外，优秀的架构师所设计的策略应该允许系统尽可能地推迟与实现细节相关的决策，越晚做决策越好。
重复
架构师们经常会钻进一个牛角尖——害怕重复。
当然，重复在软件行业里一般来说都是坏事。我们不喜欢重复的代码，当代码真的出现重复时，我们经常会感到作为一个专业人士’自己是有责任减少或消除这种重复的。
如果有两段看起来重复的代码，它们走的是不同的演进路径，也就是说它们有着不同的变更速率和变更缘由，那么这两段代码就不是真正的重复。
同样的道理，当我们对系统进行水平分层时，也可能会发现某个数据库记录的结构和某个屏幕展示的数据接口非常相似。我们可能也会为了避免再创建一个看起来相同的视图模型并在两者之间复制元素，而选择直接将数据库记录传递给 UI 层。我们也一定要小心，这里几乎肯定只是一种表面性的重复。而且，另外创建一个视图模型并不会花费太多力气，这可以帮助我们保持系统水平分层之间的隔离。
业务逻辑
如果我们要将自己的应用程序划分为业务逻辑和插件两部分，就必须更仔细地了解业务逻辑究竟是什么它到底有几种类型。
关键业务逻辑和关键业务数据是紧密相关的，所以它们很适合被放在同一个对象中处理。我们将这种对象称为“业务实体（Entity）
业务逻辑是一个软件系统存在的意义，它们属于核心功能，是系统用来赚钱或省钱的那部分代码，是整个系统中的皇冠明珠。
这些业务逻辑应该保持纯净，不要掺杂用户界面或者所使用的数据库相关的东西。在理想情况下，这部分代表业务逻辑的代码应该是整个系统的核心，其他低层概念的实现应该以插件形式接入系统中。业务逻辑应该是系统中最独立、复用性最高的代码。
