如何重构一个大型历史项目——经验详情页改版总结

原文网址：http://yanhaijing.com/program/2016/04/14/how-to-reconstruct-a-large-historical-project/

挺长时间没写博客了，你以为我去玩了吗？其实我是去做了一个大项目。

开场之前先来个热身吧，最近撸了一个小游戏《看你有多色》，源代码在这里，欢迎大家交流。

项目做完后在内部做了次分享，本文就是这次分享的文字版，警告：本文略长，建议备好咖啡，来一段愉快的阅读之旅吧，我保证不会让你失望的。

本文将会介绍如何重构一个大型历史项目的方方面面。

本文将会按照下面的目录展开分享，本文仅讨论技术。

简介
准备
时间
团队
技术
架构
边界
收益
总结

简介

这次要改版的是经验最重要的页面之一——经验wap详情页，流量巨大，历史悠久，就导致这必然是一个复杂的问题。

准备

项目上的准备就是PM提供的MRD和设计师提供的PSD，前端的准备基本是先熟悉旧版页面的逻辑，我本人其实也不熟悉这个页面。

时间

项目开始前肯定要给出排期，那么接下来就说排期和时间管理的问题。

预估时间

前端项目的时间预估最准确的就是从UE图预估，拿到UE图后将其拆分成各个组件，然后评估每个模块的开发时间，其实思想就是分治，将不可评估任务拆分成可评估任务。

这次的项目因为是就模块改版，还有一个维度就是看就模块老代码，这次老模块是一个X，工作量未知，所以留了一些buffer，结果还真派上了用场，在老代码里跌倒了几次。/(ㄒoㄒ)/~~

举个例子：

导航 2h
头部 3h
尾部 4h
。。。

风险

这次遇到可能影响进度的风险点主要都是来自经验的老代码，历史数据结构，各种边界case。

有些东西，你不看老模块的代码是不可能知道的，所以还是要把老代码全部看懂才行。

合作

本次两个人一起开发，就涉及到如何合作的问题，在开始之前我制定了一些规则。

才学了语义化的提交信息，我准备尝试一下，我指定的规范在这里《我的提交信息规范》。

最后我们一共提交了100多个commit，基本上等同于100多个小功能，我提倡勤提交，这样方便两个人同步进度。

因为页面被拆分成了模块，而我们的项目中支持模块化开发，所以两个人合作起来还是挺容易的，每个人负责自己的模块，互不干扰。

效率

根据人月神话来说，团队人越多可能效率越低，那么如何保证两个人的效率和一个人时是一样的呢？我们有如下利器来保证：

模块化开发
良好的基础框架
合理的项目（功能）拆分

技术

接下来说说我们这次改版的技术细节吧。

指导原则

技术上大体可以分为以下几类：

新技术
陈旧技术
成熟技术
稳定技术

对于新技术我们还是持敬畏的态度，这次的选型就是选择成熟稳定的技术。

技术栈

来说说我们这次的技术栈吧

fis-plus
sass
~~es6（新技术）~~
~~promise（新技术）~~
template
zepto，gmu

架构

架构是个最大的问题，我们从下面四个方面来说说：

目录
结构
样式
行为

模版

我们用的是smarty模版，对应的就是结构——HTML，比如我们的模版文件是index.tpl，其内部有各个组件拼装而成。

模版可以继承，我们的业务模版都继承通用模版，这样的好处就是方便给所有页面添加通用的一些东西。

还可以在父模版挖一些坑，在自模版填，这个功能叫做block。

举个例子吧，比如如下图我们在父模版挖一个title的坑，因为每个页面的title可能都不一样，在子页面我们会向填坑

再来说说widget，一般的一个页面会被拆分成一个个模块（组件），然后又每个模块去拼装页面。

举个例子，下面左边就是拆分完的页面，右边是伪代码。

样式

这次改版我们的样式决定使用sass这个预处理器。

我们将样式精心分类，总共有以下三类：

公用css
组件css
mixin

我们定义了两个mixin：

@mixin clearfix() {
  &::after {
    content: "";
    display: table;
    clear: both;
  }
}

@mixin size($width, $height: $width) {
  width: $width;
  height: $height;
}

_variables.scss里面我们只定义了几个能够抽取成公共的颜色变量

再来说说组件样式，一个典型的组件代码大概如下：

@import "mixin";
@import "variables";

.wgt-step-read {
    background: $bg-color;
    a {
        color: $color-primary;
    }
    .arrow {
        @include size(5px, 9px);
    }
}

