小公司的一年，一塊兒看看小公司的前端能夠怎麼作

前言

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

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

如今看來講這種話的小夥伴不過在自我安慰罷了，作的過程當中我確實很努力，也真的很認真，可是最後產生不了成果，作的事情不能落地，那麼這一切的努力能夠說毫無心義。將這一次的駕照考試映射到一次重要項目開發的話：

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

開發的過程當中，研發每天加班，測試也每天加班，可是最後項目上線後就是掛了，那麼以前的努力並不會換來豐收的果實，即未來臨的多是老闆的怒號，團隊的動盪，而不管是考試掛了，仍是項目掛了，都有幸被我經歷了。回頭想一想，人生嘛，什麼都應該經歷一發嘛，深深的體會一下掛了的那種無力感，也是不錯的嘛，想到這裏，我居然有些釋懷的感受，只不過是重頭再來（自我安慰而已啦）......

再回想16年初回到了成都，開始了愉快的「慢節奏」生活。未曾想，如今的公司給予本身的平臺竟然是其它地方所沒有的，不論從工做強度仍是業務複雜度來講，都是很對胃口的，偶爾的工做強度甚至超過了上海，嗯，這個很「成都」。

文中爲我的觀點，不喜勿噴

大公司or小公司

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

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

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

① 身邊不少小夥伴沒有買房可是都有本身的車子

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

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

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

聽過 < demo過 < 實際工做用過 < 實際工做中被坑過 < 實際工做中被屢次坑過或者深刻研究總結過

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

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

而，人的知識除了受限於本身的學習主動性之外，也受限至他的視野，當時個人視野就在前端方面打不開，沒有去研究攜程的日誌統計系統與發佈系統，到如今須要用到這部分知識時才感到苦不堪言然後悔莫及。

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

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

技術體系化

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

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

每一個H5項目有一個本身獨立的登陸註冊，native又有本身的native的登陸註冊，甚至server端的服務都彼此獨立，這樣用戶之間變造成了信息孤島，這會引起不少問題：

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

② 咱們多出一個APP後，APP又產生了本身的登陸註冊

③ 咱們H5項目內嵌至native後，帳號無法打通

④ 當咱們用戶愈來愈多，子系統愈來愈雜的時候，咱們的用戶會愈來愈亂

這個時候，咱們須要作的一件事情，就是整理全部的子系統，將咱們的帳號系統體系化。

數據庫改造

這裏咱們作的體系化第一步是對數據庫進行改造，將子系統作到一張公共的表，有過相關經驗的朋友都會知道，子系統較多的公司，應該將基礎用戶表設計得足夠抽象，只須要包含核心數據：

① 用戶id

② 用戶暱稱

③ 用戶手機

④ 用戶密碼

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

固然每一個子系統的用戶角色不盡相同，因此須要每一個子系統本身維護一個用戶角色表：

 1 //用戶總表
 2 //公司用戶不必定都是子系統的用戶,但子系統用戶必定存在與公司用戶總表中
 3 var users = [
 4     {
 5         id: '1',
 6         phone: '13579246810',
 7         name: '暱稱1',
 8         infos: '其它公共信息'
 9     },
10     {
11         id: '2',
12         phone: '13579246811',
13         name: '暱稱2',
14         infos: '其它公共信息'
15     },
16     {
17         id: '3',
18         phone: '13579246812',
19         name: '暱稱3',
20         infos: '其它公共信息'
21     }
22 ];
23 //子系統A中的用戶表
24 var a_users = [
25     {
26         id: '1',
27         roleId: '1'//遊客
28     },
29     {
30         id: '3',
31         roleId: '2'//超級管理員
32     }
33 ];
34 //子系統B中的用戶表
35 var b_users = [
36     {
37         id: '1',
38         title: '教授'//遊客
39     },
40     {
41         id: '2',
42         roleId: '副教授'//超級管理員
43     }
44 ];
45 //子系統C中的用戶表
46 var c_users = [
47     {
48         id: '2',
49         address: 'xxxx',
50         title: '三甲'//遊客
51     },
52     {
53         id: '3',
54         address: 'xxxx',
55         roleId: '二甲'//超級管理員
56     }
57 ];

咱們在處理用戶表的時候，除了抽象基礎用戶信息時，有可能還須要一層業務公共層，以咱們公司爲例，多數用戶是醫生，因此像職稱、所屬醫院這種信息會常常被用到，這個時候就會出現直接使用這種業務公共表的狀況：

子系統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年吧！！！

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

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

最後，科目三補考求過！！！