封装中修改旧代码的时机

只是单纯为了代码的统一、整洁、简练去修改旧代码是十分不可取的，这并不是镇长去小学视察

以 Antd 的 RangePicker 为例，起初写A模块下的几个页面时，有几处出现了下面的重复代码

...
    this.state = {
      queryParams: {
        minCreateTime: '2020-7-8',
        maxCreateTime: '2020-10-2',
      },
    };
...
    const { queryParams } = this.state;
    const minCreateTime = queryParams.minCreateTime
      ? moment(queryParams.minCreateTime)
      : null;
    const maxCreateTime = queryParams.maxCreateTime
      ? moment(queryParams.maxCreateTime)
      : null;
...
        <DatePicker.RangePicker
          placeholder={['起始', '结束']}
          showTime={{ format: 'HH:mm' }}
          format={'YYYY-MM-DD HH:mm:ss'}
          value={[minCreateTime, maxCreateTime]}
          onChange={(dates) =>
            this.onUpdateQueryParams({minCreateTime:dates[0].format('YYYY-MM-DD HH:mm:ss'),maxCreateTime:dates[1].format('YYYY-MM-DD HH:mm:ss')})
          }
        ></DatePicker.RangePicker>

当时并非是主要矛盾，也就自动忽略了，复制黏贴一下也不是很难，也不知该怎么封装...

结果写B模块时突然就有了灵感，上面的代码都做了哪些事情呢？

防止 null
DatePicker.RangePicker 的一些默认属性
将后台给的字符串转换成 moment，最后再转换为字符串传回去。

因为是新的封装，过程就很省事了，基于上述，粗略封装如下：

const YYYYMMDDHHmmss = 'YYYY-MM-DD HH:mm:ss'
import moment from 'moment';
interface PageRangePickerProps extends Omit<RangePickerProps, 'onChange'> {
  startTime: string;
  endTime: string;
  onChange: (startTime: string, endTime: String) => void;
}
interface PageRangePickerState {}
class PageRangePicker extends React.PureComponent<
  PageRangePickerProps,
  PageRangePickerState
> {
  static defaultProps = {
    startTime: null,
    endTime: null,
    placeholder: ['起始', '结束'],
    showTime: { format: 'HH:mm' },
    format: YYYYMMDDHHmmss,
    onChange: () => {},
  };
  public render() {
    const { startTime, endTime, onChange, ...restProps } = this.props;
    let startTimeMoment = startTime ? moment(startTime) : null;
    let endTimeMoment = endTime ? moment(endTime) : null;
    return (
      <DatePicker.RangePicker
        onChange={this.onChange}
        {...restProps}
        value={[startTimeMoment, endTimeMoment]}
      />
    );
  }
  private onChange = (dates: RangePickerValue) => {
    const startTime = dates[0].format(YYYYMMDDHHmmss);
    const endTime = dates[1].format(YYYYMMDDHHmmss);
    this.props.onChange(startTime, endTime);
  };
}

export default PageRangePicker;

通过Omit 剔除了原本的onChange 声明，直接支持传字符串
继承antd 的 RangePickerProps 依然可以得到提示
static defaultProps 设置默认属性

可以预见的坑是，这个组件和Form结合会有问题...

那么问题来了，我到底有没有必要把之前旧的写法都一一改成现在这样

衡量的核心不在于有没有时间、需要多少时间，而在于有没有这个必要。

假设A模块有3个页面使用旧的写法，而B模块2个页面使用旧写法，第三个页面时完成了封装。

显然B模块还在开发阶段，替换原有的写法是很有必要的，而对于A模块，如果已经提测或是上线，则没有必要去改动。

什么时候去改动取决于任务的分配，比如，当用户没有选择具体的时分秒，我们希望是00:00 - 23:59

对于PageRangePicker 只需要加上

showTime={{
   ...
   defaultValue:[moment('00:00:00','HH:mm:ss'),moment('23:59:59','HH:mm:ss')]
}}

对于旧代码，则可以替换新的组件，类似这种的更改正是展现我们对代码追求的好时候。

再往前后想一想，当RangePickerProps 出现设计的瑕疵时，太糟糕了！，这意味着要在组件内部耦合很多逻辑来满足需求，什么时候需要写一个新的组件，什么时候替换旧有的组件

坦白的讲，大家都是成年人了，一定要理性的看待问题，而不是一味的讲究代码的整洁、一致性。

没有完美的代码，不说业务需要的变化，即便是技术本身的迭代与演化，甚至于我们自身的不断成长，任何人去看一段代码，想要挑出点毛病总是很容易的，关键是要看所谓的"毛病"带来了怎样的影响

更改逻辑需要耗费大量的时间？成员在使用的时候容易发生一些隐型问题？bug数目多和这个有关？

如果只是一些感性上的东西则大可不必，诸如，我觉得这样不合理、这个命名有点怪、这样写不够清晰，这样不够优雅、出现两个版本会很难维护、或者在使用的时候遇到一些挫折就觉得不好用，使用封装好的东西，就是要按照人家封装的思维去使用，而不是按照自己的意志，这一点如果不搞清楚，在如今的前端世界是要吃很多暗亏的！

我经历过很多次，有些人在不了解业务以及封装涉及范围的前提下，就随便的改动，或许他们认为自己足够了解，结果造成了隐性的问题，这一点在团队协作中十分可怕。

必须要承认，好的封装能给工作带来极大的便利，对于工作效率的追求自然是不能停止的

但当我们大刀阔斧的一展自己对代码的追求与理解时，先要扪心自问对于所要做的事了解多少、需要投入多少时间、需要做哪些测试、会波及那些业务、能够获得怎样的回报，毕竟封装是一种投资。

2020/7/11 23:46，知乎上的一个回答，太美了！