小公司的前端應該怎麼作？

 

隨着能力的提高，負責的工做種類會逐漸增多，考慮的方向也會有所不一樣，這個時候不太會有太多單獨的知識點成爲阻礙了，工做中碰到的問題要麼太 「大」，總結起來費力，要麼太「小」。

在小公司作前端，由於公司以及職位的變化，對於在小公司如何作前端有一些心得，拿出來與各位作個分享，但願對處於小公司的前端有必定用處。

什麼是優秀的前端團隊？

團隊初期缺什麼

在公司中，層級越高對業務關注比例越高，反而不太關注我的成長，因此評價一個leader是以團隊爲單位，團隊成員比他強是應該的；對於我的來講的話，要多關注自身能力成長，而後能力匹配本身的職位，甚至超出本身的職位，這樣的團隊的話，戰鬥力是比較強的。

主管（包括前端主管）設定目標必須可量化 ，好比你作一個業務，kpi是多少，那麼技術就須要考慮如何才能達成，細化到研發甚至前端層級，就是所謂技術kpi了。

好比，今年H5站想達到單日平均出票量10000，那麼這個就是業務目標，須要消化分到各個業務團隊，能夠是：

① SEO優化

② SEM優化

③ 營銷廣告

④ 微信&支付寶&手機百度流量接入（微信錢包是十分優秀的流量入口，能夠極大程度的增長流量）

⑤ 實地推廣

......

以上固然只能解決部分問題，具體到前端，可能咱們就要從頁面轉換率入手，創建訂單漏斗模型，作性能優化，作交互優化，每個具體的層面都須要轉化目標。

這些都是直接可量化的東西，由於當前業務已經到了一個瓶頸，或者公司已經到了一個瓶頸，業務上就須要作不停的嘗試，對應到技術就是須要你快速迭代，低成本迭代，不斷的容錯試錯。

這個時候就會提出不少問題：

第一是你的團隊在相似高壓下會不會主動加班去實現公司的目標、我的的kpi。

第二是你的團隊在這輪高壓拼搏後有沒有留下什麼東西？

根據以前經驗，沒有團隊能夠無休止的承受高壓加班的壓力

以以前攜程無線高壓迭代的經從來說，就算是那麼優秀的團隊事實上到後期也是疲憊不堪，疲憊的時候容易犯錯，亢龍有悔，盈不可久。

第三是如何幫助新人快速的融入團隊，如何讓1+1=2。

咱們都清楚，好的項目毫不是堆人能夠堆出來的，如何讓一個項目能夠分解到各我的手中，如何讓參差不齊的同事能夠更好的協做，這個是咱們須要考慮的。

要解決這些問題是要靠平時的積累，具體體現到前端是：

1 在不停的迭代中，你的業務流程是否是最優（產品到設計到前端到最終上線流程）

2 在不停的迭代中，是否沉澱出來了公共服務與工具化服務

好的前端是什麼樣的

首先，好的前端是必定願意加班的，同時，好的前端是會找辦法讓團隊少加班的。

和一些朋友作過交流，不少好的點子，改善工做效率的點子都是幾我的討論後私下晚上搞出來，而後反覆實踐用於生產的。

通常來講業務kpi對於能力強的朋友來講不會太難，因此對他們的期待也會更多：

有強烈的意識，能深入瞭解到當前項目性能的缺陷，開發效率低下的緣由，

並會找尋處理辦法

不少團隊在快速迭代中會開始「欠帳」，時間久了就不肯意還，問題的存在擱置須要想辦法去解決，團隊成員是看獲得問題的，沒人說，沒人作是由於知道那是坑，你若是能解決的話，一到二次便能提高本身在團隊中的位置。

 

好的前端應該有良好的架構設計能力

首先，好的前端能向人清晰有條理的描述本身的技術方案，而且讓人聽得懂！而後架構設計能知足長久的需求發展，就算業務頻道擴大了10倍，用戶量增長了100倍，也不會有根本的變更。

好的前端應該具備良好的交流能力

對內，好的前端須要瞭解團隊成員的性格與能力，作出適當的任務分配分解；對外，須要搶佔業務還不能產生利益衝突，這類人是項目推動的主力。

小公司的前端應該怎麼作

不是全部的小公司都這樣，可是我見過的小公司的前端都在撲業務，而且疲於奔命，這個是個惡性循環，第一次作業務：

加班趕業務-業務結束輕鬆一週-加班趕迭代-業務結束輕鬆一週-加班新業務-業務結束輕鬆下......

偶爾你會問這些朋友爲何沒有什麼積累，獲得的答案基本是一致的，忙啊！他們忙起來的時候是真的很忙，可是第二次若是依舊這麼忙的話就有問題，第三次還這樣就是團隊不健康了，一個好的作法是：

① 完成先後分離，這步作不到，後面也不用作了

② 造成幾套UI庫

③ 根據業務形態，造成公共業務

④ 前端重複工做工具化

⑤ 造成優化體系

⑥ 造成統計體系

⑦ 創建頁面轉化漏斗模型

⑧ 作ABTesting方案

......

