來源 |?https://www.cnblogs.com/yexiaochai/p/6232328.html

前言

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

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

現(xiàn)在看來說這種話的小伙伴不過在自我安慰罷了，做的過程中我確實很努力，也真的很認(rèn)真，但是最后產(chǎn)生不了成果，做的事情不能落地，那么這一切的努力可以說毫無意義。將這一次的駕照考試映射到一次重要項目開發(fā)的話：

產(chǎn)品努力出需求 ->研發(fā)努力加班干 -> 測試努力加班測試 -> 上線 -> 大流量掛啦......

開發(fā)的過程中，研發(fā)天天加班，測試也天天加班，但是最后項目上線后就是掛了，那么之前的努力并不會換來豐收的果實，即將來臨的可能是老板的怒號，團(tuán)隊的動蕩，而不論是考試掛了，還是項目掛了，都有幸被我經(jīng)歷了。

回頭想想，人生嘛，什么都應(yīng)該經(jīng)歷一發(fā)嘛，深深的體會一下掛了的那種無力感，也是不錯的嘛，想到這里，我竟然有些釋懷的感覺，只不過是重頭再來（自我安慰而已啦）......

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

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

大公司or小公司

之前經(jīng)常有人發(fā)文說到底要去小公司還是大公司，思考幾年的經(jīng)歷，其實大公司小公司不重要，好的團(tuán)隊才重要！

大公司一般是什么都有，只需要你有一顆學(xué)習(xí)的心，多折騰多問，便能吸取大量的養(yǎng)分；而小公司也有一個巨大的優(yōu)勢，便是什么都沒有，只要你有心，就能把大公司的東西通通實現(xiàn)一篇，這種實踐來的知識技能可比學(xué)習(xí)要來的珍貴的多！

初到公司時發(fā)現(xiàn)了一種現(xiàn)象：

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

② 多數(shù)小伙伴下班就回家了

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

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

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

風(fēng)之積也不厚，其負(fù)大翼也無力也。網(wǎng)上有很多深度好文，如果沒有一定基礎(chǔ)，其實看了沒有什么意義，只會在心里感嘆，我尼瑪這人好牛逼。

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

而，人的知識除了受限于自己的學(xué)習(xí)主動性以外，也受限至他的視野，當(dāng)時我的視野就在前端方面打不開，沒有去研究攜程的日志統(tǒng)計系統(tǒng)與發(fā)布系統(tǒng)，到現(xiàn)在需要用到這部分知識時才感到苦不堪言而后悔莫及。

如果各位有機(jī)會到大公司去，一定要認(rèn)認(rèn)真真搞清楚，你自己所在領(lǐng)域里面，該公司的財富積累是什么，然后狠狠去挖掘他，了解他的歷史故事，各種處理細(xì)節(jié)，更多的不是關(guān)注他怎么做，而是要關(guān)注他們?yōu)槭裁催@么做，然后多問多demo，假以時日落地到實踐中，這塊財富就裝入你的口袋了?；叵胱约旱膿駱I(yè)，我事實上是比較后悔自己當(dāng)時為了一點小錢而放棄了阿里（成體系的前端團(tuán)隊）去了百度（新團(tuán)隊，不成體系，甚至前端框架都不統(tǒng)一），如果帶著謙卑的態(tài)度去阿里吸取一番技術(shù)的給養(yǎng)想必會受用無窮吧。

技術(shù)的學(xué)習(xí)，這個需要一個學(xué)習(xí)的態(tài)度，一個學(xué)習(xí)的恒心，其實只要是持續(xù)的投入，便一定會有收獲的。

技術(shù)體系化

在小公司，因為很多基礎(chǔ)設(shè)施都不成熟，這個會讓我們有將技術(shù)業(yè)務(wù)體系化&服務(wù)化的機(jī)會，而體系化后的技術(shù)便是公司的財富也是研發(fā)團(tuán)隊的技術(shù)壁壘，他能大幅度的提高效率，這個是一個生態(tài)體系，一旦生態(tài)體系成熟后，牽一發(fā)而動全一身，就不是任何人能輕易接手的了。

