「避免返工」的一个重要手段就是熟练掌握设计模式

持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第3天，点击查看活动详情

在工作中会有一个这样的现象：划水三天的同事，他工作进度要快于七天一直在加班的同事。另外前者还会抱怨产品经理是个二货每天变需求，后者却继续划水沉默不语。

换个角度说，需求的变更从产品本身来说，它是产品生命周期中不可或缺的一个属性。因为一层不变的产品，它不会被用户认可。如果市场上的所有产品都一样的功能，那绝大部分程序员就只有一条路：失业。

既然需求的变更是正常的，那程序员需要做的是如何在变化的需求中寻找「变化点」，找到「变化点」以后快速跟进它的变化轨迹。

那么如何找这个变化点呢？

假设，我是知乎的员工。需要让我实现「文档上传」的三种方式。前端和后端都要对三种文档方式进行区分，然后处理相应文档类型的业务。代码如下：

//文档处理
public void documentProcess()
{
   if(documentType='doc'||documentType='docx')
   {
     //处理word
   }
   else if(documentType='pdf')
   {
     //处理pdf
   }
   else if(documentType='md')
   {
    //处理markdown
   }
}

如果产品部门提出需求，增加Excel类型文档的处理。怎么办？

分三步走：

①找出变化点：文档类型

②分离：分离不同文档类型对应的处理业务

③查找对应的设计模式，进行解耦，让它满足设计原则

按照三个步骤对上述代码进行修改如下：

public abstract class State
{
  public abstract void DocumentHandler(Work w);
}

public class DocState:State
{
  public override void DocumentHandler(Work w)
  {
    w.SetState(new PdfState());
  }
}

public class PdfState:State
{
  public override void DocumentHandler(Work w)
  {
    w.SetState(new MarkdownState())
  }
}

public class MarkdownState:State
{
  public override void DocumentHandler(Work w)
  {
   //如果追加状态的情况下，在这里通过SetState设置衔接
  }
}

像上述方式这样改造，如果再追加对应的文档处理，不论增加多少种，只增加相对应的文档处理程序便可以完成。不会干扰原有的业务。

如果产品经理在快下班的时候来找你要求添加文档处理方式或者删除文档处理方式，那就变成了仅仅处理一个类型的问题。和其他文档类型的业务毫无交叉。在这种情况下就节省了原有业务的分析时间和重构时间。

省下来的分析、重构时间就可以用来划水、摸鱼。