程序设计：简单设计原则

参考文章：

1. http://www.360doc.com/content/17/0721/07/22573478_672976049.shtml
2. https://www.jianshu.com/p/50429cb1b703

1 五个原则

1. 必须满足需求
2. 尽量减少重复
3. 尽量表达清楚
4. 使用更少的代码元素
5. 以上优先级大致逐渐降低
   接下来对以上几个原则分别进行介绍和举例。

2 分条概述

2.1 必须满足需求原则

软件开发必然是为了实现某一个功能，尤其是开发业务代码，是必要要满足BA提出的需求的，自己平时的练习其实也有一个需求，那就是自己心里的那个目标。
如果做到满足需求？测试驱动开发！
第一步：对需求进行分析，尽量使用流程图和时序图对需求进行示意，使自己清楚究竟要开发什么
第二步：挑选一部分功能进行，先进行类的设计，大致设计一下就行，比如只设计好输入输出，暂时写内部逻辑
第三步：根据挑选的功能和已经设计好的类，编写相应的UT，注意！UT其实就是你以后自己调用这些类时的一个缩影
第四步：以通过UT为目的开始编码
第五步：以相同的方式，逐渐实现更多的功能
因此，“必须满足需求”这一原则，更像是对程序大方向上的一个指导，还暂时没有触及代码设计层面。
但是！如果突然新增的需求，可能会破坏已经写好代码的优雅，毫无疑问，满足金主爸爸或者老板的需求才是唯一出路……

2.2 尽量减少重复原则

写代码的时候，有时候发现，其他地方有好像有相似的代码，不要犹豫！
抽方法！！！
如果不抽方法，还是通过复制粘贴的方式去写这段重复的代码，呵呵，以后要改动逻辑的时候就麻烦不行了，因此，不能偷懒，及时发现相似的代码块，抽方法。
有时候，发现一段代码块前后文基本都没啥关系，不要犹豫，抽方法！！！会出现这种情况一定是你那里设计的不对。
idea中自动抽放的快捷键：选中一块代码。ctrl+altl+m，选好输入和输出，自动抽取一个方法，很是方便！

2.3 尽量表达清楚原则

命名及文档！变量名和方法名要是清晰和准确！比如：
同样是true，在不同的地方请用不同的变量名进行代替，不用贪方便而直接使用true和false进行赋值，比如：

boolean dead=false;
boolean alive=true;
boolean lifeStatus=dead;//比直接使用true false赋值清晰很多
//同样的！用来表示状态的数字也请务必使用描述性的变量名代替！！！！不要用傻×的一个数字……

2.4 使用更少的元素原则

类、变量的类型可见少一点，比如定义一个接口，如果只有一个类实现了这个接口，显然没有必要，这个一个接口的存在显然不符合更少的元素这一原则。
着眼于当下！只着眼于当前的需求！ 让UT逼着我们对原先的代码进行演进！而不要一开始就想好之后很远的事情！重构是最正常不过的事情，不要害怕重构！

3 思考

当你试图增加一个元素时，如果不同时满足前三条原则，那你增加这个代码元素就是完全没必要的，请删除，或者对原先的代码进行演进！
同时，在其他方面，也采用简单设计的思想：

架构设计：

• 我们应该最先考虑的是满足业务架构的系统架构（通过测试，性能、稳定性等）
• 借助DDD来合理的划分微服务（揭示意图，明确限界上下文）
• 提取公共服务组件来分离关注点（消除重复，API Gateway、BFF等）
• 最后，我们在满足了前三点的前提下尽可能简化系统架构中的组件

沟通协作

• 在与客户正式场合的沟通中，我们始终应该明确沟通主题，确定目标（通过测试 ）
• 通过加强结构思考力来提升表达的结构性和清晰度，从而达到言简意赅（消除重复，揭示意图 ）
• 最后，我们达到了前面三点之后尽量不说多余的废话