为什么我们的代码难以维护(草稿)

前端之家收集整理的这篇文章主要介绍了为什么我们的代码难以维护(草稿)前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

有没有想过这个问题,为什么我们的代码难以维护,为什么我们偏向于开发全新的系统,却不愿意改造现有系统,甚至是我们自己开发的系统。这个想法突然从我脑钻了出来,然后我思考了大概十分钟。

我认为我们系统难以维护的原因主要有三个:

一. 系统抽象级别不够

其实很多时候我们太急于实现功能,导致代码太过于具体,没有得到有效的抽象或者抽象层次不够。抽象层次不够会导致代码难以复用,难以修改,难以阅读。

1.1 代码封装层次

比如我要实现一个actionSheet,根据系统状态不同展示不同的actionSheet,并且根据用户最终选择的action,执行响应的操作。 这是一个在移动端非常常见的交互行为。

看一下我们不同的抽象级别的实现:

function handleEvent(e) {
   // 使用者只需要构造mapper即可,无需关心其他逻辑
   const buttonMapper = {
      "2": [
        {
          text: "action one",onClick: this.onButtonClick.bind(this,employeeStatus,username)
        },{
          text: "action two",onClick: this.props.leaveJob
        }
      ],"3": [
        {
          text: "action three",onClick: this.props.leaveJob
        }
      ]
      ]
    };
   return showActionSheet(buttonMapper,e.target.value)
}


// 系统抽象(将actionSheet抽象)
function showActionSheet(buttonMapper,idx = 0, title = "",cancelButton = "取消") {

    const actions = buttonMapper[idx];
    const BUTTONS = actions.map(q => q.text);

    actionSheet({
      title,cancelButton,//取消按钮文本
      otherButtons: BUTTONS,onSuccess: ({ buttonIndex }) => {
        actions[buttonIndex].onClick();
      }
    });
}

如果代码抽象层次太低,会导致代码很难复用,难以阅读和维护。 比如下面的代码

function handleEvent(e) {
      const BUTTONS = isTrue
        ? ["action one","action two"]
        : ["action three"];
        actionSheet({
        title:'title',cancelButton: "取消",//取消按钮文本
        otherButtons: BUTTONS,onSuccess: ({ buttonIndex }) => {
          if (isTrue) {
            if (buttonIndex === 0) {
              // xxxxxx

             
            } else if (buttonIndex === 1) {
               // xxxxx
            }
          } else {
            if (buttonIndex === 0) {
             // xxxxx
            }
          }
        }
      });
}

1.2 业务思维层次

比如有这样一个需求。 后台给定一个JSON,结构如下:

{
  history: [{},{}],baseInfo: {name: '张三',dept: '工程部'},bonus: {
    a: '100',b: '210'
  }
}

需要将history以 timeline形式展示

baseInfo按照form表单形式全部展示,bonus按照Box形式展示。

这种需求非常常见。

当时我做这个需求的时候想法是这样的:

1. 拆分组件。

我需要写一个timeLine组件。使用方法大概是这样:

<Timeline>
  <Timeline.Item>创建服务现场 2015-09-01</Timeline.Item>
  <Timeline.Item>初步排除网络异常 2015-09-01</Timeline.Item>
  <Timeline.Item>技术测试异常 2015-09-01</Timeline.Item>
  <Timeline.Item>网络异常正在修复 2015-09-01</Timeline.Item>
</Timeline>

我还需要一个form组件,使用方式大概是这样的:

const mapper = {
  name: "姓名",dept: "部门",};

<TextForm data={baseInfo} labelMapper={mapper} />

我还需要一个Box组件,用法如下:

<Box cols={4}>
          <BoxItem
            text={d}
            suffix="元"
            linkText="贡献奖"
            ceiling={9999}
          />
          ...
          <BoxItem
            suffix="元"
            text={c}
            linkText="全勤奖"
            ceiling={9999}
          />
        </Box>

2. 在容器组件中拼装。

以timeline为例。

<TimeLine>
              {history.map((item) => {       
                return (
                  <TimeLineItem
                    key={item.key}     
                    date={item.effectTime || ""}
                    color={item.key > 0 ? "gray" : "blue"}
                  >
                    {item.title}
                  </TimeLineItem>
                );
              })}
            </TimeLine>

后期这种抽象方式还是不够,还可以进一步抽象,经过进一步思考,我采用如下方式抽象。