初到公司的時候，我們的系統(tǒng)是這么個狀態(tài)：

每個H5項目有一個自己獨立的登錄注冊，native又有自己的native的登錄注冊，甚至server端的服務(wù)都彼此獨立，這樣用戶之間變形成了信息孤島，這會引發(fā)很多問題：

① 每次做一個H5項目都必須做一個登錄注冊，徒增工作量

② 我們多出一個APP后，APP又產(chǎn)生了自己的登錄注冊

③ 我們H5項目內(nèi)嵌至native后，賬號沒法打通

④ 當(dāng)我們用戶越來越多，子系統(tǒng)越來越雜的時候，我們的用戶會越來越亂

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

數(shù)據(jù)庫改造

這里我們做的體系化第一步是對數(shù)據(jù)庫進(jìn)行改造，將子系統(tǒng)做到一張公共的表，有過相關(guān)經(jīng)驗的朋友都會知道，子系統(tǒng)較多的公司，應(yīng)該將基礎(chǔ)用戶表設(shè)計得足夠抽象，只需要包含核心數(shù)據(jù)：

① 用戶id

② 用戶昵稱

③ 用戶手機(jī)

④ 用戶密碼

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

當(dāng)然每個子系統(tǒng)的用戶角色不盡相同，所以需要每個子系統(tǒng)自己維護(hù)一個用戶角色表：

?//用戶總表?//公司用戶不一定都是子系統(tǒng)的用戶,但子系統(tǒng)用戶一定存在與公司用戶總表中?var?users?=?[?????{????????id:?'1',?????????phone:?'13579246810',?????????name:?'昵稱1',?????????infos:?'其它公共信息'?????},?????{?????????id:?'2',?????????phone:?'13579246811',????????name:?'昵稱2',???????infos:?'其它公共信息'?????},?????{?????????id:?'3',?????????phone:?'13579246812',????????name:?'昵稱3',????????infos:?'其它公共信息'????}?];?//子系統(tǒng)A中的用戶表?var?a_users?=?[?????{?????????id:?'1',?????????roleId:?'1'//游客?????},?????{?????????id:?'3',?????????roleId:?'2'//超級管理員?????}?];?//子系統(tǒng)B中的用戶表?var?b_users?=?[?????{?????????id:?'1',?????????title:?'教授'//游客?????},?????{?????????id:?'2',?????????roleId:?'副教授'//超級管理員?????}?];//子系統(tǒng)C中的用戶表?var?c_users?=?[?????{?????????id:?'2',?????????address:?'xxxx',?????????title:?'三甲'//游客?????},?????{???????id:?'3',???????address:?'xxxx',????????roleId:?'二甲'//超級管理員???} ];

我們在處理用戶表的時候，除了抽象基礎(chǔ)用戶信息時，有可能還需要一層業(yè)務(wù)公共層，以我們公司為例，多數(shù)用戶是醫(yī)生，所以像職稱、所屬醫(yī)院這種信息會經(jīng)常被用到，這個時候就會出現(xiàn)直接使用這種業(yè)務(wù)公共表的情況：

子系統(tǒng)A與子系統(tǒng)B都是使用的與子系統(tǒng)C一樣的用戶id，但是他們直接依賴了公共業(yè)務(wù)關(guān)聯(lián)，他們在公共業(yè)務(wù)中獲取了類似科室、職稱等信息，如果這個體系再擴(kuò)展的話，會是這樣的：

公共H5服務(wù)

體系化的第二步是H5整合Server服務(wù)，當(dāng)公共的服務(wù)出現(xiàn)后，這里便需要提供公共的H5頁面，這里會遇到一個難題需要突破：

① 各個業(yè)務(wù)有自己的定制，比如注冊時候要求的字段都不一樣

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

