前言

昨日，我請了一天假去考科目三，結果第一把掛在了沒完全關閉燈光上，第二把掛在轉彎時沒有觀察後方車輛，當聽到師傅一句“下去”的時候，我那是悲痛的面紅耳赤，這讓我很鬱悶，晚上也就不想回去上班了，回家後仍然有點低沉，在這種情況下，不寫點毒雞湯，好像已經不能好好的調節心情了，看看時間年底了，便寫寫今年的總結吧。

回想自己學車的點點滴滴，其實是很認真的，一旦有時間就去學習，練習時候也表現比較正常，晚上還會冥想整個考試流程，但最後臨門一腳仍舊出錯了，這個時候可以說我問心無愧了，也可以說我努力過了，雖然失敗了，但我應該得到尊重。

現在看來說這種話的小夥伴不過在自我安慰罷了，做的過程中我確實很努力，也真的很認真，但是最後產生不了成果，做的事情不能落地，那麼這一切的努力可以說毫無意義。將這一次的駕照考試對映到一次重要專案開發的話：

產品努力出需求 ->研發努力加班幹 -> 測試努力加班測試 -> 上線 -> 大流量掛啦……

開發的過程中，研發天天加班，測試也天天加班，但是最後專案上線後就是掛了，那麼之前的努力並不會換來豐收的果實，即將來臨的可能是老闆的怒號，團隊的動盪，而不論是考試掛了，還是專案掛了，都有幸被我經歷了。回頭想想，人生嘛，什麼都應該經歷一發嘛，深深的體會一下掛了的那種無力感，也是不錯的嘛，想到這裡，我竟然有些釋懷的感覺，只不過是重頭再來（自我安慰而已啦）……

再回想16年初回到了成都，開始了愉快的“慢節奏”生活。不曾想，現在的公司給予自己的平臺居然是其它地方所沒有的，不論從工作強度還是業務複雜度來說，都是很對胃口的，偶爾的工作強度甚至超過了上海，嗯，這個很“成都”。

文中為個人觀點，不喜勿噴

大公司or小公司

之前經常有人發文說到底要去小公司還是大公司，思考幾年的經歷，其實大公司小公司不重要，好的團隊才重要！

大公司一般是什麼都有，只需要你有一顆學習的心，多折騰多問，便能吸取大量的養分；而小公司也有一個巨大的優勢，便是什麼都沒有，只要你有心，就能把大公司的東西通通實現一篇，這種實踐來的知識技能可比學習要來的珍貴的多！

初到公司時發現了一種現象：

① 身邊很多小夥伴沒有買房但是都有自己的車子

② 多數小夥伴下班就回家了

可以很清晰的感受到這裡的一種慢節奏，這個沒什麼不對，生活與工作要分開嘛，但這卻讓我感覺到了危機與憂慮，最大的憂慮是多數小夥伴可能不會在意到公司的財富了，天地不仁以萬物為芻狗，其實生活是非常公平的，每個人的機遇其實都差不多，很多財富擺在那裡，就看你是不是要去拿。

之前面試的時候，有人會問我知識獲取的途徑，也許是我比較low的緣故，我一直信奉一個原則：

聽過 < demo過 < 實際工作用過 < 實際工作中被坑過 < 實際工作中被多次坑過或者深入研究總結過

風之積也不厚，其負大翼也無力也。網上有很多深度好文，如果沒有一定基礎，其實看了沒有什麼意義，只會在心裡感嘆，我尼瑪這人好牛逼。

我學習的多數知識是直接從專案中來的，這個時候就需要你有一個好的團隊了，我十分慶幸自己曾在攜程無線待過，攜程無線在前端工程化&hybrid&公共服務化一塊走的比較遠，而我當時又很好學，平時沒事就在這之上挖掘，吸收學習，當時一些半懂不懂的知識，在後續的實踐中也逐步融會貫通了，其帶來的財富令我受益至今。

而，人的知識除了受限於自己的學習主動性以外，也受限至他的視野，當時我的視野就在前端方面打不開，沒有去研究攜程的日誌統計系統與釋出系統，到現在需要用到這部分知識時才感到苦不堪言而後悔莫及。

