當前位置:
首頁 > 知識 > 做開發十年,我總結出了這些開發經驗

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

來自:騰雲閣


作者 | 康亮


編輯 | 京露

康亮,騰訊高級工程師。歷經網易在線遊戲事業部、百度客戶端部門、騰訊研究院、騰訊MIG。橫跨多個平台10年開發,目前負責騰訊翻譯君app。


在一線做了十年的開發,經歷了網易、百度、騰訊研究院、MIG等幾個地方,陸續做過3D遊戲、2D頁游、瀏覽器、移動端翻譯app等。


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


一、對於團隊而言,流程太重要了

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


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


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


這就是我的態度:先悲觀一點,劃清底線,考慮在這個底線上你該怎麼做?


這是我做開發的一個習慣,但這個習慣肯定不適用於買房。

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


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


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


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


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

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


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


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


後來到了騰訊的團隊,感覺流程就規範多了。需求和bug有Tapd跟蹤,產品發布按照節奏,需求提出前會和開發反覆討論可行性,有專門的質量跟蹤,有專門的用戶反饋,每天知道要做什麼,也知道明天要做什麼。有產品需求,也有開發需求!這個非常重要。很多團隊,都是只有產品需求,開發好像牛一樣,耕完地就不管了?

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


二、不要炫技,老老實實寫代碼


網上有一個段子,說有人要用JS實現一個簡單的功能,然後朋友給他推薦了幾十個庫。


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


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


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


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


三、架構上實用+適用


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


這些設計都很好,各有各的道理,都適用於當前的產品。所以我的觀點是:首先分析當前產品的規模、性質,然後再設計架構。


在當前階段達到:開發效率+架構的平衡;並向後展望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上的開發是:渲染效率與渲染效果的平衡。


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


本文編號2291,以後想閱讀這篇文章直接輸入2291即可。


輸入m可以獲取到文章目錄


本文內容的相關公眾號推薦


演算法與數據結構


程序員的那點事


更多推薦15個技術類公眾微信


涵蓋:程序人生、演算法與數據結構、黑客技術與網路安全、大數據技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 程序猿 的精彩文章:

Node.js對於Java開發者而言是什麼?
普通程序員如何轉向AI方向
StackOverflow 2017開發者調查報告!
IntelliJ IDEA 2017.1正式發布
為什麼成為一名程序員這麼困難?——從程序新手到准工程師的必經之路

TAG:程序猿 |

您可能感興趣

這些人的腦洞到底是怎麼開發出來的,我也好想要開發一波!
你這個姿勢是我開發的
你這個姿勢是我開發的······
明天起,不這樣開發票就無法報銷!這個小程序,幫你正確開發票
開發人員到底需要掌握哪些開發語言
這場發布會,還是從App開發說起
正式上汛,開發區今年這麼做
小米又開發布會,這次不吹髮燒,開始講情懷了
現代開發人員必備的十款工具,來看看你漏了啥?
我們的大腦,真的只開發了一成?
你的APP開發爛尾,也許一開始就註定了
手機麻將遊戲開發現在怎麼樣了?未來怎麼發展?
《神偷5》?不存在的 開發商表示遊戲開發進度是零
發票新規施行近半月,你找到開發票竅門了嗎?
谷歌開發了個取代安卓的新系統,上手體驗後驚在當場說不出話!
你們先開發出來,我再提需求
帶你走進開發商的折扣圈套,你有上當嗎
如何做一個自我開發的職場達人
如果我們的大腦被完全開發,會發生什麼?