Libx

代码整洁之道-阅读笔记

字数统计: 808阅读时长: 3 min
2019/05/30 Share

代码问题:

  • 函数存在副作用,调用时可能对函数的结果作了隐含的假设;
  • 函数或类的职责繁多,不敢轻易修改,因为不知这种变化会影响到哪些模块;
  • 热点代码被频繁变更,职责被包裹了一层又一层,没有清晰的边界;
  • 在系统某个角落,隐藏着伺机而动的Bug,当诱发条件具备时,就会让整条调用链瘫痪;
  • 不同的业务场景包含了不同的例外场景,每种例外场景的处理方式都各不相同;
  • 同步处理与异步处理代码纠缠在一起,不可预知代码执行的顺序。

关于业务代码:

业务代码特点:逻辑复杂、前后依赖多、可复用性差、迭代周期短。

  • 合理冗余其实也是一种重构,根据业务逻辑和代码规模,做相似抽象还是代码冗余,这其实也是渐进式重构的一种体现。无论采用何种方式,只要能把业务逻辑表达清楚,让代码始终保持良好的可读性和可维护性,就OK。
  • 相似抽象还是合理冗余 when? how?why?非常容易遇到一种代码
  • 我非常喜欢Redux 中的一些思想:state 就是普通的 object,reducer 就是普通的 function,action 也是普通的 object。简单,强大

渐进式重构

关于函数

传参

在编写web应用时,尤其是像使用Vue或者React的时候,应用需要维护大量的状态,这时函数之间也会不可避免的和状态之间扯上关系。在函数之间,状态的传递和维护使用哪种方式比较好呢?

比如

data(){
return{
userGroup:1
}
}
methods:{
bar(){
operation(this.userGroup)
},
far(){
this.userGroup = [xxx]
bar()
}
}

或者是将数据使用参数进行传递

methods:{
bar(data){
operation(data)
},
far(){
bar(1)
}
}

这是我非常疑惑的地方,看起来使用前者是非常不明智的选择,因为其实相当于创建了多余的全局变量,这很明显违背了一些基本的原则。但是在实际的开发中,比如需要维护较复杂的应用,而某个状态需要在多个函数中使用,并且维护的数据类型属于数组等数据量比较大的类型时,在以数据驱动的Vue中,如果按照数据驱动思想去编写代码,使用data维护数据确实是比较简单并且省事的方法。

但简单可能会带来无序,在多个函数中对data的某个数据进行修改,意味着状态管理其实是比较混乱的。当需要加新的需求,然后你发现更改一行代码可能需要顾及到其他地方的数据变化。这其实在使应用的维护性变差。

但是在书中提到了这样的一句话:

最理想的参数数量是零。
并且按照书中的说法,似乎参数的使用是迫不得已才要使用,
而后者的使用会面临以下几个问题:丑陋的标识参数

CATALOG
  1. 1. 代码问题:
  2. 2. 关于业务代码:
  3. 3. 渐进式重构
  4. 4. 关于函数
    1. 4.1. 传参