如果各位有機會到大公司去，一定要認認真真搞清楚，你自己所在領域裡面，該公司的財富積累是什麼，然後狠狠去挖掘他，瞭解他的歷史故事，各種處理細節，更多的不是關注他怎麼做，而是要關注他們為什麼這麼做，然後多問多demo，假以時日落地到實踐中，這塊財富就裝入你的口袋了。回想自己的擇業，我事實上是比較後悔自己當時為了一點小錢而放棄了阿里（成體系的前端團隊）去了百度（新團隊，不成體系，甚至前端框架都不統一），如果帶著謙卑的態度去阿里吸取一番技術的給養想必會受用無窮吧。

技術的學習，這個需要一個學習的態度，一個學習的恆心，其實只要是持續的投入，便一定會有收穫的。

技術體系化

在小公司，因為很多基礎設施都不成熟，這個會讓我們有將技術業務體系化&服務化的機會，而體系化後的技術便是公司的財富也是研發團隊的技術壁壘，他能大幅度的提高效率，這個是一個生態體系，一旦生態體系成熟後，牽一髮而動全一身，就不是任何人能輕易接手的了。

初到公司的時候，我們的系統是這麼個狀態：

每個H5專案有一個自己獨立的登入註冊，native又有自己的native的登入註冊，甚至server端的服務都彼此獨立，這樣使用者之間變形成了資訊孤島，這會引發很多問題：

① 每次做一個H5專案都必須做一個登入註冊，徒增工作量

② 我們多出一個APP後，APP又產生了自己的登入註冊

③ 我們H5專案內嵌至native後，賬號沒法打通

④ 當我們使用者越來越多，子系統越來越雜的時候，我們的使用者會越來越亂

這個時候，我們需要做的一件事情，就是整理所有的子系統，將我們的賬號系統體系化。

資料庫改造

這裡我們做的體系化第一步是對資料庫進行改造，將子系統做到一張公共的表，有過相關經驗的朋友都會知道，子系統較多的公司，應該將基礎使用者表設計得足夠抽象，只需要包含核心資料：

① 使用者id

② 使用者暱稱

③ 使用者手機

④ 使用者密碼

⑤ 頭像&性別&出生年月&身份證&頭像……

當然每個子系統的使用者角色不盡相同，所以需要每個子系統自己維護一個使用者角色表：

我們在處理使用者表的時候，除了抽象基礎使用者資訊時，有可能還需要一層業務公共層，以我們公司為例，多數使用者是醫生，所以像職稱、所屬醫院這種資訊會經常被用到，這個時候就會出現直接使用這種業務公共表的情況：

子系統A與子系統B都是使用的與子系統C一樣的使用者id，但是他們直接依賴了公共業務關聯，他們在公共業務中獲取了類似科室、職稱等資訊，如果這個體系再擴充套件的話，會是這樣的：

公共H5服務

體系化的第二步是H5整合Server服務，當公共的服務出現後，這裡便需要提供公共的H5頁面，這裡會遇到一個難題需要突破：

① 各個業務有自己的定製，比如註冊時候要求的欄位都不一樣

② UI會成為第一個攔路虎需要你去說服

既然是公共頁面，就需要滿足一些業務的定製需求，當底層框架完善並且統一後，便可以以規範的力量給予業務開發以指導與限制了，只有將公共業務做好後，才能真正提高我們整體的開發效率

第一個問題是業務受限，那就說明公共服務做的不行，不具有通用性，那就改設計，改到滿足就行了

第二個問題，肯定是在我們已經有公共服務的情況下，告訴UI，我們這個是公共服務，是不能亂改的，設計要中性化

要整個公司的人都形成公共服務，以及重用，效率的思維後，大家才會認可這個，在人家不知道或者不認可的情況下，說那麼多也沒用，知行合一才是王道。

一個較為合理的公共頁面可能是這個樣子的：

所以，後期我們的系統就變成了這個樣子了：

