一、前端游击战为哪般？

小鹿乱撞，心花怒放。终于有机会在梦寐以求的团队博客的评论以外位置留下自己的痕迹啦，撒花撒花！淡定淡定，官博是严肃的地方，要是随便侃大山侃小山，拙文估计会被“里德尔”砍成袁姗姗。

深吸一口气，闲话少说，放马入题。

首先有必要先回答这个问题：“何为前端游击战？”

所谓“前端游击战”是相对“前端常规战”而言的。一般而言，一个前端会负责一个（也有多个项目）的开发、上线以及后期维护，精雕细琢产品。所谓一个 team, 一个团队，大致如此。比方说Qzone的前端er, 至少在一个很长的时期里面，都会泡在Qzone这个产品上，此为“常规战”，我想大部分的小伙伴都是这样子的，不只前端，设计师甚至后台开发也是如此。而 “游击战”就大不一样了，打一枪，放一炮，点到为止然后基本上就放手拜拜啦！你可能会惊讶，“还有这样玩的，能做出高品质的产品吗？”

无数的偶然可以造就生命，自然各种因素相互碰撞也会造就不一样的开发模式。

腾讯社交用户体验设计的小伙伴们遍布祖国大江南北，为亿万网民设计优质体验、提升生活品质。自然，上海这边也有不少很Nice的小伙伴啦，都是国内 顶尖的用研、交互与视觉。稍等…这里怎么有个另类——那个喝娃哈哈AD钙奶的，没错，就是你！古人云，相由心生，你这么黑，快说，你到底是干嘛的！我…… 我是做前端重构的……

剧情正如你看到的，我们上海设计中心现在有个独苗前端。要知道，我们设计中心是个支持性部门，每个交互、视觉都在特定的产品线上。那这个独苗前端该 如何定位呢？我个人定位是这样的：对内辅助，对外桥梁。所谓“对内辅助”包括原型、工具以及活跃气氛；“对外桥梁”指对外精确包装与传达交互细节、设计思 想等。

这种角色定位以及一些其他的机缘巧合就形成了有特有的游击开发策略。哦？略闻一二！

1. 我们设计中心就像个……中心，你可以想象成一个圆圆的小太阳；
2. 这个小太阳里面有很多人美心更美的小伙伴，这是小太阳持续发热的根源所在；
3. 然后小太阳周围有很多的星球a, 星球b，就是实际上的我们所说的项目a, 项目b, …；
4. 这些星球是最终作品产出的工厂。但是，要想产出好的作品，需要设计中心的支持。就像地球的繁荣离不开太阳的普照。于是，每个项目就会圈中设计中心的几位小伙伴，协助开发与产出；
5. 但是，毕竟不在一个球体上，思维方式也有差异，左脑主义 VS 右脑主义。信息从小太阳传到周围星球上的时候有时候就会脱节，设计输送的是玉米，结果最后工厂产出的是爆米花；
6. 所以，需要一个保证交互、视觉准确输出的角色，其任务很简单，作为前期的信息传递的桥梁。
7. 实践表明，这样的模式前后工作都更轻松了，产品也更保真。
8. 于是，后来的新项目，都希望这位小工在前期搭好桥梁，保证设计几乎无损运到后方。
9. 虽然小工活好耐劳效率高，但N头并进神仙也吃不消。
10. 于是，就开始了游击策略，打一枪，放一炮；不尾随，不深入；货到桥头，各走各路。

从上面的进程史可以看出，前端游击战是本着做出更精湛产品目的、同时受制于人力资源最大效益权衡下的一种开发合作模式。看上去很简单，很洒脱，实则 恰恰相反。如果你真就很简单、很洒脱地按照自己的心情交付个看上去是那么回事，实则半吊子产出然后秋扇见捐，额，好吧，开发要佛跳墙，项目经理还会来骚扰 你，这桥梁已然不是连接，而成了瓶颈，还不如当初直接设计、开发连线。所以，要想半途全身而退，还是有很多讲究的地方，这里，我就将分享自己的一些前端游 击战的经验与心得，希望对这种合作方式有兴趣的团队或个人提供一些帮助。

