重构邀请码总结

[liyatang]

仅mark，用词精简

分析业务 & 读源码

业务不仅仅界面所见，还要结合代码了解大概的逻辑。

还要细读代码，揣测用意，把逻辑等等整理出来。

设计数据结构

数据驱动，所以数据结构非常重要。可以一行UI代码没写，但是数据结构要设计好。 一旦设计好，写逻辑和代码都顺手拈来。

以小见大，以 Select 组件为例，有三种list value；list index；list item。

以上三种都各有好处

数据设计

偏向于直接用后台吐的，有时候不一定适用，可能需要重新组装选。

专注

jsx 做渲染， store 做数据。这样UI简单，重构起来也方便。数据在整理维护上也方便，在一个文件内可以一目了然逻辑。

API 数据传递

// 一般倾向于平铺开
function fun1(name, password){
    ...
}

// 如果这个formData链条很长，当我要做formData某个修改的时候，扫的代码就长，比如扫上文、上上文，维护起来就不方便了。
function fun2(formData){
    ...
}

组件化**

比如复制功能，用的 clipboard 库。如果一个页面有复制功能，一般做法是通过 ref 拿到要复制功能的地方，然后加上复制代码功能。如果有两个复制功能，还要搞两个 ref。

如果功能是独立的，可以搞组件的。

class Copy extends React.Component {
    componentDidMount() {
        this.clipboard = new Clipboard(ReactDOM.findDOMNode(this), {
            text: () => this.props.text
        });

        this.clipboard.on('success', () => {
            Tip.success('复制成功');
        });

        this.clipboard.on('error', () => {
            Tip.success("复制失败，请手动复制");
        });
    }

    componentWillUnmount() {
        this.clipboard.destroy();
    }

    render() {
        return this.props.children;
    }
}

<Copy text={...}>....</Copy>

数据库设计

举两个案例

1 关于加上有商户数据库表。
突然加了一个状态字段，那么所有和商户相关的逻辑都需要考虑进去。

2 关于类型。
多类型就老老实实用 type， 而不是依靠某个业务字段来判断类型。比如加了商户类型，存在字段F1即为商户类型1。假设后面又多了商户类型，同时也有F1字段，那么之前对于商户类型1的定义就得变了，这是很不明智的。

认知

认知 -》推翻 -》认知 -》推翻