编程中的坏味道

以下记录的是，我在学习中的一些学习笔记，这篇笔记是自己学习的学习大杂烩，主要用于记录，方便查找

代码中的坏味道： （“找茬”游戏，赶紧消灭）

   1.命名不知其意图，不能表示业务含义。

   2. 重复代码的 意图，少写if 和else 代码。

   3. 避免长函数，静态语言10行解决问题，动态语言5行解决问题，绝对能认的是20行，把大拆小来化解。

   4.避免大类，每个类都要单一责任划分，，对对象，进行 “对象健身操 “，把类写小，越小越好。

   5.避免长参数,变化频率相同，则封装成一个类,变化频率不同的话：静态不变的，可以成为软件结构的一部分；多个变化频率的，可以封装成几个类。

      对于 这种标记参数，一种解决方案就是根据这些标记参数，将函数拆分成多个函数,减小参数列表，越小越好.

   6.避免语句中的 层层嵌套，消除else和 代码圈复杂度。 少用switch语言，用模型替换。

 

##7.避免火车残骸，用封装屏蔽，记住封装和组合的使用。组合由于封装。

##8. 缺乏封装的坏味道: 封装中的set方法，是一个危险的操作，setter 往往是缺乏封装的一种 做法,我们可以用其他方法，替代seter ，把 setter 封装成一个个的函数，实际上是把不可控的修改限制在一个有限的范围内。可变数据是一种坏味道，包含set方法 和 全局数据，我们要限制可变的数据。

##9. 变量要一次性完成初始化 ，list 和map ，变量赋值。

 

 

##10、注意依赖关系的坏味道，（对依赖关系设计 要有 约定），代码应该向着稳定的方向依赖

     后端： Resource/Controller, Service,一个 Resource调用一个 Service, service 层属于我们的核心业务，而 resource 层属于接口,，NewBookParameter 属于 service 层，而 NewBookRequest 属于 resource 层，二者相互独立.

##11.坏味道：保持代码在各个层面上的一致性 ， （ 业务，非业务，业务写到服务层，业务动作，业务细节），

   

##12. 编程语言 有演进，请记住：不断学习“新”的代码风格，不断改善自 己的代码。

 ----------------未完，待完善