二、如何打好前端游击战？

1. 前期沟通很重要

前期沟通的重要性应该没有谁不知道，所以一些喜闻乐见、耳熟能详的沟通要点就不赘述，说个前端游击很重要的一个沟通点——介入深度。“介入深度”之重要性如秃子头上的虱子——显而易见：你打游击进入敌方腹地太深，抽不出来被灭的命；入敌太浅，隔靴搔痒，又没有任何效果，还要重来，费时费力。

然而，“介入深度”其实是个比较虚的概念。我自己心中的衡量是这样的：

• 发挥口遁，提供一些实现建议以及选型方案，但不码一行代码，此乃10%介入。
• 快速成型，给老板、产品经理或者开发抢先过目体验的，CSS代码什么的不能作为实际项目代码使用的，为20%介入。
• 与设计图一一匹配的HTML页面，此乃30%介入。例如，一个单页的制作工具，每个制作模块的展开状态采用独立的.html页面表示，于是，最终交付的可能就是10~20个页面；
• 包含纯视觉层面交互的原型页面，任何交互代码都不会被开发采用，纯示意，此乃40%介入。此时，你可以用CSS3高级特性完成些效果，甚至jQuery UI走起，不要担心你的代码很懒，因为都会被无视；
• 与开发公用解决方案，负责UX相关交互，JS代码直接利用，会与开发的JS合并并最终上线，此乃60%介入。此时，需要考虑规范、兼容性以及性能等等。
• 不仅负责纯视觉交互，还使用伪数据模拟与后台的通信的完整交互，但代码依然本着纯演示目的，此也是60%介入。例如，点击个按钮，ajax请求走起，按钮状态变化，菊花出现，成功后，载入内容，并出现成功提示。
• CSS, UX JS, Server JS均需要最终上线，然数据是假的，此乃80%介入。
• 页面、交互、开发一把抓，从头撸到尾，此乃100%介入。

凡事都需要经验积累的，之前就存在介入深度把我不准的问题：

① 介入过深

去年做企业盘，自己参与的第一个比较大而完整的项目，自己有点high, 完全把自己当其他部门的人使用了。做得很拼，原型页面做得超级高保真，文件上传，进度条什么的都是真实的，介入程度70%左右。然而，这种介入过于深入且 分界不明，因此，开发在代码剥离的时候花了一番功夫，这种刮骨疗伤的感觉没人会喜欢的！

② 介入过浅

今年手Q某项目，原型页华丽丽地完成了，其中的交互效果，我是按照40%的深度介入的（效果代码仅供参考）。然后，企业这边移动端经验还不是很多，于是直 接采用了我还不成熟的过场代码（无Ajax处理），先不说代码风格不一致，技术策略也不一样，所以，从代码层面讲，并不美丽。总结下来，就是经验不足，虽 有分工等前期沟通，但技术介入深度这个细节并未细致探讨，于是出现了连接不顺畅的情况。如果重新做这个项目，就会60%介入，数据请求与视图绘制就会与过 场交互形成一个完整体系。合作就会顺畅很多！

后来，就聪明了。和其他团队合作时候，会事先沟通好介入深度，说白了就是：我是不是只负责出现演示？还是我帮你们实现演示？前者属于打枪，后者属于放炮。都属于游击战范畴，后者嘛成本稍微高一点。一般情况下，我都是做到前者这一步，以便足够精力身退参与其他部门的项目。

例如，最近要开始的XXX项目，就约定好了，无论JS多么华丽，都无视，因为只是用来展示效果的花衣裳。像这样，介入深度明确，才能准确知道什么时候该撤，什么时候来补枪。

2. 不以物喜、不以己悲的胸襟