當我們這套體系走的足夠遠後，我們整個系統可能就是這樣的了：

打通H5與Native

體系化第三步是整合H5與Native資源，這裡也是所謂的Hybrid體系，只有在前兩步完成後，才能很好的完成這一步，否則就只能稱為內嵌頁，不能叫Hybrid，更不能說是什麼移動體系化。

整合Native與H5的第一步仍舊是賬號打通，一般來說，我們強制要求native中H5只能使用native提供的統一頁面進行登入，不管這個頁面是native的還是H5的。

事實上，我們H5端就登入一塊做了三套頁面一個彈窗，一套賬號登入（廢棄）、一套手機號登入、一套手機號登入並且帶第三方登入，還有在頁面裡面直接彈出的登入框，一個個APP中是不應該允許存在兩個退出賬號或者有個人資訊的地方。

設想，如果H5具有自己的登入，那麼整個情況會變得極其複雜，首先APP具有一套自己的登入，而H5如果與APP登入了不同的賬號，那麼就會存在使用者串了的情況，當然，APP可以監控H5的登入態變化，但這個東西技術實現成本比較高，並且容易出錯，所以我們這邊要求所有H5的登入全部走Native的一套體系，每次Native開啟webview時，如果有cookie就注入webview，這樣前端就自己有登入態了 一旦當app登出賬戶，之前所有的頁面也將全部彈出掉，新開一局，如此一來賬號體系已經打通。

Hybrid化

當做到H5與Native賬號打通後，我們便可以實行我們的Hybrid化程式了，這裡簡單以Header為例。

 

主流Hybrid都是使用的Native的Header，原因有很多：

① 穩定，防假死

我們料不到前端會出什麼錯，特別是第三方網站，一旦前端出錯如果iOS連個退出的按鈕都沒有，那麼就app假死了，這個比crash還討厭

② 體驗

我們在剛開啟一個H5頁面時，可能會有白屏，如果header也不在的話，體驗會比較差

而我們在設計Header互動時候，需要考慮到前端的使用習慣，最好能保持業務程式碼一致，處於不同宿主容器表現不同，這裡的設計是左中右的設計，圖中就是我們能提供的所有header樣式了，不夠也沒辦法咯。

完了我們需要對tagname定製化，header中的所有按鈕的唯一標識為tagname，所以tagname不得重複，其次常用tagname會有一個預設圖示，需要定製化的話，就讀取線上資源。

這裡back比較特殊，在webview中會檢查history的記錄，如果大於1則後退，否則會退回上一步操作。 我們可以看出，back的功能是很單一的，往往不能滿足我們的需求，所以常常使用forward+pop動畫當做back使用，而這一做法將引起令人頭疼的history錯亂問題，針對這種情況我們有一些特殊API，但是因為這個API需要Native支援，所以使用需要慎重，最好是新增一個native介面，用於跳轉後，清除所有的history webview。

Header約定是Hybrid的重要一環，也是移動體系化，技術體系化中重要的一小環，與之對應的會有：

① 分享約定

② 登入喚醒約定

③ 離線包機制

④ 跳轉機制

……

這裡體系化做的足夠好的話就會出現類似微信SDK一般的東西，但是這個要看你們是不是有足夠多的第三方接入方需要你們費這個神了，但是隻要做到這一些，你的移動端便已經體系化了，所有的H5專案的賬號系統與基本native打通是完成了。

這種體系化的東西形成後需要做到通用，比如兩個app能同時執行同一個H5站點，甚至離線包機制都是一致的，header互動也是一致的

資料視覺化

上述工作做完，表現層的東西就做了一大部分了，站在前端的角度的話，可以做的東西好像不多了，其實細細一想，有這種想法真的是圖樣圖森破，就算要把上面的事情做完都要費老大的勁，況且真正的難點可能才真正的開始，如我們第一張圖，我們有一個專案外包了，那個外包的使用者是遊離於我們賬戶體系外的，我們應該如何處理？而更讓我們頭疼的可能是資料收集與分析，猛的回頭，你會發現，對於前端，還有資料視覺化這麼一大坨的東西需要你去挖掘！

