在一線做了十年的開發(fā)，經(jīng)歷了網(wǎng)易、百度、騰訊研究院、MIG等幾個地方，陸續(xù)做過3D游戲、2D頁游、瀏覽器、移動端翻譯app等。

積累了一些感悟。必然有依然幼稚的地方，就當拋磚引玉，聊為笑談。

[[228717]]

對于團隊而言，流程太重要了

行軍打仗，你需要一個向?qū)?如果沒有向?qū)?，你需要一個地圖;如果沒有地圖，至少要學習李廣，找一匹識途的老馬;如果你連老馬也沒有，那最好可以三個臭皮匠好好討論，力圖勝過一個諸葛亮;如果三個臭皮匠連好好討論也做不到，那就是典型的烏合之眾了，最好寫代碼前，點上三炷香，斟上一杯濁酒，先拜拜菩薩，再拜拜谷歌。

我個人屬于性格溫和的(程序員大多性格不錯)，但確實見過少數(shù)強勢的人，說很多強勢的話。在技術(shù)上一言而決，一聽到任何反對就上升到私人恩怨。這樣的風格，到底是剛愎自用，還是胸有成竹，就需要仔細判斷了。

為什么說流程重要呢?實際上，如果團隊上有孫悟空存在，去西天取經(jīng)，大概也不需要什么流程，只要方向就可以了。 但作為普通的戰(zhàn)士，應(yīng)該先慮敗。找人算命時，應(yīng)該先聽聽不好的地方，好的地方就不用聽了，總歸是好的，不好的地方一定要聽，這樣才能規(guī)避。

這就是我的態(tài)度：先悲觀一點，劃清底線，考慮在這個底線上你該怎么做?

這是我做開發(fā)的一個習慣，但這個習慣肯定不適用于買房。

怎么劃清底線呢?就是假想團隊中沒有孫悟空了，光靠你唐玄奘、豬八戒和沙和尚，應(yīng)該怎么去取經(jīng)。

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

我經(jīng)歷過一個流程很混亂的階段。都是很多年前的事情了，可以拿出來說說，不涉及單個人。

2011年在百度瀏覽器團隊時遇到幾件讓人影響深刻的事情。 有一次開會，產(chǎn)品拿出Google某個產(chǎn)品的DEMO，里面有一段很酷炫3D 效果，要求開發(fā)加上，只給2天時間，大家目瞪口呆。后續(xù)的開發(fā)為了趕節(jié)奏，導致非常多的bug，又為了修改bug，leader將所有的bug按照人員平均分配，導致不同模塊間的同學相互修改。。。。。實在難以想象。好比讓做花卷的廚子，去修改西湖醋魚的味道。

最初的現(xiàn)象是：bug下降的慢，延伸bug反而增加，每個人都累的半死，代碼風格極其雜亂，為了趕工導致的臨時方案層出不窮;

1. 到了中期：人員離職越來也多，代碼難以維護，新加的需求與之前的臨時方案沖突。
2. 到了后期：想做一些修復，想調(diào)整架構(gòu)，又要保證正常運行，其難度好比在一架飛行的飛機上拆換零件。

然后我也急忙離職了。。。。實在看不到成功的可能性。

后來到了騰訊的團隊，感覺流程就規(guī)范多了。需求和bug有Tapd跟蹤，產(chǎn)品發(fā)布按照節(jié)奏，需求提出前會和開發(fā)反復討論可行性，有專門的質(zhì)量跟蹤，有專門的用戶反饋，每天知道要做什么，也知道明天要做什么。有產(chǎn)品需求，也有開發(fā)需求!這個非常重要。很多團隊，都是只有產(chǎn)品需求，開發(fā)好像牛一樣，耕完地就不管了?

流程其實沒那么復雜，就是各司其責+節(jié)奏。我們都是“哆瑞咪發(fā)梭拉西多”中的一員，各自有各自的責任，然后組合在一起，按照一個節(jié)奏跑起來。把該做的事情與該跑的節(jié)奏定好。

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

網(wǎng)上有一個段子，說有人要用JS實現(xiàn)一個簡單的功能，然后朋友給他推薦了幾十個庫。

真的有必要嗎?具體情況具體分析。

居家過日子，你只需要一套普通的工具就可以了;如果你是修車的，你需要一套修車的工具;如果你是光頭強，你需要一臺伐木機。 吃飯用筷子，用刀叉，都可以，但不要用殺豬刀，不要用丈八長矛!，當然也不能用牙簽。

用什么工具，用什么庫，問問過來人，多在KM上搜索一下。舉個例子：android上加密，用SQLChpher就可以了，微信也在用，你當然可以學習;數(shù)據(jù)庫ORM思想，用KM上推薦的GreenDAO就可以了;PC上3D引擎，用OGRE就可以了;小型游戲DEMO，用Irrlicht足夠;寫WebGL，用ThreeJS足夠。