首先，不管出於什麼考慮，先後必定要作分離，若是有SEO需求，那麼再後續推動nodeJS方案，畢竟如今不給錢想排前面仍是很難，SEO基本沒意義。

其實，小公司有不少坑能夠佔住，這個會幫助你創建團隊威望，下面我舉幾個細節點說一說。

UI庫

UI庫的造成與UI庫的多少將決定你後續項目重複工做量的多少，這個UI庫須要注意幾點：

① UI是否可重用

② UI是否可定製

好比讓不少朋友去作這個時間選擇器，作出來就真的是時間選擇器，若是讓他換成城市選擇器，就全傻眼了.

③ UI是否可拆分，可聚合

仍是以上面UI爲例，這個組件事實上是一個聚合組件，由一個select組件與一個彈出層組件組成，你的UI是否是可拆分是評價他質量的一個很大考慮點。

......

公共服務

公共服務能夠說成一個大一點的「UI組件」，可是他是與業務相關的，UI來講通常不會與業務產生耦合，以上面的日期選擇器來講，不管他裝的是日期仍是區域都是能夠的，而且不該該請求服務，他是純淨的UI組件。

而公共服務是不純淨的是必定與業務相關的，移動端比較常見的公共服務是：

passport

包含登陸註冊、我的資料管理，甚至包含一些認證相關的，與公司帳號相關的操做，登陸註冊是各類活動，各類業務頻道均可能會使用的業務，這種東西是必須服務化的，可是不少小公司都沒作。

由於公共的特色，頁面設計最好中性一點，其中幾個經常使用的頁面，好比登陸須要包含如下設計：

① 樣式可定製化（彈出層、獨立頁面什麼的都是常事）

② 回退可定製，其實全部的公共服務回退按鈕都是須要定製的，登陸成功去哪一個URL登陸失敗去哪一個URL，點擊瀏覽器回退去哪一個URL都得約定，少一個都不是公共服務

③ 單點登陸，事實上初期根本用不到什麼單點登陸，甚至你們都不是跨域的，因此後續須要再支持便可

還有不少與passport同樣的公共業務，好比：

① 錢包服務，包括用戶支付訂單相關管理

② 城市列表，這個要考慮參數如何傳遞

③ 反饋系統

④ 公司介紹

除了面向C端的公共頁面服務，還會有面向B端的統計平臺相關。

前端工具化

靜態資源處理

評價一個前端團隊是否優秀成熟的評判多以團隊工具化的程度，一個簡單的例子是：

① 大家前端靜態資源是如何組織的、如何打包的

② 大家前端靜態資源是如何解決緩存的（比較好的方案是MD5）

上面兩點可使用grunt/gulp一類的構建工具輕鬆作到，若是有公共框架文件還會須要引入種子文件的概念

跨域問題

另外，全部前端團隊都會遇到跨域問題，特別是先後分離後，服務器端只提供API接口，前端代碼隨便在哪都能運行，那麼這個時候你是怎麼作呢？

① 使用fiddler&charles作代理

② 提供測試服務器

③ 支持jsonp跨域

④ 支持cors跨域

那麼這些方案，哪一種最適合團隊，哪一種成本最低（通常來講是代理），是咱們須要考慮的

tips：我以前使用fiddler，如今換mac了使用charles，兩款工具十分優

秀，正則一塊的處理很好，推薦使用

移動端適配

從後端轉到前端的同窗通常在業務邏輯上有一些天生的優點，可是每每在CSS一塊比較弱，如何在開發人員無感的狀況下引入rem，如何與現有機制無縫的使用less，如何處理單頁應用中css的污染，這個是框架底層須要考慮的。

模塊化&組件化開發

團隊上規模後，如何使用模塊化開發處理協做問題；業務代碼複雜度上升後，如何使用組件化編程思惟簡單開發複雜度，這些須要應用到項目實踐中，而且路徑是可複製的；

一些優化手段，也須要工具化，框架化，讓開發人員無感。

先後端協做

前端與服務器端，開發速度未必同步，事實上不少時候都不是同步的，在已經約定了接口格式的狀況下，接口尚未寫好，可是前端依然能寫交互，團隊是如何寫這種假數據，這個方面實現會大大的提高工做效率。

訂單降低分析

若是在某一個時間段，全站的流量或者全站的訂單量降低了，你如何跟蹤此次降低的緣由，如何最大程度上避免下次出現相似的現象，這個時候數據統計會避免咱們成爲瞎子，因此得儘快創建統計平臺，轉換率模型。

快速迭代，經過迭代來優化產品，可是若是每個迭代都徹底顛覆了以前的設計，不少時候公司就是原地踏步，每邁出一步你要清晰的知道前一個版本哪裏出了問題，針對問題作優化，而不是頻繁改版。

此次改版後，你如何知道此次優化就比上一次的好，而不是其它因素形成，ABTesting方案應該是每個成熟團隊必須的，持續優化這些都是創建在有效的數據監控與意見反饋機制上的，咱們不能作完網站變成瞎子。

誠然，對於一個前端來講，要推進上述工做仍是有一點難度的，但並非不可能，前端對本身的定位要變，從前端工程師到軟件工程師。

前端的重視程度須要你們一併努力，在大公司作前端難，在小公司作前端更難。