到处打游击，说穿了就是吃百家饭。然而，每家的饭菜的食材、口味都是不一样的。如何才能在别人家吃得开心？很简单，放弃自己特有的口味，尝试接受别 人家但你自己可能不喜欢的口味。这前端游击战也是如此。很多有经验有资历的开发经常会鄙视别人写的代码，如果团队里有另外一个有经验有资历但世界观不一样 的开发，往往会为技术选项或者命名之类的事情闹得不开心，我以前就遇到过一个开发逼走另外一个开发的情况。这种代码洁癖的完美主义者看上去有追求，当然， 自我感觉也是我这是有追求，优越感油然而生，实际上，只是心胸狭隘的表现罢了！让这样的人去打游击，感觉就像是让关羽背后偷袭别人，然后撒腿就跑——不可 想象，难于上青天！

所以，要想游击打得好，宽广胸襟少不了！具体该如何做呢？我总结了下面几条供大家参考：

① 放弃自己的常用习惯

这里所说的习惯很多啦。包括，命名、文件组织方式、代码排版（缩进），书写风格，语言模式等等。尤其当一个人在一个团队呆久了，固然会有很多的习惯，这其 实挺好的，保持一致性，代码迭代什么的前后风格统一，更利于维护和协作。但是，如果你是搞游击战的，那这些习惯都是要弃之不顾的。为何？很简单，因为每个 部门，每个团队的风格、习惯都是不一样的，你肯定不能按照自己的习惯来走，否则合作起来代码不和谐，还容易出乱子。举个例子：你的CSS命名都是下划线开 始的，JS参与的类名都是大小写组合的驼峰命名；但是，跟你游击合作的团队规范是，CSS命名短连接符，JS类名都是js_开头。这显然问题来了，你的HTML代码还能用吗？哪个用来显示样式、哪个脚本绑定傻傻分不清楚。

所以，合作动手之前，先要把自己的那些各种习惯放在一边，去看看跟你游击的团队以前的文件名、变量、属性名如何命名的、JS的习惯书写模式是什么的，等等。然后，按照这个团队的习惯来写代码，哪怕这个习惯在你“专业”的眼光里是欠妥的。记住，重要的是团队合作！

拿我自己举例，我之前CSS命名一直使用下划线_，因为可以愉快的双击选中（历史原因）。来设计中心后发现，合作的项目都是短横线-。你知道的，毅然舍弃了5~6年的命名习惯，“短命（短横线命名）”走起，然后愉快地打游击~~

② 丢弃自己的那点小资本

工作久了，总会积累些技术资本，比方说组件达人，SASS好手，YUI忠实粉，CoffeeScript第二人。没错，这些都是好东西，没人会否认的，很 多人说不定要靠这些升职加薪迎娶白富美呢！但是，亲们哪，在打前端游击战的时候，这些东西呢，就不要放出来了！你可能会疑问：“为什么不要啊，我觉得这些 东西很好啊！我用起来很顺手！”问题在于，你顺手，跟你不是一个团队的其他小伙伴不顺手哈！

游击战的精髓的是能「击」更能「游」！你说你使用CoffeeScript, 没错，是能「击」，对其他同事心理打击确实很大，但是「游」不回去啦。无非两种结果：“受”说，哎呦，你这个好高大上，给我们几个培训下嘛；“攻”说，我 们可没精力专门找人维护你的**（屏蔽）代码！无论哪种情况，都被套牢，脱不开身！

所以，你自己那点引以为豪的资本都放在一边。首先，使用合作团队的通常解决方案，是不是有自己的框架与组件库；然后，如果没有，你也应该使用业界开 源、普遍认可、富含文档的解决方案。比方说MVC方案，你牛，你有自己一套web开发框架，上可风卷残云，下可飞沙走石，抱歉，还是老老实实使用 Backbone.js. 因为你必须牢记这一点：我这是在打游击战，其他部门也需要我，我要速度撤离，没人会傻不拉几跪舔一个人不在、文档缺失、潜在风险不详的框架的！如果你在一 个稳定团队做一个稳定项目，这么牛的东西那铁定要上啊，绩效考评什么的，就指望它了！