如何成為一名好前端？

　　1什么是優(yōu)秀的前端團隊? 　　團隊初期缺什么
　　在公司中，層級越高對業(yè)務(wù)關(guān)注比例越高，反而不太關(guān)注個人成長，所以評價一個leader是以團隊為單位，團隊成員比他強是應(yīng)該的;對于個人來說的話，要多關(guān)注自身能力成長，然后能力匹配自己的職位，甚至超出自己的職位，這樣的團隊的話，戰(zhàn)斗力是比較強的。
　　主管(包括前端主管)設(shè)定目標必須可量化 ，比如你做一個業(yè)務(wù)，kpi是多少，那么技術(shù)就需要考慮如何才能達成，細化到研發(fā)甚至前端層級，就是所謂技術(shù)kpi了。
　　比如，今年H5站想達到單日平均出票量10000，那么這個就是業(yè)務(wù)目標，需要消化分到各個業(yè)務(wù)團隊，可以是：
　?、?SEO優(yōu)化
　?、?SEM優(yōu)化
　?、?營銷廣告
　?、?微信&支付寶&手機百度流量接入(微信錢包是十分優(yōu)秀的流量入口，可以極大程度的增加流量)
　?、?實地推廣
　　……
　　以上當然只能解決部分問題，具體到前端，可能我們就要從頁面轉(zhuǎn)換率入手，建立訂單漏斗模型，做性能優(yōu)化，做交互優(yōu)化，每一個具體的層面都需要轉(zhuǎn)化目標。
　　這些都是直接可量化的東西，因為當前業(yè)務(wù)已經(jīng)到了一個瓶頸，或者公司已經(jīng)到了一個瓶頸，業(yè)務(wù)上就需要做不停的嘗試，對應(yīng)到技術(shù)就是需要你快速迭代，低成本迭代，不斷的容錯試錯。
　　這個時候就會提出很多問題：
　　第一是你的團隊在類似高壓下會不會主動加班去實現(xiàn)公司的目標、個人的kpi。
　　第二是你的團隊在這輪高壓拼搏后有沒有留下什么東西?
　　根據(jù)之前經(jīng)驗，沒有團隊可以無休止的承受高壓加班的壓力
　　以之前攜程無線高壓迭代的經(jīng)歷來說，就算是那么優(yōu)秀的團隊事實上到后期也是疲憊不堪，疲憊的時候容易犯錯，亢龍有悔，盈不可久。
　　第三是如何幫助新人快速的融入團隊，如何讓1+1=2。
　　我們都清楚，好的項目絕不是堆人可以堆出來的，如何讓一個項目可以分解到各個人手中，如何讓良莠不齊的同事可以更好的協(xié)作，這個是我們需要考慮的。
　　要解決這些問題是要靠平時的積累，具體體現(xiàn)到前端是：
　　1 在不停的迭代中，你的業(yè)務(wù)流程是不是最優(yōu)(產(chǎn)品到設(shè)計到前端到最終上線流程)
　　2 在不停的迭代中，是否沉淀出來了公共服務(wù)與工具化服務(wù)
　　2好的前端是什么樣的?
　　首先，好的前端是一定愿意加班的，同時，好的前端是會找辦法讓團隊少加班的。
　　和一些朋友做過交流，很多好的點子，改善工作效率的點子都是幾個人討論后私下晚上搞出來，然后反復(fù)實踐用于生產(chǎn)的。
　　一般來說業(yè)務(wù)kpi對于能力強的朋友來說不會太難，所以對他們的期待也會更多：
　　有強烈的意識，能深刻了解到當前項目性能的缺陷，開發(fā)效率低下的原因，并會找尋處理辦法
　　很多團隊在快速迭代中會開始“欠賬”，時間久了就不愿意還，問題的存在擱置需要想辦法去解決，團隊成員是看得到問題的，沒人說，沒人做是因為知道那是坑，你如果能解決的話，一到二次便能提升自己在團隊中的位置。
　　好的前端應(yīng)該有良好的架構(gòu)設(shè)計能力
　　首先，好的前端能向人清晰有條理的描述自己的技術(shù)方案，并且讓人聽得懂!
　　然后架構(gòu)設(shè)計能滿足長久的需求發(fā)展，就算業(yè)務(wù)頻道擴大了10倍，用戶量增加了100倍，也不會有根本的變動。
　　好的前端應(yīng)該具有良好的交流能力
　　對內(nèi)，好的前端需要了解團隊成員的性格與能力，做出適當?shù)娜蝿?wù)分配分解;對外，需要搶占業(yè)務(wù)還不能產(chǎn)生利益沖突，這類人是項目推進的主力。
　　3小公司的前端應(yīng)該怎么做?
　　不是所有的小公司都這樣，但是我見過的小公司的前端都在撲業(yè)務(wù)，并且疲于奔命，這個是個惡性循環(huán)，第一次做業(yè)務(wù)：
　　加班趕業(yè)務(wù)-業(yè)務(wù)結(jié)束輕松一周-加班趕迭代-業(yè)務(wù)結(jié)束輕松一周-加班新業(yè)務(wù)-業(yè)務(wù)結(jié)束輕松下……
　　偶爾你會問這些朋友為什么沒有什么積累，得到的答案基本是一致的，忙啊!他們忙起來的時候是真的很忙，但是第二次如果依舊這么忙的話就有問題，第三次還這樣就是團隊不健康了，一個好的做法是：
　?、?完成前后分離，這步做不到，后面也不用做了
　?、?形成幾套UI庫
　?、?根據(jù)業(yè)務(wù)形態(tài)，形成公共業(yè)務(wù)
　?、?前端重復(fù)工作工具化
　?、?形成優(yōu)化體系
　　⑥ 形成統(tǒng)計體系
　?、?建立頁面轉(zhuǎn)化漏斗模型
　?、?做ABTesting方案
　　......
　　首先，無論出于什么考慮，前后一定要做分離，如果有SEO需求，那么再后續(xù)推進nodeJS方案，畢竟現(xiàn)在不給錢想排前面還是很難，SEO基本沒意義。
　　其實，小公司有很多坑可以占住，這個會幫助你建立團隊威望，下面我舉幾個細節(jié)點說一說。
　　UI庫
　　UI庫的形成與UI庫的多少將決定你后續(xù)項目重復(fù)工作量的多少，這個UI庫需要注意幾點：
　?、?UI是否可重用
　?、?UI是否可定制
　　比如讓很多朋友去做這個時間選擇器，做出來就真的是時間選擇器，如果讓他換成城市選擇器，就全傻眼了：
　　③ UI是否可拆分，可聚合
　　還是以上面UI為例，這個組件事實上是一個聚合組件，由一個select組件與一個彈出層組件組成，你的UI是不是可拆分是評價他質(zhì)量的一個很大考慮點。
　　……
　　公共服務(wù)
　　公共服務(wù)可以說成一個大一點的“UI組件”，但是他是與業(yè)務(wù)相關(guān)的，UI來說一般不會與業(yè)務(wù)產(chǎn)生耦合，以上面的日期選擇器來說，無論他裝的是日期還是區(qū)域都是可以的，并且不應(yīng)該請求服務(wù)，他是純凈的UI組件。
　　而公共服務(wù)是不純凈的是一定與業(yè)務(wù)相關(guān)的，移動端比較常見的公共服務(wù)是：
　　passport
　　包含登錄注冊、個人資料管理，甚至包含一些認證相關(guān)的，與公司賬號相關(guān)的操作，登錄注冊是各種活動，各種業(yè)務(wù)頻道都可能會使用的業(yè)務(wù)，這種東西是必須服務(wù)化的，但是很多小公司都沒做。
　　因為公共的特點，頁面設(shè)計最好中性一點，其中幾個常用的頁面，比如登錄需要包含以下設(shè)計：
　?、?樣式可定制化(彈出層、獨立頁面什么的都是常事)
　?、?回退可定制，其實所有的公共服務(wù)回退按鈕都是需要定制的，登錄成功去哪個URL登錄失敗去哪個URL，點擊瀏覽器回退去哪個URL都得約定，少一個都不是公共服務(wù)
　?、?單點登錄，事實上初期根本用不到什么單點登錄，甚至大家都不是跨域的，所以后續(xù)需要再支持即可
　　還有很多與passport一樣的公共業(yè)務(wù)，比如：
　?、?錢包服務(wù)，包括用戶支付訂單相關(guān)管理
　?、?城市列表，這個要考慮參數(shù)如何傳遞
　?、?反饋系統(tǒng)
　?、?公司介紹
　　除了面向C端的公共頁面服務(wù)，還會有面向B端的統(tǒng)計平臺相關(guān)。
　　前端工具化
　　靜態(tài)資源處理
　　評價一個前端團隊是否優(yōu)秀成熟的評判多以團隊工具化的程度，一個簡單的例子是：
　　① 你們前端靜態(tài)資源是如何組織的、如何打包的
　?、?你們前端靜態(tài)資源是如何解決緩存的(比較好的方案是MD5)
　　上面兩點可以使用grunt/gulp一類的構(gòu)建工具輕松做到，如果有公共框架文件還會需要引入種子文件的概念
　　跨域問題
　　另外，所有前端團隊都會遇到跨域問題，特別是前后分離后，服務(wù)器端只提供API接口，前端代碼隨便在哪都能運行，那么這個時候你是怎么做呢?
　?、?使用fiddler&charles做代理
　?、?提供測試服務(wù)器
　　③ 支持jsonp跨域
　?、?支持cors跨域
　　那么這些方案，哪種最適合團隊，哪種成本最低(一般來說是代理)，是我們需要考慮的
　　tips：我之前使用fiddler，現(xiàn)在換mac了使用charles，兩款工具十分優(yōu)秀，正則一塊的處理很好，推薦使用
　　移動端適配
　　從后端轉(zhuǎn)到前端的同學一般在業(yè)務(wù)邏輯上有一些天生的優(yōu)勢，但是往往在CSS一塊比較弱，如何在開發(fā)人員無感的情況下引入rem，如何與現(xiàn)有機制無縫的使用less，如何處理單頁應(yīng)用中css的污染，這個是框架底層需要考慮的。
　　模塊化&組件化開發(fā)
　　團隊上規(guī)模后，如何使用模塊化開發(fā)處理協(xié)作問題;業(yè)務(wù)代碼復(fù)雜度上升后，如何使用組件化編程思維簡單開發(fā)復(fù)雜度，這些需要應(yīng)用到項目實踐中，并且路徑是可復(fù)制的;
　　一些優(yōu)化手段，也需要工具化，框架化，讓開發(fā)人員無感。
　　前后端協(xié)作
　　前端與服務(wù)器端，開發(fā)速度未必同步，事實上很多時候都不是同步的，在已經(jīng)約定了接口格式的情況下，接口還沒有寫好，但是前端依然能寫交互，團隊是如何寫這種假數(shù)據(jù)，這個方面實現(xiàn)會大大的提升工作效率。
　　訂單下降分析
　　如果在某一個時間段，全站的流量或者全站的訂單量下降了，你如何跟蹤這次下降的原因，如何最大程度上避免下次出現(xiàn)類似的現(xiàn)象，這個時候數(shù)據(jù)統(tǒng)計會避免我們成為瞎子，所以得盡快建立統(tǒng)計平臺，轉(zhuǎn)換率模型。
　　快速迭代，通過迭代來優(yōu)化產(chǎn)品，但是如果每一個迭代都完全顛覆了之前的設(shè)計，很多時候公司就是原地踏步，每邁出一步你要清晰的知道前一個版本哪里出了問題，針對問題做優(yōu)化，而不是頻繁改版。
　　這次改版后，你如何知道這次優(yōu)化就比上一次的好，而不是其它因素造成，ABTesting方案應(yīng)該是每一個成熟團隊必須的，持續(xù)優(yōu)化這些都是建立在有效的數(shù)據(jù)監(jiān)控與意見反饋機制上的，我們不能做完網(wǎng)站變成瞎子。