2016年即将过去，回顾总结项目的时候，发现日常工作中一些值得我们思考的地方，这次选了印象比较深刻的京东云项目，希望本文能对读者有所帮助，文多图少，一目百行的客官请轻虐。

项目变数

由于项目的紧迫性，项目进度基本处于多线并行追赶的状态，产品、视觉、前端三个线边输出边交接，产品和视觉会把重要的框架性的页面先输出给到前端，这样一来，前端得到的交互文档、视觉稿基本是阶段性的，并没有完整的项目逻辑和项目页面可以参考来评估项目的构建方案，项目的公用模块、公用组件、组件管理方式等全局性的内容难以确定，类似这些项目中各种不能确定的信息，我称之为『变数』。『变数』会给构建页面过程带来很多不可预测的问题，这些问题可能会令一部分工作推倒或翻工。

主动获取项目信息

面对这种时间线短、各线并行、存在『变数』的项目，主动获取项目信息尤其重要，个人觉得比较重要的有以下几个：项目整体信息结构、整体的时间线规划、视觉稿的具体输出日期、视觉交接 Deadline、前端开发的周期、前端交接 Deadline、项目各线对接负责人。

这次项目属于改版类，从旧版大概了解到站点频道划分、频道之间逻辑关系、业务模块的引用情况等信息，这次改版产品的逻辑变化不大，主要是视觉的优化。虽然前期视觉给到我们的视觉稿只有站点首页，频道的首页和频道的内页都还在并行进行中，但从旧版站点逻辑和产品交互侧得到的信息以及已出的视觉稿可以确定站点哪些部分可以作为公用组件去制作，也可以大致确定项目的资源目录分布。

对于旧站点常见的组件而在已出视觉稿未体现到的，如侧导航弹浮层，找到产品和交互进一步了解后，得知会在频道首页和内页会用到，亦可以确认作为公用组件制作，并可以提前为这些组件制作评估工作量并选择最佳的实现方案。

整体的时间线规划、视觉稿的具体输出日期、视觉交接 Deadline、前端开发的周期以及前端交接 Deadline，这些信息都是项目时间维度上的信息，这类信息的确认，可以让我们更准确评估工作量（在时间线内是否可以完成所有工作），从而在项目紧急性方面做好更合理的人力投入。

潜在『变数』

我们接到新项目，一般都会考虑以上的因素，主动去获取项目的信息，这些信息都是显而易见的，但有些信息略显隐蔽。

拿到设计稿的时候，发现视觉设计师只提供了一份 1280 分辨率的宽屏版，国内分辨率使用占比名列前 5 的 1024 分辨率并没有兼容，带着疑问找到视觉确认，得知首页会有 1280 分辨率和 1024 分辨率两个版本，适配 1024 分辨率版本会迟一点给到。

对于这种看似不是问题的问题而前期又可以确认的问题，我是一定要去确认的！这种问题在前期看上去并不会成为项目推进的阻力，但是说不定会在项目后期爆发，对项目造成吨暴击伤害。

记得刚入行的时候就亲身经历过联调阶段调整分辨率兼容问题，产品说『我的笔记本电脑首页出现横向滚动条了』，然后去排查了一下，发现产品用了 1024 分辨率，而视觉给到前端的视觉稿只兼容到 1280 分辨率，当时缺少实际项目经验，就默默按照 1280 去做了。当产品找到视觉，视觉回答『立项的时候文档没有写到分辨率兼容情况呀，所以当时只做了宽屏1280了』，最后产品『还是兼容一下吧，做一个窄版适配吧』，再然后视觉和前端就只能『……』。

这种问题两条线人员很容易懵B『O嘴』，而且最终还是需要重新调整适配 1024 分辨率，视觉和前端两条线都需要额外的工时，而这些工时并不在前期规划内，所以最有可能会令到视觉或前端或两者都加班，如果加班在可控的时间内完成的话还算是亡羊补牢，但如果加班后还是影响到项目进展造成项目 delay 的话，那就不是影响视觉和前端两条工作线工作效率这么简单了，这是一种潜在的『变数』，应该如何避免这种『变数』的出现，非常值得我们去思考。

如果前端可以从立项就开始参与和产品、交互、视觉、开发各线大前期沟通的话，每个岗位的同事都可以就各自的专业去衡量评估项目，是不是能更早地去发现一些潜在的『变数』呢？而去执行实现的话是否需要在流程上做出改动？如果因为团队的合作模式不能实现，作为前端，我们是不是应该更主动去找到各线的同事进行沟通？