既然是公共頁面，就需要滿足一些業(yè)務(wù)的定制需求，當(dāng)?shù)讓涌蚣芡晟撇⑶医y(tǒng)一后，便可以以規(guī)范的力量給予業(yè)務(wù)開發(fā)以指導(dǎo)與限制了，只有將公共業(yè)務(wù)做好后，才能真正提高我們整體的開發(fā)效率

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

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

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

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

所以，后期我們的系統(tǒng)就變成了這個樣子了：

當(dāng)我們這套體系走的足夠遠(yuǎn)后，我們整個系統(tǒng)可能就是這樣的了：

打通H5與Native

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

整合Native與H5的第一步仍舊是賬號打通，一般來說，我們強(qiáng)制要求native中H5只能使用native提供的統(tǒng)一頁面進(jìn)行登錄，不管這個頁面是native的還是H5的。

事實上，我們H5端就登錄一塊做了三套頁面一個彈窗，一套賬號登錄（廢棄）、一套手機(jī)號登錄、一套手機(jī)號登錄并且?guī)У谌降卿?，還有在頁面里面直接彈出的登錄框，一個個APP中是不應(yīng)該允許存在兩個退出賬號或者有個人信息的地方。

設(shè)想，如果H5具有自己的登錄，那么整個情況會變得極其復(fù)雜，首先APP具有一套自己的登錄，而H5如果與APP登錄了不同的賬號，那么就會存在用戶串了的情況，當(dāng)然，APP可以監(jiān)控H5的登錄態(tài)變化，但這個東西技術(shù)實現(xiàn)成本比較高，并且容易出錯，所以我們這邊要求所有H5的登錄全部走Native的一套體系，每次Native打開webview時，如果有cookie就注入webview，這樣前端就自己有登錄態(tài)了一旦當(dāng)app注銷賬戶，之前所有的頁面也將全部彈出掉，新開一局，如此一來賬號體系已經(jīng)打通。

Hybrid化

當(dāng)做到H5與Native賬號打通后，我們便可以實行我們的Hybrid化進(jìn)程了，這里簡單以Header為例。

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

① 穩(wěn)定，防假死

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

② 體驗

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

而我們在設(shè)計Header交互時候，需要考慮到前端的使用習(xí)慣，最好能保持業(yè)務(wù)代碼一致，處于不同宿主容器表現(xiàn)不同，這里的設(shè)計是左中右的設(shè)計，圖中就是我們能提供的所有header樣式了，不夠也沒辦法咯。

完了我們需要對tagname定制化，header中的所有按鈕的唯一標(biāo)識為tagname，所以tagname不得重復(fù)，其次常用tagname會有一個默認(rèn)圖標(biāo)，需要定制化的話，就讀取線上資源。

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

Header約定是Hybrid的重要一環(huán)，也是移動體系化，技術(shù)體系化中重要的一小環(huán)，與之對應(yīng)的會有：

① 分享約定

② 登錄喚醒約定

③ 離線包機(jī)制

④ 跳轉(zhuǎn)機(jī)制

......

這里體系化做的足夠好的話就會出現(xiàn)類似微信SDK一般的東西，但是這個要看你們是不是有足夠多的第三方接入方需要你們費這個神了，但是只要做到這一些，你的移動端便已經(jīng)體系化了，所有的H5項目的賬號系統(tǒng)與基本native打通是完成了。

這種體系化的東西形成后需要做到通用，比如兩個app能同時運行同一個H5站點，甚至離線包機(jī)制都是一致的，header交互也是一致的。

數(shù)據(jù)可視化

