18

封装中修改旧代码的时机 - 简书

 4 years ago
source link: https://www.jianshu.com/p/d491ca4f41a6?
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

封装中修改旧代码的时机

0.5312020.07.01 21:12:32字数 1,136阅读 115

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

以 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，知乎上的一个回答，太美了！


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK