今天給大家帶來一個大牛的故事，希望給所有學習系統開發的人一點感悟。張生在一線做了十年的開發，經歷了網易、百度、騰訊研究院、MIG 等幾個地方，陸續做過 3D 遊戲、2D 頁遊、瀏覽器、移動端翻譯 app 等。
積累了一些感悟。必然有依然幼稚的地方，就當拋磚引玉，聊爲笑談。喜歡的朋友也可以留下企鵝，大家進一步交流，話不多說;
![]()
一、對於團隊而言，流程太重要了
張生個人屬於性格溫和的(程序員大多性格不錯)，但確實見過少數強勢的人，說很多強勢的話。在技術上一言而決，一聽到任何反對就上升到私人恩怨。這樣的風格，到底是剛愎自用，還是胸有成竹，就需要仔細判斷了。
爲什麼說流程重要呢?實際上，如果團隊上有孫悟空存在，去西天取經，大概也不需要什麼流程，只要方向就可以了。 但作爲普通的戰士，應該先慮敗。找人算命時，應該先聽聽不好的地方，好的地方就不用聽了，總歸是好的，不好的地方一定要聽，這樣才能規避。
張生的態度：先悲觀一點，劃清底線，考慮在這個底線上你該怎麼做?
這是張生做開發的一個習慣，但這個習慣肯定不適用於買房。怎麼劃清底線呢?就是假想團隊中沒有孫悟空了，光靠你唐玄奘、豬八戒和沙和尚，應該怎麼去取經。
這個月走什麼地方，遇到山怎麼走，遇到河怎麼過，遇到路上有妖怪劫道，誰去抵擋。遇到路上有少女要搭救，怎麼辦?這就是流程，是原則。
張生經歷過一個流程很混亂的階段。都是很多年前的事情了，可以拿出來說說，不涉及單個人。
2011年在百度瀏覽器團隊時遇到幾件讓人影響深刻的事情。 有一次開會，產品拿出 Google 某個產品的 DEMO，裏面有一段很酷炫 3D 效果，要求開發加上，只給2天時間，大家目瞪口呆。後續的開發爲了趕節奏，導致非常多的 bug ，又爲了修改 bug ，leader 將所有的 bug 按照人員平均分配，導致不同模塊間的同學相互修改......實在難以想象。好比讓做花捲的廚子，去修改西湖醋魚的味道。
最初的現象是：bug下降的慢，延伸 bug 反而增加，每個人都累的半死，代碼風格極其雜亂，爲了趕工導致的臨時方案層出不窮;
到了中期：人員離職越來也多，代碼難以維護，新加的需求與之前的臨時方案衝突。
到了後期：想做一些修復，想調整架構，又要保證正常運行，其難度好比在一架飛行的飛機上拆換零件。
然後他也急忙離職了......實在看不到成功的可能性。
後來到了騰訊的團隊，感覺流程就規範多了。需求和 bug 有 Tapd 跟蹤，產品發佈按照節奏，需求提出前會和開發反覆討論可行性，有專門的質量跟蹤，有專門的用戶反饋，每天知道要做什麼，也知道明天要做什麼。有產品需求，也有開發需求!這個非常重要。很多團隊，都是隻有產品需求，開發好像牛一樣，耕完地就不管了?
二、不要炫技，老老實實寫代碼
網上有一個段子，說有人要用JS實現一個簡單的功能，然後朋友給他推薦了幾十個庫。
真的有必要嗎?具體情況具體分析。
居家過日子，你只需要一套普通的工具就可以了;如果你是修車的，你需要一套修車的工具;如果你是光頭強，你需要一臺伐木機。 吃飯用筷子，用刀叉，都可以，但不要用殺豬刀，不要用丈八長矛!，當然也不能用牙籤。
用什麼工具，用什麼庫，問問過來人，多在KM上搜索一下。舉個例子：android 上加密，用 SQLChpher就可以了，微信也在用，你當然可以學習;數據庫 ORM 思想，用 KM 上推薦的 GreenDAO 就可以了;PC 上 3D 引擎，用OGRE就可以了;小型遊戲 DEMO，用 Irrlicht 足夠;寫 WebGL，用 ThreeJS 足夠。
首先想想：一些大庫 hold 的住嗎，後續發展如何?這些庫對安裝包的體積影響有多大?有沒有調研過同樣的產品在用什麼?
想清楚了再決定用什麼，最好是跟隨成功項目的腳步。
三、架構上實用+適用
很喜歡曾國藩的一句話：結硬寨、打呆仗。
一字長蛇陣、八門金鎖陣，哪個好?iOS 都是單個進程，微信 Android 版本3.5以前是單進程，3.5以後有獨立的網絡進程; PC 瀏覽器的進程架構更加複雜，UI 進程、內核進程、Render 進程，而且還有根據頁面多少的進程調節模型。
這些設計都很好，各有各的道理，都適用於當前的產品。所以我的觀點是：首先分析當前產品的規模、性質，然後再設計架構。
在當前階段達到：開發效率+架構的平衡;並向後展望3個月，或者半年左右，看看架構能不能適應。
四、既要有攻城之力，也要有熬戰之氣——BUG
產品開發完成後，必然有 bug 。其實開發人員在工作過程中，是有一定的直覺或者心理預判的，即：某個功能模塊的質量如何。 這裏面的質量包括：可維護性、擴展性、算法\渲染效率，還有就是bug與崩潰率。
功能開發完成後，就要開始守城了。
bug，一部分產生是由於架構帶來的，例如比較複雜的架構，會導致複雜的實現細節;
但還有很大部分bug，其實是基於如下三個原因產生的：
對於某個api的不瞭解，或者對於某個平臺，或者 SDK 版本的不瞭解。 舉例而言：android裏面非主線程，是不能直接處理UI相關的事情的;JAVA 的內存釋放也不是絕對的，相互指向是無法釋放的;函數個數是有DEX問題制約的---------------------這些bug的產生，也是開發人員摸索學習的過程，經歷過一次就不會再犯了。這是學習廣度與熟練度的問題;
還有一些bug，是由於粗心大意導致的。例如空指針的問題，野指針的問題。在 C 的開發中，野指針的問題，GDI 句柄的釋放問題，這些都是嚴謹的代碼需要避免的; 而又一些工具，或者方法是可以規避這些問題的，例如 android中 的利用@ Nullable 和@ NonNull 加強空指針檢測等方法;
還有一些bug，是由於“使用情況各異導致的”。例如：偶現在某個模塊crash。這裏的本質還是因爲邏輯的異常邊界沒有處理好。例如 android 上的 OOM 問題，還有 PC 上 UI 焦點導致的對象釋放問題。這些異常情況，一部分靠測試發現，一部分靠用戶反饋，還有一部分就靠自己的異常處理。例如Android中的try catch機制，其實就是遇到異常了，你能糾正錯誤的機會。
![]()
五、自審
每過一段時間，都要站在高空俯視自己，問問：到底是在承擔過去，還是在改變未來。如果你還處於迷茫期或者瓶頸期沒有方向，這裏可以留下企鵝，針對你的情況，我想做過過來人肯定能給你一個不錯的建議和指引。
積累了一些感悟。必然有依然幼稚的地方，就當拋磚引玉，聊爲笑談。喜歡的朋友也可以留下企鵝，大家進一步交流，話不多說;
一、對於團隊而言，流程太重要了
張生個人屬於性格溫和的(程序員大多性格不錯)，但確實見過少數強勢的人，說很多強勢的話。在技術上一言而決，一聽到任何反對就上升到私人恩怨。這樣的風格，到底是剛愎自用，還是胸有成竹，就需要仔細判斷了。
爲什麼說流程重要呢?實際上，如果團隊上有孫悟空存在，去西天取經，大概也不需要什麼流程，只要方向就可以了。 但作爲普通的戰士，應該先慮敗。找人算命時，應該先聽聽不好的地方，好的地方就不用聽了，總歸是好的，不好的地方一定要聽，這樣才能規避。
張生的態度：先悲觀一點，劃清底線，考慮在這個底線上你該怎麼做?
這是張生做開發的一個習慣，但這個習慣肯定不適用於買房。怎麼劃清底線呢?就是假想團隊中沒有孫悟空了，光靠你唐玄奘、豬八戒和沙和尚，應該怎麼去取經。
這個月走什麼地方，遇到山怎麼走，遇到河怎麼過，遇到路上有妖怪劫道，誰去抵擋。遇到路上有少女要搭救，怎麼辦?這就是流程，是原則。
張生經歷過一個流程很混亂的階段。都是很多年前的事情了，可以拿出來說說，不涉及單個人。
2011年在百度瀏覽器團隊時遇到幾件讓人影響深刻的事情。 有一次開會，產品拿出 Google 某個產品的 DEMO，裏面有一段很酷炫 3D 效果，要求開發加上，只給2天時間，大家目瞪口呆。後續的開發爲了趕節奏，導致非常多的 bug ，又爲了修改 bug ，leader 將所有的 bug 按照人員平均分配，導致不同模塊間的同學相互修改......實在難以想象。好比讓做花捲的廚子，去修改西湖醋魚的味道。
最初的現象是：bug下降的慢，延伸 bug 反而增加，每個人都累的半死，代碼風格極其雜亂，爲了趕工導致的臨時方案層出不窮;
到了中期：人員離職越來也多，代碼難以維護，新加的需求與之前的臨時方案衝突。
到了後期：想做一些修復，想調整架構，又要保證正常運行，其難度好比在一架飛行的飛機上拆換零件。
然後他也急忙離職了......實在看不到成功的可能性。
後來到了騰訊的團隊，感覺流程就規範多了。需求和 bug 有 Tapd 跟蹤，產品發佈按照節奏，需求提出前會和開發反覆討論可行性，有專門的質量跟蹤，有專門的用戶反饋，每天知道要做什麼，也知道明天要做什麼。有產品需求，也有開發需求!這個非常重要。很多團隊，都是隻有產品需求，開發好像牛一樣，耕完地就不管了?
二、不要炫技，老老實實寫代碼
網上有一個段子，說有人要用JS實現一個簡單的功能，然後朋友給他推薦了幾十個庫。
真的有必要嗎?具體情況具體分析。
居家過日子，你只需要一套普通的工具就可以了;如果你是修車的，你需要一套修車的工具;如果你是光頭強，你需要一臺伐木機。 吃飯用筷子，用刀叉，都可以，但不要用殺豬刀，不要用丈八長矛!，當然也不能用牙籤。
用什麼工具，用什麼庫，問問過來人，多在KM上搜索一下。舉個例子：android 上加密，用 SQLChpher就可以了，微信也在用，你當然可以學習;數據庫 ORM 思想，用 KM 上推薦的 GreenDAO 就可以了;PC 上 3D 引擎，用OGRE就可以了;小型遊戲 DEMO，用 Irrlicht 足夠;寫 WebGL，用 ThreeJS 足夠。
首先想想：一些大庫 hold 的住嗎，後續發展如何?這些庫對安裝包的體積影響有多大?有沒有調研過同樣的產品在用什麼?
想清楚了再決定用什麼，最好是跟隨成功項目的腳步。
三、架構上實用+適用
很喜歡曾國藩的一句話：結硬寨、打呆仗。
一字長蛇陣、八門金鎖陣，哪個好?iOS 都是單個進程，微信 Android 版本3.5以前是單進程，3.5以後有獨立的網絡進程; PC 瀏覽器的進程架構更加複雜，UI 進程、內核進程、Render 進程，而且還有根據頁面多少的進程調節模型。
這些設計都很好，各有各的道理，都適用於當前的產品。所以我的觀點是：首先分析當前產品的規模、性質，然後再設計架構。
在當前階段達到：開發效率+架構的平衡;並向後展望3個月，或者半年左右，看看架構能不能適應。
四、既要有攻城之力，也要有熬戰之氣——BUG
產品開發完成後，必然有 bug 。其實開發人員在工作過程中，是有一定的直覺或者心理預判的，即：某個功能模塊的質量如何。 這裏面的質量包括：可維護性、擴展性、算法\渲染效率，還有就是bug與崩潰率。
功能開發完成後，就要開始守城了。
bug，一部分產生是由於架構帶來的，例如比較複雜的架構，會導致複雜的實現細節;
但還有很大部分bug，其實是基於如下三個原因產生的：
對於某個api的不瞭解，或者對於某個平臺，或者 SDK 版本的不瞭解。 舉例而言：android裏面非主線程，是不能直接處理UI相關的事情的;JAVA 的內存釋放也不是絕對的，相互指向是無法釋放的;函數個數是有DEX問題制約的---------------------這些bug的產生，也是開發人員摸索學習的過程，經歷過一次就不會再犯了。這是學習廣度與熟練度的問題;
還有一些bug，是由於粗心大意導致的。例如空指針的問題，野指針的問題。在 C 的開發中，野指針的問題，GDI 句柄的釋放問題，這些都是嚴謹的代碼需要避免的; 而又一些工具，或者方法是可以規避這些問題的，例如 android中 的利用@ Nullable 和@ NonNull 加強空指針檢測等方法;
還有一些bug，是由於“使用情況各異導致的”。例如：偶現在某個模塊crash。這裏的本質還是因爲邏輯的異常邊界沒有處理好。例如 android 上的 OOM 問題，還有 PC 上 UI 焦點導致的對象釋放問題。這些異常情況，一部分靠測試發現，一部分靠用戶反饋，還有一部分就靠自己的異常處理。例如Android中的try catch機制，其實就是遇到異常了，你能糾正錯誤的機會。
五、自審
每過一段時間，都要站在高空俯視自己，問問：到底是在承擔過去，還是在改變未來。如果你還處於迷茫期或者瓶頸期沒有方向，這裏可以留下企鵝，針對你的情況，我想做過過來人肯定能給你一個不錯的建議和指引。