作為騰訊進階工程師，在一線做了十年的開發，經曆了網易、百度、騰訊研究院、MIG等幾個地方，陸續做過3D遊戲、2D頁遊、浏覽器、移動端翻譯app等，積累了一些感悟。必然有依然幼稚的地方，就當抛磚引玉，聊為笑談。
康亮，騰訊進階工程師。曆經網易線上遊戲事業部、百度用戶端部門、騰訊研究院、騰訊MIG。橫跨多個平台10年開發，目前負責騰訊翻譯君app。
在一線做了十年的開發，經曆了網易、百度、騰訊研究院、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，其實是基于如下三個原因産生的：
1 . 對于某個api的不了解，或者對于某個平台，或者SDK版本的不了解。 舉例而言：andrid裡面非主線程，是不能直接處理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說的，還有PC插件也需要考慮。Android上首先要防止被别人逆向，我成功逆向并重新打包過有第一位和第二位的競品。這似乎有點不可思議，但确實做到了。加強+混淆+代碼判斷，最好都有。
安全上，可以看金剛掃描的漏洞，逐一修改就行。公司很多工具很好用的！
十、開發效率
開發效率可以用這些方式提升：
1 . 建構公用工具類，友善大家使用
2 . 使用開源的一些包，例如ORM思想的資料庫等
3 . 可以很快的找到問題。開發中，找bug的時間，往往是很多的。我用的方法有3個： 使用try catch； 攔截所有crash到我指定的地方；超多的Log，Log有統一的控制開關。
4 . 借力：資料上報用燈塔，崩潰上報用bugly，公司KM上很多經驗，拿過來用。
十一、安裝包體積
1 . TINY壓縮圖檔
2 . 删除無效的資源檔案
十二、UI渲染效率
UI是使用者的第一感覺；UI快并穩定，第一感覺就不會差太多；管理好記憶體，基本管理好了一半crash；管理好UI，等于管理了人機互動感受。
UI上的開發是：渲染效率與渲染效果的平衡。
相關推薦：
簡約而不簡單--大衆點評+小程式開發經驗談 - 騰雲閣
此文已由作者授權騰訊雲技術社群釋出，轉載請注明文章出處，擷取更多雲計算技術幹貨，可請前往騰訊雲技術社群
海量技術實踐經驗，盡在雲加社群！
https://cloud.tencent.com/developer