以timeLine实现为例:

const renderItem = item = <Timeline.Item key={item.key}            
   date={item.effectTime || ""}
   color={item.key > 0 ? "gray" : "blue"}
>
{item.title}
</ Timeline.Item>

const renderList = ({children}) = <Timeline>
{children}
</ Timeline>

const renderTimeLine = compose(renderList,map(renderItem))

renderTimeLine(data.history)

本质上渲染一个timeline组件由两部分组成,渲染外层wrapper,渲染里层items。 渲染items又可以看作渲染items执行n遍。 于是问题简化为 1.生成wrapper 2. 生成item。 经过这样抽象,你会发现上面例子的baseInfo和 bonus 其实也可以抽象为上面的“模型”。

二. 系统状态组织混乱

其实将系统抽象为状态,从状态映射视图也是对业务进行的抽象。有一个名词叫有限状态机,其实系统中的状态通常都是有限的,系统总是在有限状态中的一个节点。也就是说系统只是状态在时间节点上的分布。前端有很多状态管理容器,有名的有redux, mobx, vuex,statex 等。拿redux来讲,redux 中最核心的reducer, 其实就是reduce,只不过reduce 遍历的是给定的list。 而redux 遍历的是随时间变化的action list。

系统中状态混乱,彼此之间关联是造成代码难以维护的另一个重要原因。如何组织好系统状态是重要工作,我们不可能依靠某一个工具就可以很好组织我们的app state。状态管理有很多问题需要解决,比如状态如何组织,如何共享,如何保证不污染, 如何优雅订阅状态变更,如何优雅地修改状态等等。

有这么多问题,我们来看下redux(包括react-redux)对上面这些问题做了哪些努力。

1. 状态如何组织

redux是单一数据源,对于业务复杂的,可以写多个reducers,然后combine reducers。

2. 如何共享

redux每次store改变, 都会导致provider 中store变更,从而导致子组件刷新。然后子组件订阅单一数据源的部分key。

3.如何优雅订阅状态变更

如上

4. 如何保证状态不相互污染。

redux通过immutable方式修改state。

5.如何优雅地修改状态

redux 通过diapatch action 修改 state。 dispatch一个action,相当于往actions数组里面push一个action。然后reduce 当前应用状态的state。 通过actions 就可以还原,回退,从而还原“案发现场”

上面这些只是说了redux对状态管理做的努力,再好的工具,如果使用者本身技能不够好,也会把工具用得一团糟。对于使用者来说,一定要明白引入工具解决了什么问题,这样才可以更好的使用工具。对于app state的管理,并不是说引入了redux,就要将应用全部state都放在redux中管理。另外也不是所有应用都适合状态管理框架(应用复杂度要和框架复杂度匹配)。因此这就需要我们对app state有一个完整的理解,恰当地管理app state。一般而言,app state分为两部分,一部分是需要共享的状态,另一部分是组件独享的状态。如何区分比较简单,关键是使用者有去区分的”意识“。 而redux做状态共享非常方便,但是独享的状态使用redux就没必要了。对于完全不需要共享的状态,可以维护在上层container组件中,将这些脏活累活讲给container组件,然后将独享状态分发,保证下层组件的**纯粹性**。

不管是独享还是共享希望都可以从上面提到的几点去思考。

> 在这里,并不其他组件没有使用当前组件状态就不是共享状态,这需要你对应用未来的理解。因为可能出现这个状态本身就应该是共享的,只是目前暂时不共享的情况。

三. 对于非自己开发的功能不熟悉,不明白功能的具体业务场景。

对于这种,从代码 层次上是无法缓解的。那么就必须从文档和注释上下功夫。文档的话我觉得对于一个需求应该有完善的产品文档,UI设计文档和开发文档。 对于一些业务最好可以给一个产品文档和UI设计文档的链接。 因此推荐将业务讨论的过程通过外部文档记录,并将记录过程于文档结合,方便相关人员查看。

// prd: http://www.xxx.com/1233423x/index.html
// sketch: http://www.xxx.com/1233423x/index.html

class PageA {
  xxxxxx
}

适当增加注释,还原当初业务场景:

function renderHistory() {
    // 由于历史遗留,需要处理旧数据,因此这里需要做兼容处理
    // xxxx
}

猜你在找的React相关文章