隨著技術的沉澱，公司的發展，公司的業務雖然越來越複雜，但是在我們的體系下，都還能很好的運轉，但是業務才是技術的祖宗，我們可能會收到類似這種需求：

① 請給我一下上次迎新活動3個月後的使用者留存率

② 請給我XX推廣人員的訂單推廣率

③ 請給我APP由XX二維碼推廣活動的資料

④ 請告訴我為什麼我們轉化率低

……

使用者&訂單渠道

可以相信，所有這一切必定會將你問懵，一般來說，不是所有前端一開始設計便能考慮到這些問題，也不是考慮到這些問題就能設計得好，這裡簡單以使用者業務渠道做一個說明。

為了解決以上問題，我們在設計使用者表的時候就得新增一些欄位了（比較痛苦的是最開始沒有這些東西，後面加就惱火了）：

① 專案來源，標誌該使用者（訂單）來源於哪個子系統

② 業務來源，標誌該使用者（訂單）來源於什麼渠道

這個渠道就比較複雜了，可以是推廣人的拼音，可以是一個活動的標誌……

這個設計其實比較簡單，就是新增幾個資料表欄位嘛，真正的難點在於前端&native呼叫，一般來說，我們希望業務開發無感的便存入進去了，所以我們可以這樣設計：

① 在url（cookie也行，就是麻煩）上加入一個channel的參

這裡如果不使用cookie需要前端框架做處理，保證每次跳轉將這個channel引數一直帶下去

② 每次ajax請求的時候將這種新增一個入common的欄位，讓server端自動處理

所以，業務開發只需要在url做處理（生成二維碼的時候帶上引數），前端框架統一處理後，每次請求就自動帶上了，比如：

http://medlinker.com/h5/interlocution/index.html?med_channel=qq

native處理方案類似，這裡處理完了，我們便可以收集到使用者（訂單）來源於哪個渠道了，有了這個資料收集便能很好的做後續的分析。

補足體系

上述是業務方的資料收集，這個屬於精準定製結果，直接介面儲存，除此之外，我們還需要對整個子系統進行資料打點採集，比如頁面pv+uv+按鈕點選，這個是比較簡單的需求，如果一個H5站點用於了多個容器（微信、qq），而每個容器（渠道）產生的pv資訊需要記錄起來的話，便會有些麻煩。

資料採集這塊是我最近準備做的東西，事實上這塊我也很有一點一籌莫展的感覺，首先碰到第一個問題就比較令人頭疼？

我們到底是應該自己從無到有做一套採集打點系統還是應該直接使用友盟或者百度統計這種第三方的東西？

這裡因為我也還沒有想清楚，便不做展開，當這塊形成後我們整個體系就變成了這個樣子了：

經過將近一年的努力，我們逐步構建了這個移動體系化，並且正在向各部分添磚加瓦，現在在以下模組仍然有所缺失：

① 資料視覺化缺失，如上所言，這塊是我們接下來需要補足的，這裡又包括了資料採集，儲存，分析，展示多個方面，總之可以做的很多。

② 通用IM訊息系統缺失

我們現在Native使用的自身的IM，H5與Native由於原來北京成都兩個團隊而選擇了融雲體系，現在整個訊息系統沒有打通，這裡是需要打通的，以後就算大家選用第三方的服務，都一定記得讓自己server端做一次收口工作，做一次proxy，這個如果後期需要改造更換訊息系統會輕易的多！

③ 日誌監控

我們的日誌監控與預警一塊做的也不夠完善，這裡包括前端預警與server端預警，這塊接下來要加強

④ 全站https化

……

其實除了上面的一些，應該還有很多其他體系模組沒有被提出，比如：

① 開發環境

一般環境分為開發、QA、預覽（生產某一個機器）、生產四個環境，環境是比較好做區分的，但是難點在於通用的釋出系統與各環境的資料處理問題，比如QA環境就是需要一些生產環境的資料，這個時候該怎麼做？？？