上述工作做完，表現(xiàn)層的東西就做了一大部分了，站在前端的角度的話，可以做的東西好像不多了，其實細(xì)細(xì)一想，有這種想法真的是圖樣圖森破，就算要把上面的事情做完都要費老大的勁，況且真正的難點可能才真正的開始，如我們第一張圖，我們有一個項目外包了，那個外包的用戶是游離于我們賬戶體系外的，我們應(yīng)該如何處理？而更讓我們頭疼的可能是數(shù)據(jù)收集與分析，猛的回頭，你會發(fā)現(xiàn)，對于前端，還有數(shù)據(jù)可視化這么一大坨的東西需要你去挖掘！

隨著技術(shù)的沉淀，公司的發(fā)展，公司的業(yè)務(wù)雖然越來越復(fù)雜，但是在我們的體系下，都還能很好的運轉(zhuǎn)，但是業(yè)務(wù)才是技術(shù)的祖宗，我們可能會收到類似這種需求：

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

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

③ 請給我APP由XX二維碼推廣活動的數(shù)據(jù)

④ 請告訴我為什么我們轉(zhuǎn)化率低

......

用戶&訂單渠道

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

為了解決以上問題，我們在設(shè)計用戶表的時候就得新增一些字段了（比較痛苦的是最開始沒有這些東西，后面加就惱火了）：

① 項目來源，標(biāo)志該用戶（訂單）來源于哪個子系統(tǒng)

② 業(yè)務(wù)來源，標(biāo)志該用戶（訂單）來源于什么渠道

這個渠道就比較復(fù)雜了，可以是推廣人的拼音，可以是一個活動的標(biāo)志......

這個設(shè)計其實比較簡單，就是新增幾個數(shù)據(jù)表字段嘛，真正的難點在于前端&native調(diào)用，一般來說，我們希望業(yè)務(wù)開發(fā)無感的便存入進(jìn)去了，所以我們可以這樣設(shè)計：

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

這里如果不使用cookie需要前端框架做處理，保證每次跳轉(zhuǎn)將這個channel參數(shù)一直帶下去

② 每次ajax請求的時候?qū)⑦@種新增一個入common的字段，讓server端自動處理

所以，業(yè)務(wù)開發(fā)只需要在url做處理（生成二維碼的時候帶上參數(shù)），前端框架統(tǒng)一處理后，每次請求就自動帶上了，比如：

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

native處理方案類似，這里處理完了，我們便可以收集到用戶（訂單）來源于哪個渠道了，有了這個數(shù)據(jù)收集便能很好的做后續(xù)的分析。

補(bǔ)足體系

上述是業(yè)務(wù)方的數(shù)據(jù)收集，這個屬于精準(zhǔn)定制結(jié)果，直接接口存儲，除此之外，我們還需要對整個子系統(tǒng)進(jìn)行數(shù)據(jù)打點采集，比如頁面pv+uv+按鈕點擊，這個是比較簡單的需求，如果一個H5站點用于了多個容器（微信、qq），而每個容器（渠道）產(chǎn)生的pv信息需要記錄起來的話，便會有些麻煩。

數(shù)據(jù)采集這塊是我最近準(zhǔn)備做的東西，事實上這塊我也很有一點一籌莫展的感覺，首先碰到第一個問題就比較令人頭疼？

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

這里因為我也還沒有想清楚，便不做展開，當(dāng)這塊形成后我們整個體系就變成了這個樣子了：

經(jīng)過將近一年的努力，我們逐步構(gòu)建了這個移動體系化，并且正在向各部分添磚加瓦，現(xiàn)在在以下模塊仍然有所缺失：

① 數(shù)據(jù)可視化缺失，如上所言，這塊是我們接下來需要補(bǔ)足的，這里又包括了數(shù)據(jù)采集，存儲，分析，展示多個方面，總之可以做的很多。

② 通用IM消息系統(tǒng)缺失

我們現(xiàn)在Native使用的自身的IM，H5與Native由于原來北京成都兩個團(tuán)隊而選擇了融云體系，現(xiàn)在整個消息系統(tǒng)沒有打通，這里是需要打通的，以后就算大家選用第三方的服務(wù)，都一定記得讓自己server端做一次收口工作，做一次proxy，這個如果后期需要改造更換消息系統(tǒng)會輕易的多！

