一、前端游擊戰為哪般？

小鹿亂撞，心花怒放。終于有機會在夢寐以求的團隊博客的評論以外位置留下自己的痕跡啦，撒花撒花！淡定淡定，官博是嚴肅的地方，要是隨便侃大山侃小山，拙文估計會被“里德爾”砍成袁姍姍。

深吸一口氣，閑話少說，放馬入題。

首先有必要先回答這個問題：“何為前端游擊戰？”

所謂“前端游擊戰”是相對“前端常規戰”而言的。一般而言，一個前端會負責一個（也有多個項目）的開發、上線以及后期維護，精雕細琢產品。所謂一個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. 因為你必須牢記這一點：我這是在打游擊戰，其他部門也需要我，我要速度撤離，沒人會傻不拉幾跪舔一個人不在、文檔缺失、潛在風險不詳的框架的！如果你在一個穩定團隊做一個穩定項目，這么牛的東西那鐵定要上啊，績效考評什么的，就指望它了！

還是拿我舉例吧，OOCSS用的不亦樂乎，quicklayout獨步江湖，用之寫頁面速度趕上高鐵，一切盡在彈指間。但是，我現在游擊的至少5~6個項目，沒有一個使用之，因為，只有我和對我關注的人對此熟悉。頁面交付后，一些微調的CSS維護工作我其實不參與的⑴，所以，如果CSS過于個性化，顯然是給自己挖坑。

③ 學會退而求其次
都聽說過，“做最好的自己，給最愛的人”，確實，我們在團隊里做開發時候，是應該精益求精，精上加精。但是，有時候需要把好主義情懷放在一邊了，不必執著于好的代碼。

首先明確一點，一個產品的最終質量，給企業最終帶來的收益，與代碼是否好的相關系數其實很低。

有時候，跟隨合作團隊的集成解決方案，最終生成或發布的代碼可能并不是好的狀態。比方說，依賴Less, 計算數值N位小數，嵌套、函數濫用，導致最終CSS太多層級，可重復利用CSS只是編寫時候重復利用，生成的CSS依然狗皮膏藥顯啰嗦。或者模塊依賴過于耦合，以至于一個很簡單頁面，也要加載一堆CSS以及JS, 顯得較重等~

這些是問題嗎？確實是！但是，千萬不要用你狹隘的眼神去評判之，指責之，或者自己為是走自認為最精簡，代碼最好度方案——不成熟。多人協作、工程化等是個很復雜的事情，舍棄一點點好的代碼退而求其次，實際上是種大智。

作為一個游擊戰士，一定要有著眼大局，退而求其次的意識。如果你實在看不慣，你可以主動請纓去該團隊，幫助其解決方案進一步完善。那你晉級考評什么的必定妥妥的！如果沒有這份心，就做好自己的工作，跟大部隊一起，擰成一股繩，把產品質量、體驗做好，這些才是更要關注的更高境界。

④ 樂于接受并學習新事物
不同部門，不同團隊顯然其使用的一些技術選型都是不一樣的，有的可能是你一直不推崇的方式，此時怎么辦？

做技術的人，一定要有博大的胸懷，去接受各種不同思想、不同工具、不同的開發模式。那種歧視用QQ郵箱，鄙棄黨員，鄙視陸琪的人其實是很幼稚與狹隘的。我雖不贊同，但我樂于接受。

尤其你想成為游擊開發專家，自然這方面要更甚一籌。我年初有個項目，很有意思，使用Git協作開發，頭一遭，好在我對Git沒啥特別的情感，一番折騰，感覺不錯，學到了很多東西，而且最后合作也很順利。看到沒，諸位，前端游擊戰的好處在于有機會學習其他知識、接觸其他時髦的工具，如果你是狹隘的排斥的，不樂于接受與學習的話，實際上是阻礙了自己的成長與發展。

再舉個更有代表性的例子，我是個忠實的不推崇Sass, Less, 以及Stylus的人，我是個道家主義者，推崇本源、無為而治。雖不推崇，但我很樂于接受這方面的知識，關注這方面的發展，甚至，12年時候，花大功夫翻譯了stylus的中文文檔，目前也就這一文檔吧。最近的一個項目，嘿，就是基于Less的生成CSS的，遇到了自己一向不推崇的東西。雖然，合作的小伙伴說，你直接寫CSS代碼也是可以的。但我還是還樂意地用起了Less⑵, 當年翻譯Stylus積累的知識2年后居然起了作用，分分鐘上手。最后，開發開心，我也開心，大家都開心。

所以，像我們寫代碼的，無論何時，都不能被自己所掌握的那點技術形成的世界觀所束縛，接受不同風格的人，不同技術背景的人，不同技術擅長點的人。招聘的時候尤其注意，狹隘的技術人總是傾向于招聘跟自己同類的人，最后，就是個全是中鋒的球隊，做出來的東西嘛，我就不說什么了。

⑵ 切記，前端游擊戰要想打得好，必須使用團隊的技術方案！否則你自己開發時候順手爽，完了合作同事三天兩頭找你有得煩！

3. 文檔以及注釋

溝通很順暢，開發制作時候也是按照了團隊的規范、方案走了，然后直接SVN提交拍屁股走人？且慢，還有個很重要的東西，就是文檔以及詳盡的注釋。

前端游擊戰的精髓之一就是「游」，你說你啥都不交代，回頭前端開發遇到疑問還不是得來找你，你游啊？你游得走嘛！磨刀不誤砍柴工，寫好文檔，寫好注釋，順利交工。開發開心，你也開心，大家都開心！

有很多人真是不擅長寫文檔，從小怕寫作文給烙下的陰影。其實呢，不要多專業，只要換位思考下就可以了。腦補下，跟我交接的小伙伴，他什么都不知道，第一次看到我這個代碼，他知道該如何觸發這里效果顯示嗎？稍微一想就會發現，擦，我這里不寫點內容，就是親媽來了也不知道這里要加個.active的類名啊！于是，你就可以注釋了：

<!-- 
注意，前方高能：
這里點擊顯示下拉直接通過添加和刪除類名.active即可；
禁用使用類名.disable;
注意這里HTML位置，以及后面不能換行，以免出現空格
...
-->

多站在對方立場考慮，自然就知道該寫些什么了。如果你還是駕馭不了，恩，可以文末的郵箱聯系我，我會傳授寫作大法，祝你練成神功 。

三、結語以及廣告

你東西做的好，合作開心，別人都找你，才會有游擊戰這種模式。下面問題來了，1. 如何做的好？首先最最重要的是超出常人，開發所望塵的敏感的設計之心，做出來的東西必須能夠精確傳達設計思想、交互體驗（否則，合作團隊里的前端直接開發豈不更爽氣）；然后是需要比較多的積累，一是深度，要你介入多深，你就能有多深；二是廣度，我以前常常深入研究業務以外的知識點，結果為現在在各個團隊快速上手打下了較好的的基礎。2. 如何合作開心？心胸寬廣，視野開闊，團隊合作放在第一位；過于個人的東西舍棄、團隊的東西跟隨，不會的東西學習，交接文檔要清楚等。

根據我沒有依據的猜想，這種游擊戰風格的前端開發模式應該很少見。要是哪個廠子或者團隊看到了本文，無論有沒有興趣，都可以試試這種開發模式，對吧，要有寬廣的胸懷，可以不贊同，但內心要樂于接受，說不定能提高產品情感化方面的檔次與質量，能與騰訊的產品競爭呢！