当然，这仅仅是针对此情况而去考虑的东西，其实我想提出的是，面对『项目变数』我们需要做的就是尽可能及时掌握更多关于项目的任何信息去深入了解项目，对项目未来发展作出预见性的判断从而掌握主动权，而不是静静地等待进入前端流程。项目可见度越高，准备越充分，项目主动性越强，只有 100% 的项目信息确认，才能 Kill the 『潜变数』Tens of Thousands Times
。

方案推动

首页的设计稿包含了很多单色图标，图标复用性很强，同一个图标出现在不同的模块，而且大小又不一样，又需要多态并且兼容 Retina 高清屏。

站在前端角度考虑，PC平台的解决方案，第一时间肯定会想到 iconfont 图标。iconfont 图标已不是什么新鲜的技术，不少同事都在不少项目中都有应用到，可是大家在遇到同一问题使用相同技术的时候，处理方法亦有不同。有的同事可能会自己制作 iconfont 图标；有的同事可能会让设计师提供图标 SVG 文件，利用线上的工具自动生成 iconfont 图标；有的同事可能会把 iconfont 的生成工具介绍给视觉设计师，让视觉设计师生成 iconfont 图标。

站在视觉角度考虑，当然想图标在所以设备都可以高清呈现。不同的设计师经验不一样，有些可能会提供 SVG 文件，有些可能会提供一套1X，2X图，有些甚至会把 3X 图也一起给到前端

当项目同时由多人维护的时候，就可能会出现同一个项目同样的的技术方案出现不一样的协作方式，一旦人员交叉交接的时候，就有意思了。从协作效率上来看是存在一定问题的，因此很有必要让前端和视觉设计师统一一套解决 iconfont 图标的方案。

如何实行？ 个人觉得，最重要的是让大家对问题达成共识，也就是：解决这个问题于工作有何收益？

首先需要站在视觉方角度让他们知道问题痛点，再提出解决方案并希望得到他们的协作，下面我以对话的形式将当时我和视觉沟通的对话内容简单叙述一下（前端：FE，视觉：VD）：

FE：啊宏，这些单色图标数量挺多的呀，复用率又高，很多还有双态，同一个图标还有不一样的尺寸，全部做成图片的话数量很多哇，即使全部合并成 sprite 图，图片的 K 数也会很大呢。最要命的是图标后续不知道还会有多少种色态会扩展，首页还要求适配高清屏呢，这工作量不是一般的小呀。

VD：确实啊，高清屏适配每一个图标我都要给一个 2X 图你，10个图标我就得给你 20 个，如果有双态的话，就得给你40个,这次首页纯色图标就有50个。。。

FE：嗯，会出人命的，主要这些图标都是纯色图标，都做成图片不值得，用 iconfont 图标可以解决，全矢量，还可以用样式控制尺寸大小和颜色，高清屏、尺寸、配色都不是问题呀，省力省时间呢！

VD：666，那这个 iconfont 图标要怎么个搞法啊？我需要做些什么呢？

FE：只需要把图标做成 SVG 文件提供给我就 OK 了呀，网上有 SVG 转 iconfont 图标的服务哈

VD：没问题呀，如果能解决刚才说的问题

FE：是啊是啊！主要是这样处理的话可以节省大家的时间，效率成倍提高的啊，不过生成 iconfont 图标后有些图标会在 windows 显示出问题，有问题的图标需要你用 Ai 再处理一下哟，没问题吧？

VD：没问题啊，总比切一堆图好吧，哈哈~~

FE：好的，那么我们约定好，以后这一类纯色图标我们都统一用 iconfont 图标处理，由视觉这边提供图标的 SVG 文件，然后前端负责生成 iconfont 图标，我会在组内推一下这个处理 iconfont 的流程，麻烦你在视觉组内也推一下这个方法哈，都统一这么处理，看OK么？

VD：好的没问题~~ 6666 ~~~

FE：6666~~

项目最后一共投入了5个人力完成后期的构建，成功统一使用了这个 iconfont 图片处理流程，避免了一大波 icon 的蹂躏：

痛点定位和效率收益是这次协作成功推动的关键点，个人觉得要成功推动一个方案实施，『痛点』及『收益点』必定是核心点。以上仅仅是一个简单的方案推动例子，真正操作起来也不会太困难，但关键是我们需要从每次的工作收益中沉淀点『好西』出来就很好了。

好了，以上就是我在京东云改版项目中对工作流程以及上下线协作中感受比较深的一些思考和总结。其实问题都很常见，也有很多更好的解决方案，但是要将这些问题和解决方案存在的价值转化出来，还是需要我们做完每一次的项目后认真去总结沉淀，最后，做好业务无非几个字，想得周全，助得快乐，踩得深入，跳得出来。