首先想想：一些大庫hold的住嗎，后續(xù)發(fā)展如何?這些庫對安裝包的體積影響有多大?有沒有調(diào)研過同樣的產(chǎn)品在用什么?

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

架構(gòu)上實用+適用

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

一字長蛇陣、八門金鎖陣，哪個好?iOS都是單個進程，微信Android版本3.5以前是單進程，3.5以后有獨立的網(wǎng)絡(luò)進程; PC瀏覽器的進程架構(gòu)更加復雜，UI進程、內(nèi)核進程、Render進程，而且還有根據(jù)頁面多少的進程調(diào)節(jié)模型。

這些設(shè)計都很好，各有各的道理，都適用于當前的產(chǎn)品。所以我的觀點是：首先分析當前產(chǎn)品的規(guī)模、性質(zhì)，然后再設(shè)計架構(gòu)。

在當前階段達到：開發(fā)效率+架構(gòu)的平衡;并向后展望3個月，或者半年左右，看看架構(gòu)能不能適應(yīng)。

我做騰訊翻譯君時，曾反復猶豫要不要模仿微信加入獨立的網(wǎng)絡(luò)進程。后來逆向了有排在第一二位的競品，最終采用了現(xiàn)在的主功能單進程模型。

產(chǎn)品規(guī)模、人員規(guī)模、功能階段，具體問題具體分析。

既要有攻城之力，也要有熬戰(zhàn)之氣——

BUG

產(chǎn)品開發(fā)完成后，必然有bug。其實開發(fā)人員在工作過程中，是有一定的直覺或者心理預(yù)判的，即：某個功能模塊的質(zhì)量如何。 這里面的質(zhì)量包括：可維護性、擴展性、算法渲染效率，還有就是bug與崩潰率。

功能開發(fā)完成后，就要開始守城了。

bug，一部分產(chǎn)生是由于架構(gòu)帶來的，例如比較復雜的架構(gòu)，會導致復雜的實現(xiàn)細節(jié);

但還有很大部分bug，其實是基于如下三個原因產(chǎn)生的：

1. 對于某個api的不了解，或者對于某個平臺，或者SDK版本的不了解。 舉例而言：andrid里面非主線程，是不能直接處理UI相關(guān)的事情的;JAVA的內(nèi)存釋放也不是絕對的，相互指向是無法釋放的;函數(shù)個數(shù)是有DEX問題制約的---------------------這些bug的產(chǎn)生，也是開發(fā)人員摸索學習的過程，經(jīng)歷過一次就不會再犯了。這是學習廣度與熟練度的問題;
2. 還有一些bug，是由于粗心大意導致的。例如空指針的問題，野指針的問題。在C的開發(fā)中，野指針的問題，GDI句柄的釋放問題，這些都是嚴謹?shù)拇a需要避免的; 而又一些工具，或者方法是可以規(guī)避這些問題的，例如android中的利用@Nullable和@NonNull加強空指針檢測等方法;
3. 還有一些bug，是由于“使用情況各異導致的”。例如：偶現(xiàn)在某個模塊crash。這里的本質(zhì)還是因為邏輯的異常邊界沒有處理好。例如android上的OOM問題，還有PC上UI焦點導致的對象釋放問題。這些異常情況，一部分靠測試發(fā)現(xiàn)，一部分靠用戶反饋，還有一部分就靠自己的異常處理。例如Android中的try catch機制，其實就是遇到異常了，你能糾正錯誤的機會。

自審

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

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

注釋

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

這是我在翻譯君項目中寫注釋的方式。

1：對于很復雜的邏輯，務(wù)必用12345的順序依次寫清楚;

2 ：對于函數(shù)中的某個參數(shù)，需要解釋為什么要設(shè)置這個參數(shù)，尤其是公用工具類里面的函數(shù)---說清楚參數(shù)的背景含義，可以讓其他調(diào)用者理解的更加清晰。

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

代碼結(jié)構(gòu)

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

而且，還有一個重要的好處：代碼結(jié)構(gòu)表現(xiàn)出來的其實是——程序的一個模塊邏輯思想——讓大家工作在不同的區(qū)域。

代碼風格

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

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

安全與逆向

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

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

開發(fā)效率

開發(fā)效率可以用這些方式提升：

1. 構(gòu)建公用工具類，方便大家使用
2. 使用開源的一些包，例如ORM思想的數(shù)據(jù)庫等
3. 可以很快的找到問題。開發(fā)中，找bug的時間，往往是很多的。我用的方法有3個： 使用try catch; 攔截所有crash到我指定的地方;超多的Log，Log有統(tǒng)一的控制開關(guān)。
4. 借力：數(shù)據(jù)上報用燈塔，崩潰上報用bugly，公司KM上很多經(jīng)驗，拿過來用。

安裝包體積

1. TINY壓縮圖片
2. 刪除無效的資源文件

UI渲染效率

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

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

很匆忙的寫的，必然有很幼稚的地方，歡迎斧正。