② 小流量釋出

有些時候，我們為了測試，可能需要小流量釋出，一方面為了關注流量變化，一方面為了確認沒有錯誤，我們需要這種系統，同時也需要我們的視覺化系統記錄各種情況的轉化率等資料

這裡也僅僅是我（前端角度）所瞭解的移動體系，也許換個人來，又會大有不同，不管是什麼樣的體系，都一定要保證，自己的公司是有一套開發所依賴的體系的，這個東西會極大的提升開發效率與穩定性！

體系設計

在我看來，體系的設計與出現不是一朝一夕的事情，也不是憑空設計，脫離業務，每當我們需要在我們的技術體系中新增模組的時候都需要思考一些問題：

我們提出的這個東西是要真實解決我們開發中的什麼痛點？

這個會需要我們具有一定的特質：

① 有強烈的意識，能瞭解效能的缺陷，開發效率低下的原因，並能提供有效的處理辦法，再此之上進行抽象

② 對於團隊中擱置的老大難問題，要想辦法進行有效的推動、處理

而，我們體系化的東西也不是過家家產生的，這種比較通用的設計必須要出文件，必須與人商量，技術方案裡必須的流程圖、時序圖都要規範，還要把設計要完成的關鍵引數標註好，最後作為驗收標準。方案出來之後要確認方案如何落地，操作路線是什麼，執行計劃是什麼，怎麼處理團隊間的阻力。

比如我們上面做的通用的登入註冊頁面，就需要相關的文件，要描述清楚，我們這個東西的邊界是什麼，能解決什麼問題，有什麼限制，體系設計推動任重道遠，你我共勉。

工作態度

我在上海工作期間學習到的另一個受用無窮的知識便是“正能量”了，其實正能量並不能讓你多寫幾行程式碼，但是他會令你的工作狀態持續上升，與之對應的是負能量，如果你身邊有小夥伴產生負能量的話，就一定要小心了，負能量就確確實實能讓你少寫幾行程式碼了。

當時攜程無線解散的時候，需要我們併入其他團隊，不知不覺間就生出了一些負面情緒，我們是後爹後媽養的，過去肯定沒好日子過了，於是那段時間各種消沉，也有換工作的準備了；而團隊兩個老大哥的表現卻截然相反，一個老大哥仍舊是勤勤懇懇的工作，幫助團隊乃至整個公司渡過了當時比較困難的技術交接時期，另一個老大哥積極的協助新團隊推動新框架，甚至那個框架都不是我們寫的。

後來，我經常與兩個老大哥交流，一個老大哥（來自華為）傳給了我“忍、滾、狠”的絕技，另一個老大哥帶著我領會了皮實的意義，其實這些道理真的很簡單，我們處於順境的時候，自然意氣風發，那麼當我們處於逆境中的時候，我們就應該自暴自棄、消沉不已嗎？

時至今日，我有點什麼疑惑的地方都經常喜歡請教兩位老大哥，我也從他們身上學到了，其實在抓技術的同時，協調推動能力也是至關重要的，因為現在很多業務都是幾個部門在做，如果沒有良好的推動能力的話，極有可能iOS一套東西，Android一套，前端自成一套，這種對整個公司來說是一種浪費，需要有人站出來整理整合。

團隊戰鬥

我十分喜歡武俠，近期特別喜歡劍雨中的一段戲份：

當時是轉輪王手下三大高手，雷彬、彩戲師、細雨等五人戲份（大S可忽略），彩戲師提出你我三人聯手格殺轉輪王如何，並開出了條件等待交易：

我（彩戲師）只要羅摩遺體

全部財產給雷彬

細雨回去和愛人過小日子

顯然，彩戲師的價碼是足夠讓人動心的，他也提出了相當的誠意，主攻轉輪王去了，這個時候雷彬開始了觀望，然而細雨一聲“你們玩，我回家和相公吃飯去了”，直接把整個交易堵死了。

