本文由騰訊云加社區整理和發布，原文鏈接：cloud.tencent.com/developer/article/1004735，內容有刪減和改動。
1、引言
在互聯網一線做了十年的程序開發，經歷了網易、百度、騰訊研究院、MIG 等幾個地方，陸續做過 3D 游戲、2D 頁游、瀏覽器、移動端翻譯 app 等。積累了一些感悟，但必然有依然幼稚的地方，就當拋磚引玉，聊為笑談。
（本文同步發布于：http://www.52im.net/thread-2162-1-1.html）
2、關于作者
康亮：
騰訊高級工程師；
歷經網易在線游戲事業部、百度客戶端部門、騰訊研究院、騰訊MIG；
橫跨多個平臺10年開發，目前負責騰訊翻譯君app。
3、對于開發團隊而言，流程太重要了
行軍打仗，你需要一個向導；
如果沒有向導，你需要一個地圖；
如果沒有地圖，至少要學習李廣，找一匹識途的老馬；
如果你連老馬也沒有，那最好可以三個臭皮匠好好討論，力圖勝過一個諸葛亮；
如果三個臭皮匠連好好討論也做不到，那就是典型的烏合之眾了，最好寫代碼前，點上三炷香，斟上一杯濁酒，先拜拜菩薩，再拜拜谷歌。
我個人屬于性格溫和的（程序員大多性格不錯），但確實見過少數強勢的人，說很多強勢的話。在技術上一言而決，一聽到任何反對就上升到私人恩怨。這樣的風格，到底是剛愎自用，還是胸有成竹，就需要仔細判斷了。
為什么說流程重要呢？
實際上，如果團隊上有孫悟空存在，去西天取經，大概也不需要什么流程，只要方向就可以了。 但作為普通的戰士，應該先慮敗。找人算命時，應該先聽聽不好的地方，好的地方就不用聽了，總歸是好的，不好的地方一定要聽，這樣才能規避。
這就是我的態度：先悲觀一點，劃清底線，考慮在這個底線上你該怎么做？
這是我做開發的一個習慣，但這個習慣肯定不適用于買房。
怎么劃清底線呢？就是假想團隊中沒有孫悟空了，光靠你唐玄奘、豬八戒和沙和尚，應該怎么去取經。
這個月走什么地方，遇到山怎么走，遇到河怎么過，遇到路上有妖怪劫道，誰去抵擋。遇到路上有少女要搭救，怎么辦？這就是流程，是原則。
我經歷過一個流程很混亂的職業階段：都是很多年前的事情了，可以拿出來說說，不涉及單個人。
2011年在百度瀏覽器團隊時遇到幾件讓人影響深刻的事情。 有一次開會，產品拿出 Google 某個產品的 DEMO，里面有一段很酷炫 3D 效果，要求開發加上，只給2天時間，大家目瞪口呆。后續的開發為了趕節奏，導致非常多的 bug ，又為了修改 bug ，leader 將所有的 bug 按照人員平均分配，導致不同模塊間的同學相互修改......實在難以想象。好比讓做花卷的廚子，去修改西湖醋魚的味道。
最初的現象是：bug下降的慢，延伸 bug 反而增加，每個人都累的半死，代碼風格極其雜亂，為了趕工導致的臨時方案層出不窮；
到了中期：人員離職越來也多，代碼難以維護，新加的需求與之前的臨時方案沖突；
到了后期：想做一些修復，想調整架構，又要保證正常運行，其難度好比在一架飛行的飛機上拆換零件。
然后我也急忙離職了......實在看不到成功的可能性。
后來到了騰訊的團隊，感覺流程就規范多了。需求和 bug 有 Tapd 跟蹤，產品發布按照節奏，需求提出前會和開發反復討論可行性，有專門的質量跟蹤，有專門的用戶反饋，每天知道要做什么，也知道明天要做什么。有產品需求，也有開發需求！這個非常重要。很多團隊，都是只有產品需求，開發好像牛一樣，耕完地就不管了？
流程其實沒那么復雜，就是各司其責+節奏。我們都是“哆瑞咪發梭拉西多”中的一員，各自有各自的責任，然后組合在一起，按照一個節奏跑起來。把該做的事情與該跑的節奏定好。
▲ 圖左 - “精英團隊”，圖右 - “烏合之眾”
4、不要炫技，老老實實寫代碼
網上有一個段子：說有人要用JS實現一個簡單的功能，然后朋友給他推薦了幾十個庫（哈哈哈！）。
真的有必要嗎？具體情況具體分析。
1）居家過日子，你只需要一套普通的工具就可以了；
2）如果你是修車的，你需要一套修車的工具；
3）如果你是光頭強，你需要一臺伐木機。
吃飯用筷子，用刀叉，都可以，但不要用殺豬刀，不要用丈八長矛！當然也不能用牙簽。
用什么工具，用什么庫，問問過來人，如果是騰訊內部，可以多在KM上搜索一下。
舉個例子：
1）android 上加密，用 SQLCipher就可以了，微信也在用，你當然可以學習（《微信本地數據庫SQLCipher破解版》）；
2）數據庫 ORM 思想，用 KM 上推薦的 GreenDAO 就可以了；
3）PC 上 3D 引擎，用OGRE就可以了；
4）小型游戲 DEMO，用 Irrlicht 足夠；
5）寫 WebGL，用 ThreeJS 足夠。
首先想想：一些大庫 hold 的住嗎，后續發展如何？這些庫對安裝包的體積影響有多大？有沒有調研過同樣的產品在用什么？
想清楚了再決定用什么，最好是跟隨成功項目的腳步。
5、架構上要遵循：實用+適用的原則
很喜歡曾國藩的一句話：結硬寨、打呆仗。
一字長蛇陣、八門金鎖陣，哪個好？iOS 都是單個進程，微信 Android 版本3.5以前是單進程，3.5以后有獨立的網絡進程； PC 瀏覽器的進程架構更加復雜，UI 進程、內核進程、Render 進程，而且還有根據頁面多少的進程調節模型。
這些設計都很好，各有各的道理，都適用于當前的產品。
所以我的觀點是：首先分析當前產品的規模、性質，然后再設計架構。
在當前階段達到：開發效率+架構的平衡；并向后展望3個月或者半年左右：看看架構能不能適應。
我做騰訊翻譯君時，曾反復猶豫要不要模仿微信加入獨立的網絡進程。后來逆向了有排在第一二位的競品，最終采用了現在的主功能單進程模型。
產品規模、人員規模、功能階段，具體問題具體分析。
6、既要有攻城之力，也要有改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機制，其實就是遇到異常了，你能糾正錯誤的機會。
7、自審、反思
每過一段時間，都要站在高空俯視自己，問問：到底是在承擔過去，還是在改變未來。
如果之前程序代碼質量不好，后面修改問題的時間就會比較多。到了開發的中期，得多問問自己，你在不停的改正以前的錯誤，還是在做新的東西。 如果修改錯誤的時間多一點，那就要注意自己的代碼質量了！
▲ 程序員的“進階之路”
8、注釋！注釋！
我很喜歡寫注釋。
有大牛說：代碼就是最好的注釋。 可惜我還沒有達到那個程度。
所以，我會把注釋寫的非常清楚：
其一：為了自己以后維護的方便；
其二：為了其他人接手的方便。
上圖兩個截圖，是我在翻譯君項目中寫注釋的方式：
1）對于很復雜的邏輯，務必用12345的順序依次寫清楚；
2）對于函數中的某個參數，需要解釋為什么要設置這個參數，尤其是公用工具類里面的函數---說清楚參數的背景含義，可以讓其他調用者理解的更加清晰。
我一般不用英文寫。雖然這樣看起來格調很低，但勝在大家都能輕松的看懂。寫代碼不能太傲嬌，寫注釋也不要太傲嬌，目的是讓你的搭檔或者接手者，更輕松的理解，讓她/他少加班。
9、代碼結構
代碼結構要清晰。有按照功能劃分的，有按照 UI 結構劃分的。還有公用工具類，有數據管理，有主邏輯控制。不管用哪種思想，有序的代碼結構，可以讓每個人感覺很干凈。好比日本的收納整理技巧讓很多小資推崇，無非就是干凈、整潔、便于管理。
而且，還有一個重要的好處：代碼結構表現出來的其實是——程序的一個模塊\邏輯思想——讓大家工作在不同的區域。
10、代碼風格
代碼風格統一！好比一家人，有叫 Tom 的，有叫安東尼的，還有叫流川楓、石破天、圣杰夫拉斯基，無所適從。
理論上，看一個函數，就能從名稱上區分哪些是成員變量，哪些是局部變量，哪些是全局靜態值。
除了命名統一外，還有一行代碼最大的寬度，函數的連續調用長度等，頭文件的包含風格，也最好有一個約定。類的出現時間，創建人名，最好也加上，看起來沒用，但到了追蹤問題時，就能看出時間線的好處。
這方面可以看看阿里團隊做的幾個編碼規范方面的規約，《重磅發布：《阿里巴巴Android開發手冊(規約)》[附件下載]》、《阿里技術結晶：《阿里巴巴Java開發手冊(規約)-終極版》[附件下載]》。
11、安全與逆向
這是針對Android說的，還有PC插件也需要考慮。Android 上首先要防止被別人逆向，我成功逆向并重新打包過有第一位和第二位的競品。這似乎有點不可思議，但確實做到了。加固+混淆+代碼判斷，最好都有。
安全上，可以看金剛掃描的漏洞，逐一修改就行。
12、開發效率
開發效率可以用這些方式提升：
1）構建公用工具類，方便大家使用；
2）使用開源的一些包，例如 ORM 思想的數據庫等；
3）可以很快的找到問題。開發中，找 bug 的時間，往往是很多的。我用的方法有3個： 使用 try catch； 攔截所有 crash 到我指定的地方；超多的 Log，Log 有統一的控制開關。
附錄：更多感悟、思考
[1] 程序員的百味人生：
《一個微信實習生自述：我眼中的微信開發團隊》
《微信程序員創業總結：如何提高Android開發效率》
《如何做一個合格的 iOS Team Leader》
《程序員中年危機：拿什么拯救你，我的三十五歲》
《一個魔都程序員的3年：從程序員到CTO的歷練》
《為什么說即時通訊社交APP創業就是一個坑？》
《致我們再也回不去的 Github ...》
《一名90后二流大學程序員的自述：我是如何從“菜鳥”到“辣雞”的》
《一個魔都程序員的3年：從程序員到CTO的歷練》
《選擇比努力更重要：我是如何從流水線工人到程序員的？》
《程序員的抉擇：必須離開帝都——因為除了工作機會，還有什么值得留戀？》
《干了這碗雞湯：從理發店小弟到阿里P10技術大牛》
《程序員神級跳槽攻略：什么時候該跳？做什么準備？到哪里找工作？》
《感悟分享：在騰訊的八年，我的成長之路和職業思考》
《調皮的程序員：Linux之父雕刻在Linux內核中的故事》
《迷茫中前行：一個專科渣渣菜鳥的編程入門感悟》
《機會不給無準備的人：一個Android程序員屢戰屢敗的悲慘校招經歷》
《笑中帶淚的碼農往事：入職三天被開，公司給100塊叫我走人，有我慘？》
《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》
《干貨分享：十年大廠資深程序員的開發經驗總結》
>> 更多同類文章 ……
[2] 即時通訊/社交產品的實踐總結、感悟分享：
《技術往事：微信估值已超5千億，雷軍曾有機會收編張小龍及其Foxmail》
《QQ和微信兇猛成長的背后：騰訊網絡基礎架構的這些年》
《閑話即時通訊：騰訊的成長史本質就是一部QQ成長史》
《騰訊開發微信花了多少錢？技術難度真這么大？難在哪？》
《技術往事：史上最全QQ圖標變遷過程，追尋IM巨人的演進歷史》
《開發往事：深度講述2010到2015，微信一路風雨的背后》
《開發往事：記錄微信3.0版背后的故事（距微信1.0發布9個月時）》
《微信七年回顧：歷經多少質疑和差評，才配擁有今天的強大》
《前創始團隊成員分享：盤點微信的前世今生——微信成功的必然和偶然》
《QQ的成功，遠沒有你想象的那么順利和輕松》
《[技術腦洞] 如果把14億中國人拉到一個微信群里技術上能實現嗎？》
《QQ和微信止步不前，意味著即時通訊社交應用創業的第2春已來？》
《那些年微信開發過的雞肋功能，及其帶給我們的思考》
《為什么說即時通訊社交APP創業就是一個坑？》
《即時通訊創業必讀：解密微信的產品定位、創新思維、設計法則等》
《老羅最新發布了“子彈短信”這款IM，主打熟人社交能否對標微信？》
《盤點和反思在微信的陰影下艱難求生的移動端IM應用》
《QQ現狀深度剖析：你還認為QQ已經被微信打敗了嗎？
《那些年微信開發過的雞肋功能，及其帶給我們的思考》
《漸行漸遠的人人網：十年親歷者的互聯網社交產品復盤和反思》
《中國互聯網社交二十年：全民見證的互聯網創業演義》
>> 更多同類文章 ……
（本文同步發布于：http://www.52im.net/thread-2162-1-1.html）