③ 日志監(jiān)控

我們的日志監(jiān)控與預(yù)警一塊做的也不夠完善，這里包括前端預(yù)警與server端預(yù)警，這塊接下來要加強(qiáng)

④ 全站https化

......

其實除了上面的一些，應(yīng)該還有很多其他體系模塊沒有被提出，比如：

① 開發(fā)環(huán)境

一般環(huán)境分為開發(fā)、QA、預(yù)覽（生產(chǎn)某一個機(jī)器）、生產(chǎn)四個環(huán)境，環(huán)境是比較好做區(qū)分的，但是難點在于通用的發(fā)布系統(tǒng)與各環(huán)境的數(shù)據(jù)處理問題，比如QA環(huán)境就是需要一些生產(chǎn)環(huán)境的數(shù)據(jù)，這個時候該怎么做？？？

② 小流量發(fā)布

有些時候，我們?yōu)榱藴y試，可能需要小流量發(fā)布，一方面為了關(guān)注流量變化，一方面為了確認(rèn)沒有錯誤，我們需要這種系統(tǒng)，同時也需要我們的可視化系統(tǒng)記錄各種情況的轉(zhuǎn)化率等數(shù)據(jù)

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

體系設(shè)計

在我看來，體系的設(shè)計與出現(xiàn)不是一朝一夕的事情，也不是憑空設(shè)計，脫離業(yè)務(wù)，每當(dāng)我們需要在我們的技術(shù)體系中添加模塊的時候都需要思考一些問題：

我們提出的這個東西是要真實解決我們開發(fā)中的什么痛點？

這個會需要我們具有一定的特質(zhì)：

① 有強(qiáng)烈的意識，能了解性能的缺陷，開發(fā)效率低下的原因，并能提供有效的處理辦法，再此之上進(jìn)行抽象

② 對于團(tuán)隊中擱置的老大難問題，要想辦法進(jìn)行有效的推動、處理

而，我們體系化的東西也不是過家家產(chǎn)生的，這種比較通用的設(shè)計必須要出文檔，必須與人商量，技術(shù)方案里必須的流程圖、時序圖都要規(guī)范，還要把設(shè)計要完成的關(guān)鍵參數(shù)標(biāo)注好，最后作為驗收標(biāo)準(zhǔn)。

方案出來之后要確認(rèn)方案如何落地，操作路線是什么，執(zhí)行計劃是什么，怎么處理團(tuán)隊間的阻力。

比如我們上面做的通用的登錄注冊頁面，就需要相關(guān)的文檔，要描述清楚，我們這個東西的邊界是什么，能解決什么問題，有什么限制，體系設(shè)計推動任重道遠(yuǎn)，你我共勉。

工作態(tài)度

我在上海工作期間學(xué)習(xí)到的另一個受用無窮的知識便是“正能量”了，其實正能量并不能讓你多寫幾行代碼，但是他會令你的工作狀態(tài)持續(xù)上升，與之對應(yīng)的是負(fù)能量，如果你身邊有小伙伴產(chǎn)生負(fù)能量的話，就一定要小心了，負(fù)能量就確確實實能讓你少寫幾行代碼了。

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

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

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

團(tuán)隊?wèi)?zhàn)斗

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

當(dāng)時是轉(zhuǎn)輪王手下三大高手，雷彬、彩戲師、細(xì)雨等五人戲份（大S可忽略），彩戲師提出你我三人聯(lián)手格殺轉(zhuǎn)輪王如何，并開出了條件等待交易：

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

全部財產(chǎn)給雷彬

細(xì)雨回去和愛人過小日子

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

這部戲其實真的非常精彩，如果他們?nèi)蝗贿_(dá)成一致跑去圍殺轉(zhuǎn)輪王，我才會感到奇怪?？紤]到電影才過3/4，觀眾可能會說那么這一切豈不是太輕易了？但是從真實社會閱歷來說，這樁交易達(dá)成的概率很低，一個核心原因是：