這部戲其實真的非常精彩，如果他們三突然達成一致跑去圍殺轉輪王，我才會感到奇怪。考慮到電影才過3/4，觀眾可能會說那麼這一切豈不是太輕易了？但是從真實社會閱歷來說，這樁交易達成的概率很低，一個核心原因是：

我們做一件事情時，但煩需要他人合作共事，就一定比一個人難多了，人和人之間想法差異是及其巨大的，就看劍雨幾個主要人物的需求：

① 轉輪王，需要羅摩遺體長jj，好xxoo

② 彩戲師，需要羅摩遺體治病

③ 雷彬，需要錢與不受控制

④ 細雨，需要愛，需要家人不受傷害

⑤ 大S，也許是需要關注吧

可以看到，裡面最核心的利益衝突是來源於轉輪王與彩戲師的，這也是為什麼處於弱者的彩戲師要先出手，表達誠意，其他人可以觀望，可以退出。

同樣，團隊之中，人和人的差異是巨大的，這種差異甚至是難以調和的，在這之中就一定會有一個智障或者特別有私心、或者懶惰、或者喜歡單獨和上級溝通的，只要一個隊友有一項或者幾項毛病，整個團隊就會扯皮，而處理扯皮是內耗的事情，但這種內耗又往往比正經做事要花費更多的精力。

在團隊內，各個小夥伴性格各異，彼此較勁；然後團隊之間又有分別，產品與研發彼此對立，就算一個公司，內部也有派系之分，小至一個家族也會兄弟拆牆，講到底，分的是彼此，爭的是權利，除了自己人就不是自己人，不是自己人就算別人，這個分別不知何時才能停止。

因為是人都會有分別，產品變更了需求，就比開發改了我程式碼更可惡；上海分公司的產品欺負了深圳分公司的研發，又比身邊的死UI更加可惡，大大小小的分別，職位的分別，地域的分別，親疏的分別，人很容易就可以找到和自己不同的族群作為敵人，所以紛爭很難停止，解決分別心這種佛學的話題顯然我們無能為力，所以選人就變得尤為關鍵。

綜上，要讓團隊有戰鬥力：

① 首先就要有好的計劃

② 其次要有好的leader

③ 然後找合適的人

⑤ 最後打到共同的敵人（專案）

好的方向才可能出好的結果，任何沒有計劃的事情都收效甚微，好的leader才能團結團隊，技術要過硬，視野要夠遠，搶業務要凶猛，而慈不掌兵，如果有和團隊氣質不符，甚至起到反作用的，一定要提前剔除（勸退是最後的手段，更多的應該是影響），否則吃虧的是整個團隊。

這裡再強調下leader的作用，團隊的戰鬥力需要leader去激發，leader作為公司的執行意志與核心驅動力，需要起到正確的帶頭作用，要有足夠的責任感與危機感，要善於彙報工作，爭搶業務，如果你的leader總是把業務往外面推，那麼這個leader是不合格的。

因為，我們是來工作，是來賺錢的，我首先是來賺錢的，其次才有團隊小夥伴的戰鬥情誼，如果沒有業務就是沒有KPI，沒有KPI就是沒有錢，連最基本的發展都沒有的話，再好的私交在公司面前也不可持續，我們是因為這份事業才在一起的，夢想&激情這種屬於稀缺的消耗品，不是人人擁有的。

個人與團隊的關係，矛盾而又統一，完全追求個人能力成長最大化必定和團隊利益衝突，如果能合理運用團隊又能打破個人的侷限，所以團隊合作才是突破一切的關鍵，一個人的力量是有限的，遇到困難也更容易突破，如果發現一些事情，團隊中只有你能做，就要小心了。

結語

本來寫此文是因為昨天駕考掛了，當時寫出來的東西，感覺比較消極，於是今日抽一些時間重新整理一番，梳理思緒情感，一起積極面對2017年吧！！！

其實，小公司真的有很多獨有的優勢，很多坑等著你去做，去思考，只要能把這些坑一個個填平，那麼必將會有長足的進步，也能儘快的突破自我瓶頸。

文中想法系個人想法，或許有問題，請積極交流。