其编译后的css如下所示

.wgt-step-read {background: #fff;}
.wgt-step-read a {color: #333;}
.wgt-step-read .arrow {width: 5px; height: 9px}

用了sass后我们可能会忽视嵌套问题，任意嵌套，我们规定嵌套不能超过三层。

小贴士：这里介绍一个css选择符的两种逻辑，我推荐的其实是中庸思想，不走极端。

.wgt-step-read .arrow // 嵌套
.wgt-step-read-arrow // 组合类名

.wgt-step-read ul p span // bad
.wgt-step-read .pv // 添加类名，解决上面嵌套层级的问题

再来说说我们样式的指导原则：

wgt前缀（区分模块和其他类）
嵌套不要超过三层（添加类名解决）
合理使用类名（语义）
合理使用mixin（区分extend）
DRY

最后说说布局之争，项目开始时我们有如下两种布局可以选择：

最终我们选的还是传统的px，因为我们为我们是知识型页面，页面多为文字；其次px比rem更简单。

在我的逻辑看起来我用大屏是未来看到更多的文字，而不是更大的字体，如果我想看更大的字体我自己调整字体就好了。

行为

行为这里展开讲的地方不太多，因为按照模块拆分以后，每个js都不太大，强调的一点就是不要再拼接字符串了，而是改用前端模版。

边界

边界这块在内部分享中介绍了很多内容，这里绝大部分都不能展开叙述，因为可能会涉及到一些内部的数据；当然我会将一些比较通用的知识，不涉及经验的具体细节。

起源

对于经验而言，经过了多年的沉淀，已经没有人能够熟悉的知道他的方方面面，那么我们如何理清楚，经验的一些属性、分类、边界情况呢？

答案就是追本溯源，而不是舍本逐末，我开始的出发方向就错了，我一头跳进了某一个case中，还好后来及时修正了这种错误的思想。

举个例子，我们是如何追本溯源的呢？大概从以下一些方面：

产生经验的地方
后端数据
老代码

最直观的其实就是生产经验的地方，也就是说每个case都能在这里找到出处。

其次就是看模版数据，再次就是看经验的老代码。

总而言之，经验的复杂程度超乎我的想象。

一条线的变迁

有太多内容都不能公开给大家，想来想去就说这个吧，还比较有意思。

对你没看错，就是下面这条线，就是她！！！

看看我是怎么实现的吧，如下图，对你们看错，separator-line就是这条线

不知道你会不会鄙视我，我选择了一种不太优雅的实现方式，为了装饰性增加了多余的html。

不知道你会如何实现这条线，来说说我的实现方式吧。

最开始时，我把它放在了tag-wp的bodder-bottom上，后来我发现tag-wp竟然可能不存在，o(╯□╰)o

我想那我就放在abstract-wp上吧，也许聪明的你猜到了解决，是的，这个元素也可能没有。

最后我只能搞一个单独元素出来了，o(╯□╰)o

这个问题其实我们也可以换个思路，就峰回路转了，我们可以不把这条线考虑成装饰性元素，而是考虑成分割线，是不是就好理解了呢，分割线就是该用一个元素来表示（hr），虽然我这里没有用hr，但是内心总是不那么忐忑了，谁让我是强迫症呢，不写出优雅的代码我会吃不下，睡不着的。

收益

最后来说说这次改版的收益吧。

可维护性

旧的代码，陈年失修，而且一直在打补丁，自我感觉改版后，可维护性上了一个量级，这里就不能给大家贴代码展示了。

不过有一个数据还是可以拿来展示一些的，其实新旧版都要处理同样的逻辑的，同样的逻辑旧版用了107行，而新版只用了73行。

总结

这次改版让我明白了一个道理，页面中的任何元素都可能没有，需要考虑到容错处理；设计不能一蹴而就，往往需要反复打磨，反复修改，或者推翻重来；凭空的设计完美却不实用，好的设计必须结合产品内容，项目细节。

优点

这次改版我认为在下面几点上都是做的不错的地方：

架构
新技术
团队合作

缺点

如果说优缺点的话，我认为唯一的缺点就是时间的预估了，时间预估上的失误还是很明显的。如果时间不能准确预估需要留好buffer。

表扬

我需要表扬我队友的效率，开发真的很快。比我快太多。

批评与自我批评

我要批评我队友的效率，复制粘贴了太多老代码，自己也没看，而且代码规范都没遵守。

我也要批评我自己的效率，想得太多，做的太少，应该提高自己的效率。

附

本文的百度脑图。