代码优化：度与平衡

Peipei Wong 8月 03, 2018

代码需要及时优化，但是什么的优化是恰当的呢？什么优化是不恰当的呢？

这个时候需要优化了

我有两个container：一个具有筛选功能、一个不具有筛选功能，但是他们有共同的属性：list为空的时候，都显示没有数据；并且都具有瀑布流的功能。但针对目前只有这两个container的时候，我可以不进行相同功能的提取。但是，第三个container出来了，它与之前的两个container都不相同（数据获取的方式与前两者不同），但是具有相同的特性。
在我准备写的时候，我发现再让我写一遍瀑布流的功能很别扭，这个时候，就应该考虑优化代码了。
于是，我比较了这三个container的相同性之后，开始进行分层处理。

// fetch 数据层
// 解析数据层
// 判断是否与内容以及增加瀑布流功能层
// 内容显示层

分层处理后，代码的重复性减少，代码层级变得更清楚，架构也变得稳定。
因为使用React去进行开发的，这样的划分带来的最显著的特点就是组件化，即使以后出现新的数据源，这样的分层也会很灵活。
以上是我做的一个我觉得很棒的优化。我放下手头的活，写写画画思考了一会，经过分析得出这是最好的一个处理方式，确定好方案，撸起袖子，开始干活！

以下优化不可取

写了好多组件，都需要用到redux里面的数据，写的mapState那叫一个重复啊，我想着把这一块相同的代码提成一个公用函数。想了就做了，结果当然是得到了反对，并乖乖的改了过去。对方给我的理由是：mapState本来就是标示从Redux里面去了哪些数据，如何命名。如果写到别的地方，阅读者不能一眼看到你想要的数据类型，反而还需要再去查别的文件，这种做法是不恰当的。

2.技术栈现在用的graphql + apollo，所以大部分组件都是以这样的格式开头的：

@graphql(QUERY, {
  options: {
    variables: {
      // params
    }
  }
})
@WaterFallWrapper() // 高阶组件
class HomeNewest extends React.Component {
  // bababa
}

我看了很多组件都是这样开头的，心理的优化分子开始作祟，我想再把graphql弄成一个高阶函数，准备这样做的时候，我认真的思考一下🤔，这个包暴露的方法为什么不来一个最精简的方法呢，这么想了想，就没有进行这个优化工作…这个就属于过度优化了…

总结

优化代码的话，最好从架构的方面去入手去进行，而不是仅仅从代码角度去思考

PS: 引用别人的话：过度优化相当想着死后如何分遗产;-)