做開發十年，我總結出了這些開發經驗

在一線做了十年的開發，經歷了網易、百度、騰訊研究院、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機制，其實就是遇到異常了，你能糾正錯誤的機會。

五、自審

每過一段時間，都要站在高空俯視自己，問問：到底是在承擔過去，還是在改變未來。

如果之前程序代碼質量不好，后面修改問題的時間就會比較多。到了開發的中期，得多問問自己，你在不停的改正以前的錯誤，還是在做新的東西。 如果修改錯誤的時間多一點，那就要注意自己的代碼質量了！

六、注釋

我很喜歡寫注釋。有大牛說：代碼就是最好的注釋。 可惜我還沒有達到那個程度。所以，我會把注釋寫的非常清楚。其一：為了自己以后維護的方便； 其二：為了其他人接手的方便。

這是我在翻譯君項目中寫注釋的方式。1：對于很復雜的邏輯，務必用12345的順序依次寫清楚；2 ：對于函數中的某個參數，需要解釋為什么要設置這個參數，尤其是公用工具類里面的函數---說清楚參數的背景含義，可以讓其他調用者理解的更加清晰。

我一般不用英文寫。雖然這樣看起來格調很低，但勝在大家都能輕松的看懂。寫代碼不能太傲嬌，寫注釋也不要太傲嬌，目的是讓你的搭檔或者接手者，更輕松的理解，讓她/他少加班。

七、代碼結構

代碼結構要清晰。有按照功能劃分的，有按照 UI 結構劃分的。還有公用工具類，有數據管理，有主邏輯控制。不管用哪種思想，有序的代碼結構，可以讓每個人感覺很干凈。好比日本的收納整理技巧讓很多小資推崇，無非就是干凈、整潔、便于管理。

而且，還有一個重要的好處：代碼結構表現出來的其實是——程序的一個模塊邏輯思想——讓大家工作在不同的區域。

八、代碼風格

代碼風格統一！好比一家人，有叫 Tom 的，有叫安東尼的，還有叫流川楓、石破天、圣杰夫拉斯基，無所適從。理論上，看一個函數，就能從名稱上區分哪些是成員變量，哪些是局部變量，哪些是全局靜態值。

除了命名統一外，還有一行代碼最大的寬度，函數的連續調用長度等，頭文件的包含風格，也最好有一個約定。類的出現時間，創建人名，最好也加上，看起來沒用，但到了追蹤問題時，就能看出時間線的好處。

九、安全與逆向

這是針對Android說的，還有PC插件也需要考慮。Android 上首先要防止被別人逆向，我成功逆向并重新打包過有第一位和第二位的競品。這似乎有點不可思議，但確實做到了。加固+混淆+代碼判斷，最好都有。

安全上，可以看金剛掃描的漏洞，逐一修改就行。公司很多工具很好用的！

十、開發效率

開發效率可以用這些方式提升：

構建公用工具類，方便大家使用。

使用開源的一些包，例如 ORM 思想的數據庫等。

可以很快的找到問題。開發中，找 bug 的時間，往往是很多的。我用的方法有3個： 使用 try catch； 攔截所有 crash 到我指定的地方；超多的 Log，Log 有統一的控制開關。

借力：數據上報用燈塔，崩潰上報用 bugly，公司 KM 上很多經驗，拿過來用。

十一、安裝包體積

TINY 壓縮圖片

刪除無效的資源文件

十二、UI渲染效率

UI 是用戶的第一感覺；UI 快并穩定，第一感覺就不會差太多；管理好內存，基本管理好了一半 crash；管理好 UI，等于管理了人機交互感受。

UI 上的開發是：渲染效率與渲染效果的平衡。