如何打好前端游擊戰

 

 

1、前端游擊戰爲哪般？

小鹿亂撞，心花盛開。終於有機會在求之不得的團隊博客的評論之外位置留下本身的痕跡啦，撒花撒花！淡定淡定，官博是嚴肅的地方，要是隨便侃大山侃小山，拙文估計會被「裏德爾」砍成袁姍姍。

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

首先有必要先回答這個問題：「何爲前端游擊戰？」

所謂「前端游擊戰」是相對「前端常規戰」而言的。通常而言，一個前端會負責一個（也有多個項目）的開發、上線以及後期維護，精雕細琢產品。所謂一個 team, 一個團隊，大體如此。比方說Qzone的前端er, 至少在一個很長的時期裏面，都會泡在Qzone這個產品上，此爲「常規戰」，我想大部分的小夥伴都是這樣子的，不僅前端，設計師甚至後臺開發也是如此。而 「游擊戰」就大不同了，打一槍，放一炮，點到爲止而後基本上就放手拜拜啦！「我擦」，你可能會驚訝，「還有這樣玩的，能作出高品質的產品嗎？」

無數的偶然能夠造就生命，天然各類因素相互碰撞也會造就不同的開發模式。

騰訊社交用戶體驗設計的小夥伴們遍及祖國大江南北，爲億萬網民設計優質體驗、提高生活品質。天然，上海這邊也有很多很Nice的小夥伴啦，都是國內 頂尖的用研、交互與視覺。稍等…這裏怎麼有個另類——那個喝娃哈哈AD鈣奶的，沒錯，就是你！古人云，相由心生，你這麼黑，快說，你究竟是幹嗎的！我…… 我是作前端重構的……

劇情正如你看到的，咱們上海設計中心如今有個獨苗前端。要知道，咱們設計中心是個支持性部門，每一個交互、視覺都在特定的產品線上。那這個獨苗前端該 如何定位呢？我我的定位是這樣的：對內輔助，對外橋樑。所謂「對內輔助」包括原型、工具以及活躍氣氛；「對外橋樑」指對外精確包裝與傳達交互細節、設計思 想等。

這種角色定位以及一些其餘的機緣巧合就造成了有特有的遊擊開發策略。哦？略聞一二！

1. 咱們設計中心就像個……中心，你能夠想象成一個圓圓的小太陽；
2. 這個小太陽裏面有不少人美心更美的小夥伴，這是小太陽持續發熱的根源所在；
3. 而後小太陽周圍有不少的星球a, 星球b，就是實際上的咱們所說的項目a, 項目b, …；
4. 這些星球是最終做品產出的工廠。可是，要想產出好的做品，須要設計中心的支持。就像地球的繁榮離不開太陽的普照。因而，每一個項目就會圈中設計中心的幾位小夥伴，協助開發與產出；
5. 可是，畢竟不在一個球體上，思惟方式也有差別，左腦主義 VS 右腦主義。信息從小太陽傳到周圍星球上的時候有時候就會脫節，設計輸送的是玉米，結果最後工廠產出的是爆米花；
6. 因此，須要一個保證交互、視覺準確輸出的角色，其任務很簡單，做爲前期的信息傳遞的橋樑。
7. 實踐代表，這樣的模式先後工做都更輕鬆了，產品也更保真。
8. 因而，後來的新項目，都但願這位小工在前期搭好橋樑，保證設計幾乎無損運到後方。
9. 雖然小工活好耐勞效率高，但N頭並進神仙也吃不消。
10. 因而，就開始了遊擊策略，打一槍，放一炮；不尾隨，不深刻；貨到橋頭，各走各路。

從上面的進程史能夠看出，前端游擊戰是本着作出更精湛產品目的、同時受制於人力資源最大效益權衡下的一種開發合做模式。看上去很簡單，很灑脫，實則 偏偏相反。若是你真就很簡單、很灑脫地按照本身的心情交付個看上去是那麼回事，實則半吊子產出而後秋扇見捐，額，好吧，開發要佛跳牆，項目經理還會來騷擾 你，這橋樑已然不是鏈接，而成了瓶頸，還不如當初直接設計、開發連線。因此，要想半途全身而退，仍是有不少講究的地方，這裏，我就將分享本身的一些前端遊 擊戰的經驗與心得，但願對這種合做方式有興趣的團隊或我的提供一些幫助。

2、如何打好前端游擊戰？

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過於個性化，顯然是給本身挖坑。

⑴ 跟我遊擊合做的小夥伴中也有很多對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位置，以及後面不能換行，以避免出現空格
...
-->

多站在對方立場考慮，天然就知道該寫些什麼了。若是你仍是駕馭不了，恩，能夠文末的郵箱聯繫我，我會傳授寫做大法，祝你練成神功 。

3、結語以及廣告

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

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

最後，打一個廣告，若是哪位小夥伴想和我一塊兒愉快地打游擊戰，能夠發送簡歷至zhangxinxu@zhangxinxu.com, 有信必回。

原文來自： 騰訊ISUX