乾貨分享：十年大廠資深程序員的開發經驗總結

本文由騰訊雲加社區整理和發佈，原文連接：cloud.tencent.com/developer/article/1004735，內容有刪減和改動。

一、引言

在互聯網一線作了十年的程序開發，經歷了網易、百度、騰訊研究院、MIG 等幾個地方，陸續作過 3D 遊戲、2D 頁遊、瀏覽器、移動端翻譯 app 等。積累了一些感悟，但必然有依然幼稚的地方，就當拋磚引玉，聊爲笑談。

（本文同步發佈於：http://www.52im.net/thread-21...）

二、關於做者

康亮：

騰訊高級工程師；

歷經網易在線遊戲事業部、百度客戶端部門、騰訊研究院、騰訊MIG；

橫跨多個平臺10年開發，目前負責騰訊翻譯君app。

三、對於開發團隊而言，流程過重要了

行軍打仗，你須要一個嚮導；

若是沒有嚮導，你須要一個地圖；

若是沒有地圖，至少要學習李廣，找一匹識途的老馬；

若是你連老馬也沒有，那最好能夠三個臭皮匠好好討論，力圖賽過一個諸葛亮；

若是三個臭皮匠連好好討論也作不到，那就是典型的烏合之衆了，最好寫代碼前，點上三炷香，斟上一杯濁酒，先拜拜菩薩，再拜拜谷歌。

我我的屬於性格溫和的（程序員大多性格不錯），但確實見過少數強勢的人，說不少強勢的話。在技術上一言而決，一聽到任何反對就上升到私人恩怨。這樣的風格，究竟是剛愎自用，仍是成竹在胸，就須要仔細判斷了。

爲何說流程重要呢？

實際上，若是團隊上有孫悟空存在，去西天取經，大概也不須要什麼流程，只要方向就能夠了。 但做爲普通的戰士，應該先慮敗。找人算命時，應該先聽聽很差的地方，好的地方就不用聽了，總歸是好的，很差的地方必定要聽，這樣才能規避。

這就是個人態度：先悲觀一點，劃清底線，考慮在這個底線上你該怎麼作？

這是我作開發的一個習慣，但這個習慣確定不適用於買房。

怎麼劃清底線呢？就是假想團隊中沒有孫悟空了，光靠你唐玄奘、豬八戒和沙和尚，應該怎麼去取經。

這個月走什麼地方，遇到山怎麼走，遇到河怎麼過，遇到路上有妖怪劫道，誰去抵擋。遇到路上有少女要搭救，怎麼辦？這就是流程，是原則。

我經歷過一個流程很混亂的職業階段：都是不少年前的事情了，能夠拿出來講說，不涉及單我的。

2011年在百度瀏覽器團隊時遇到幾件讓人影響深入的事情。 有一次開會，產品拿出 Google 某個產品的 DEMO，裏面有一段很酷炫 3D
效果，要求開發加上，只給2天時間，你們目瞪口呆。後續的開發爲了趕節奏，致使很是多的 bug ，又爲了修改 bug ，leader 將全部的
bug 按照人員平均分配，致使不一樣模塊間的同窗相互修改......實在不可思議。比如讓作花捲的廚子，去修改西湖醋魚的味道。

最初的現象是：bug降低的慢，延伸 bug 反而增長，每一個人都累的半死，代碼風格極其雜亂，爲了趕工緻使的臨時方案層出不窮；

到了中期：人員離職越來也多，代碼難以維護，新加的需求與以前的臨時方案衝突；

到了後期：想作一些修復，想調整架構，又要保證正常運行，其難度比如在一架飛行的飛機上拆換零件。

而後我也急忙離職了......實在看不到成功的可能性。

後來到了騰訊的團隊，感受流程就規範多了。需求和 bug 有 Tapd 跟蹤，產品發佈按照節奏，需求提出前會和開發反覆討論可行性，有專門的質量跟蹤，有專門的用戶反饋，天天知道要作什麼，也知道明天要作什麼。有產品需求，也有開發需求！這個很是重要。不少團隊，都是隻有產品需求，開發好像牛同樣，耕完地就無論了？

流程其實沒那麼複雜，就是各司其責+節奏。咱們都是「哆瑞咪發梭拉西多」中的一員，各自有各自的責任，而後組合在一塊兒，按照一個節奏跑起來。把該作的事情與該跑的節奏定好。

四、不要炫技，老老實實寫代碼

網上有一個段子：說有人要用JS實現一個簡單的功能，而後朋友給他推薦了幾十個庫（哈哈哈！）。

真的有必要嗎？具體狀況具體分析。

1）居家過日子，你只須要一套普通的工具就能夠了；

2）若是你是修車的，你須要一套修車的工具；

3）若是你是光頭強，你須要一臺伐木機。

吃飯用筷子，用刀叉，均可以，但不要用殺豬刀，不要用丈八長矛！固然也不能用牙籤。

用什麼工具，用什麼庫，問問過來人，若是是騰訊內部，能夠多在KM上搜索一下。

舉個例子：

1）android 上加密，用 SQLCipher就能夠了，微信也在用，你固然能夠學習（《微信本地數據庫SQLCipher破解版》）；

2）數據庫 ORM 思想，用 KM 上推薦的 GreenDAO 就能夠了；

3）PC 上 3D 引擎，用OGRE就能夠了；

4）小型遊戲 DEMO，用 Irrlicht 足夠；

5）寫 WebGL，用 ThreeJS 足夠。