這筆買賣涉及了大多數(shù)人的利益，乃至生命，一旦一件事情涉及了多個人的利益，那么這個事情勢必會很慢、很難達(dá)成一致

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

① 轉(zhuǎn)輪王，需要羅摩遺體長jj，好xxoo

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

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

④ 細(xì)雨，需要愛，需要家人不受傷害

⑤ 大S，也許是需要關(guān)注吧

可以看到，里面最核心的利益沖突是來源于轉(zhuǎn)輪王與彩戲師的，這也是為什么處于弱者的彩戲師要先出手，表達(dá)誠意，其他人可以觀望，可以退出。

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

在團(tuán)隊內(nèi)，各個小伙伴性格各異，彼此較勁；然后團(tuán)隊之間又有分別，產(chǎn)品與研發(fā)彼此對立，就算一個公司，內(nèi)部也有派系之分，小至一個家族也會兄弟拆墻，講到底，分的是彼此，爭的是權(quán)利，除了自己人就不是自己人，不是自己人就算別人，這個分別不知何時才能停止。

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

綜上，要讓團(tuán)隊有戰(zhàn)斗力：

① 首先就要有好的計劃

② 其次要有好的leader

③ 然后找合適的人

⑤ 最后打到共同的敵人（項目）

好的方向才可能出好的結(jié)果，任何沒有計劃的事情都收效甚微，好的leader才能團(tuán)結(jié)團(tuán)隊，技術(shù)要過硬，視野要夠遠(yuǎn)，搶業(yè)務(wù)要兇猛，而慈不掌兵，如果有和團(tuán)隊氣質(zhì)不符，甚至起到反作用的，一定要提前剔除（勸退是最后的手段，更多的應(yīng)該是影響），否則吃虧的是整個團(tuán)隊。

這里再強(qiáng)調(diào)下leader的作用，團(tuán)隊的戰(zhàn)斗力需要leader去激發(fā)，leader作為公司的執(zhí)行意志與核心驅(qū)動力，需要起到正確的帶頭作用，要有足夠的責(zé)任感與危機(jī)感，要善于匯報工作，爭搶業(yè)務(wù)，如果你的leader總是把業(yè)務(wù)往外面推，那么這個leader是不合格的。

因為，我們是來工作，是來賺錢的，我首先是來賺錢的，其次才有團(tuán)隊小伙伴的戰(zhàn)斗情誼，如果沒有業(yè)務(wù)就是沒有KPI，沒有KPI就是沒有錢，連最基本的發(fā)展都沒有的話，再好的私交在公司面前也不可持續(xù)，我們是因為這份事業(yè)才在一起的，夢想&激情這種屬于稀缺的消耗品，不是人人擁有的。

個人與團(tuán)隊的關(guān)系，矛盾而又統(tǒng)一，完全追求個人能力成長最大化必定和團(tuán)隊利益沖突，如果能合理運用團(tuán)隊又能打破個人的局限，所以團(tuán)隊合作才是突破一切的關(guān)鍵，一個人的力量是有限的，遇到困難也更容易突破，如果發(fā)現(xiàn)一些事情，團(tuán)隊中只有你能做，就要小心了。

結(jié)語

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

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

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

最后，科目三補(bǔ)考求過?。?！

我到小公司一年，一起來看看小公司前端是怎么做的

大公司or小公司

技術(shù)體系化

數(shù)據(jù)庫改造

公共H5服務(wù)

打通H5與Native

Hybrid化

數(shù)據(jù)可視化

用戶&訂單渠道

補(bǔ)足體系

體系設(shè)計

工作態(tài)度

團(tuán)隊?wèi)?zhàn)斗

結(jié)語

我到小公司一年，一起來看看小公司前端是怎么做的