首先想一想：一些大庫 hold 的住嗎，後續發展如何？這些庫對安裝包的體積影響有多大？有沒有調研過一樣的產品在用什麼？

想清楚了再決定用什麼，最好是跟隨成功項目的腳步。

五、架構上要遵循：實用+適用的原則

很喜歡曾國藩的一句話：結硬寨、打呆仗。

一字長蛇陣、八門金鎖陣，哪一個好？iOS 都是單個進程，微信 Android 版本3.5之前是單進程，3.5之後有獨立的網絡進程； PC 瀏覽器的進程架構更加複雜，UI 進程、內核進程、Render 進程，並且還有根據頁面多少的進程調節模型。

這些設計都很好，各有各的道理，都適用於當前的產品。

因此個人觀點是：首先分析當前產品的規模、性質，而後再設計架構。

在當前階段達到：開發效率+架構的平衡；並向後展望3個月或者半年左右：看看架構能不能適應。

我作騰訊翻譯君時，曾反覆猶豫要不要模仿微信加入獨立的網絡進程。後來逆向了有排在第一二位的競品，最終採用瞭如今的主功能單進程模型。

產品規模、人員規模、功能階段，具體問題具體分析。

六、既要有攻城之力，也要有改Bug的熬戰之氣

產品開發完成後，必然有 bug 。其實開發人員在工做過程當中，是有必定的直覺或者心理預判的，即：某個功能模塊的質量如何。 這裏面的質量包括：可維護性、擴展性、算法渲染效率，還有就是bug與崩潰率。

功能開發完成後，就要開始守城了。

bug，一部分產生是因爲架構帶來的，例如比較複雜的架構，會致使複雜的實現細節。

但還有很大部分bug，實際上是基於以下三個緣由產生的：

1）對於某個api的不瞭解，或者對於某個平臺，或者 SDK 版本的不瞭解。舉例而言：android裏面非主線程，是不能直接處理UI相關的事情的；JAVA 的內存釋放也不是絕對的，相互指向是沒法釋放的；函數個數是有DEX問題制約的---------------------這些bug的產生，也是開發人員摸索學習的過程，經歷過一次就不會再犯了。這是學習廣度與熟練度的問題；

2）還有一些bug，是因爲粗枝大葉致使的。例如空指針的問題，野指針的問題。在 C 的開發中，野指針的問題，GDI 句柄的釋放問題，這些都是嚴謹的代碼須要避免的； 而又一些工具，或者方法是能夠規避這些問題的，例如 android中 的利用@ Nullable 和@ NonNull 增強空指針檢測等方法；

3）還有一些bug，是因爲「使用狀況各異致使的」。例如：偶如今某個模塊crash。這裏的本質仍是由於邏輯的異常邊界沒有處理好。例如 android 上的 OOM 問題，還有 PC 上 UI 焦點致使的對象釋放問題。這些異常狀況，一部分靠測試發現，一部分靠用戶反饋，還有一部分就靠本身的異常處理。例如Android中的try catch機制，其實就是遇到異常了，你能糾正錯誤的機會。

七、自審、反思

每過一段時間，都要站在高空俯視本身，問問：究竟是在承擔過去，仍是在改變將來。

若是以前程序代碼質量很差，後面修改問題的時間就會比較多。到了開發的中期，得多問問本身，你在不停的改正之前的錯誤，仍是在作新的東西。 若是修改錯誤的時間多一點，那就要注意本身的代碼質量了！

八、註釋！註釋！

我很喜歡寫註釋。

有大牛說：代碼就是最好的註釋。 惋惜我尚未達到那個程度。

因此，我會把註釋寫的很是清楚：

其一：爲了本身之後維護的方便；

其二：爲了其餘人接手的方便。

我在翻譯君項目中寫註釋的方式：

1）對於很複雜的邏輯，務必用12345的順序依次寫清楚；

2）對於函數中的某個參數，須要解釋爲何要設置這個參數，尤爲是公用工具類裏面的函數---說清楚參數的背景含義，可讓其餘調用者理解的更加清晰。

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

九、代碼結構

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

並且，還有一個重要的好處：代碼結構表現出來的實際上是——程序的一個模塊邏輯思想——讓你們工做在不一樣的區域。

十、代碼風格

代碼風格統一！比如一家人，有叫 Tom 的，有叫安東尼的，還有叫流川楓、石破天、聖傑夫拉斯基，無所適從。

理論上，看一個函數，就能從名稱上區分哪些是成員變量，哪些是局部變量，哪些是全局靜態值。

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

這方面能夠看看阿里團隊作的幾個編碼規範方面的規約，《重磅發佈：《阿里巴巴Android開發手冊(規約)》[附件下載]》、《阿里技術結晶：《阿里巴巴Java開發手冊(規約)-終極版》[附件下載]》。

十一、安全與逆向

這是針對Android說的，還有PC插件也須要考慮。Android 上首先要防止被別人逆向，我成功逆向並從新打包過有第一位和第二位的競品。這彷佛有點難以想象，但確實作到了。加固+混淆+代碼判斷，最好都有。

安全上，能夠看金剛掃描的漏洞，逐一修改就行。

十二、開發效率

開發效率能夠用這些方式提高：

1）構建公用工具類，方便你們使用；

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

3）能夠很快的找到問題。開發中，找 bug 的時間，每每是不少的。我用的方法有3個： 使用 try catch； 攔截全部 crash 到我指定的地方；超多的 Log，Log 有統一的控制開關。

《中國互聯網社交二十年：全民見證的互聯網創業演義》

更多同類文章 ……

（本文同步發佈於：http://www.52im.net/thread-21...）