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

7
回復
183
查看
打印 上一主題 下一主題
[復制鏈接]

16

主題

16

帖子

547

安幣

手工藝人

從這十年開發中,我積累了一些感悟,必然有依然幼稚的地方,就當拋磚引玉,聊為笑談。
對于團隊而言,流程太重要了
行軍打仗,你需要一個向導:
  • 如果沒有向導,你需要一個地圖。
  • 如果沒有地圖,至少要學習李廣,找一匹識途的老馬。
  • 如果你連老馬也沒有,那最好可以三個臭皮匠好好討論,力圖勝過一個諸葛亮。
  • 如果三個臭皮匠連好好討論也做不到,那就是典型的烏合之眾了,最好寫代碼前,點上三炷香,斟上一杯濁酒,先拜拜菩薩,再拜拜谷歌。
我個人屬于性格溫和的(程序員大多性格不錯),但確實見過少數強勢的人,說很多強勢的話。
在技術上一言而決,一聽到任何反對就上升到私人恩怨。這樣的風格,到底是剛愎自用,還是胸有成竹,就需要仔細判斷了。
為什么說流程重要呢?實際上,如果團隊上有孫悟空存在,去西天取經,大概也不需要什么流程,只要方向就可以了。
但作為普通的戰士,應該先慮敗。找人算命時,應該先聽聽不好的地方,好的地方就不用聽了,總歸是好的,不好的地方一定要聽,這樣才能規避。
這就是我的態度:先悲觀一點,劃清底線,考慮在這個底線上你該怎么做?這是我做開發的一個習慣,但這個習慣肯定不適用于買房。
怎么劃清底線呢?就是假想團隊中沒有孫悟空了,光靠你唐玄奘、豬八戒和沙和尚,應該怎么去取經?
這個月走什么地方,遇到山怎么走,遇到河怎么過,遇到路上有妖怪劫道,誰去抵擋。遇到路上有少女要搭救,怎么辦?這就是流程,是原則。
我經歷過一個流程很混亂的階段。都是很多年前的事情了,可以拿出來說說,不涉及單個人。
2011 年在百度瀏覽器團隊時,遇到幾件讓人印象深刻的事情。有一次開會,產品拿出 Google 某個產品的 DEMO,里面有一段很酷炫 3D 效果,要求開發加上,只給 2 天時間,大家目瞪口呆。
后續的開發為了趕節奏,導致非常多的 Bug ,又為了修改 Bug ,Leader 將所有的 Bug 按照人員平均分配,導致不同模塊間的同學相互修改......實在難以想象。好比讓做花卷的廚子,去修改西湖醋魚的味道。
最初的現象是:Bug下降的慢,延伸 Bug 反而增加,每個人都累的半死,代碼風格極其雜亂,為了趕工導致的臨時方案層出不窮。
到了中期:人員離職越來也多,代碼難以維護,新加的需求與之前的臨時方案沖突。
到了后期:想做一些修復,想調整架構,又要保證正常運行,其難度好比在一架飛行的飛機上拆換零件。
然后我也急忙離職了......因為實在看不到成功的可能性。
后來我到了騰訊的團隊,感覺流程就規范多了。需求和 Bug 有 Tapd 跟蹤,產品發布按照節奏,需求提出前會和開發反復討論可行性,有專門的質量跟蹤和用戶反饋,每天知道要做什么,也知道明天要做什么。
有產品需求,也有開發需求!這個非常重要。很多團隊,都是只有產品需求,開發好像牛一樣,耕完地就不管了?
流程其實沒那么復雜,就是各司其責+節奏。我們都是“哆瑞咪發梭拉西多”中的一員,各自有各自的責任,然后組合在一起,按照一個節奏跑起來。把該做的事情與該跑的節奏定好。
不要炫技,老老實實寫代碼
網上有一個段子,說有人要用 JS 實現一個簡單的功能,然后朋友給他推薦了幾十個庫,真的有必要嗎?
具體情況具體分析。居家過日子,你只需要一套普通的工具就可以了;如果你是修車的,你需要一套修車的工具;如果你是光頭強,你需要一臺伐木機。
吃飯用筷子,用刀叉,都可以,但不要用殺豬刀,不要用丈八長矛!當然也不能用牙簽。用什么工具,用什么庫,問問過來人,多在 KM 上搜索一下。
舉個例子:
  • Android 上加密,用 SQLCipher 就可以了,微信也在用,你當然可以學習。
  • 數據庫 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,其實是基于如下三個原因產生的:
①對于某個 API 的不了解,或者對于某個平臺,或者 SDK 版本的不了解。
舉例而言:Android 里面非主線程,是不能直接處理 UI 相關的事情的;Java 的內存釋放也不是絕對的,相互指向是無法釋放的;函數個數是有 DEX 問題制約的。
這些 Bug 的產生,也是開發人員摸索學習的過程,經歷過一次就不會再犯了。這是學習廣度與熟練度的問題。
②還有一些 Bug,是由于粗心大意導致的。
例如空指針的問題,野指針的問題。在 C 的開發中,野指針的問題,GDI 句柄的釋放問題,這些都是嚴謹的代碼需要避免的。
而有一些工具,或者方法是可以規避這些問題的,例如 Android 中的利用 @Nullable 和 @NonNull 加強空指針檢測等方法。
③還有一些 Bug,是由于“使用情況各異導致的”。
例如:偶現在某個模塊的 crash。這里的本質還是因為邏輯的異常邊界沒有處理好;例如 Android 上的 OOM 問題,還有 PC 上 UI 焦點導致的對象釋放問題。
這些異常情況,一部分靠測試發現,一部分靠用戶反饋,還有一部分就靠自己的異常處理。
例如 Android 中的 try catch 機制,其實就是遇到異常了,你能糾正錯誤的機會。
自審
每過一段時間,都要站在高空俯視自己,問問:到底是在承擔過去,還是在改變未來。
如果之前程序代碼質量不好,后面修改問題的時間就會比較多。到了開發的中期,得多問問自己,你在不停的改正以前的錯誤,還是在做新的東西;如果修改錯誤的時間多一點,那就要注意自己的代碼質量了!
注釋
我很喜歡寫注釋。有大牛說:代碼就是最好的注釋,可惜我還沒有達到那個程度。
所以,我會把注釋寫的非常清楚,有兩點原因:
  • 為了自己以后維護的方便。
  • 為了其他人接手的方便。







上圖是我在翻譯君項目中寫注釋的方式:
  • 對于很復雜的邏輯,務必用 12345 的順序依次寫清楚。
  • 對于函數中的某個參數,需要解釋為什么要設置這個參數,尤其是公用工具類里面的函數。說清楚參數的背景含義,可以讓其他調用者理解的更加清晰。
我一般不用英文寫。雖然這樣看起來格調很低,但勝在大家都能輕松的看懂。
寫代碼不能太傲嬌,寫注釋也不要太傲嬌,目的是讓你的搭檔或者接手者,更輕松的理解,讓她/他少加班。
代碼結構
代碼結構要清晰。有按照功能劃分的,有按照 UI 結構劃分的。還有公用工具類,有數據管理,有主邏輯控制。
不管用哪種思想,有序的代碼結構,可以讓每個人感覺很干凈。好比日本的收納整理技巧讓很多小資推崇,無非就是干凈、整潔、便于管理。
而且,還有一個重要的好處:代碼結構表現出來的其實是——程序的一個模塊\邏輯思想——讓大家工作在不同的區域。




代碼風格
代碼風格統一!好比一家人,有叫 Tom 的,有叫安東尼的,還有叫流川楓、石破天、圣杰夫拉斯基,無所適從。
理論上,看一個函數,就能從名稱上區分哪些是成員變量,哪些是局部變量,哪些是全局靜態值。
除了命名統一外,還有一行代碼最大的寬度,函數的連續調用長度等,頭文件的包含風格,也最好有一個約定。
類的出現時間,創建人名,最好也加上,看起來沒用,但到了追蹤問題時,就能看出時間線的好處。
安全與逆向
這是針對 Android 說的,還有 PC 插件也需要考慮。Android 上首先要防止被別人逆向,我成功逆向并重新打包過有第一位和第二位的競品。
這似乎有點不可思議,但確實做到了。加固+混淆+代碼判斷,最好都有。安全上,可以看金剛掃描的漏洞,逐一修改就行。公司很多工具很好用的!
開發效率
開發效率可以用這些方式提升:
  • 構建公用工具類,方便大家使用。
  • 使用開源的一些包,例如 ORM 思想的數據庫等。
  • 可以很快的找到問題。開發中,找 Bug 的時間,往往是很多的。我用的方法有 3 個:使用 try catch;攔截所有 crash 到我指定的地方;超多的 Log,Log 有統一的控制開關。
  • 借力:數據上報用燈塔,崩潰上報用 bugly,公司 KM 上很多經驗,拿過來用。
安裝包體積
關于開發效率,總結如下兩點:
  • TINY 壓縮圖片
  • 刪除無效的資源文件
UI 渲染效率
UI 是用戶的第一感覺,UI 快并穩定,第一感覺就不會差太多。
管理好內存,基本上就管理好了一半 crash;管理好 UI,等于管理了人機交互感受。UI 上的開發是:渲染效率與渲染效果的平衡。

分享到:  QQ好友和群 QQ空間 微信
收藏
收藏0
支持
支持0
反對
反對0

6

主題

9577

帖子

2865

安幣

Android大神

Rank: 6Rank: 6

沙發
發表于 4 天前 | 只看該作者
幫幫頂頂!!

0

主題

9447

帖子

2402

安幣

Android大神

Rank: 6Rank: 6

板凳
發表于 4 天前 | 只看該作者
幫幫頂頂!!

9

主題

9487

帖子

1804

安幣

Android大神

Rank: 6Rank: 6

QQ達人

地板
發表于 4 天前 | 只看該作者
樓主威武,以后多發干貨,多辦活動~!

7

主題

1萬

帖子

2316

安幣

Android大神

Rank: 6Rank: 6

5#
發表于 4 天前 | 只看該作者
每次我都積極回帖的,想要安幣~

394

主題

1051

帖子

842

安幣

手工藝人

6#
發表于 4 天前 | 只看該作者
感謝大神~

7

主題

9628

帖子

1958

安幣

Android大神

Rank: 6Rank: 6

7#
發表于 4 天前 | 只看該作者
感謝分享,樓主V5~

2

主題

254

帖子

3401

安幣

碼皇(巴士元老)

Rank: 8Rank: 8

8#
發表于 前天 11:10 | 只看該作者
強烈支持樓主ing……
您需要登錄后才可以回帖 登錄 | 立即注冊

本版積分規則

領先的中文移動開發者社區
18620764416
7*24全天服務
意見反饋:[email protected]

掃一掃關注我們

Powered by Discuz! X3.2© 2001-2019 Comsenz Inc.( 粵ICP備15117877號 )

龙江福彩p62开奖 什么端游好玩还能赚钱 杭州麻将爆头什么意思 原子国货汇凭什么赚钱 下班多余的时间怎么赚钱 我中了彩票首页 2018年网上干嘛能赚钱 喜马拉雅听书录制能赚钱吗 利赢彩票苹果 手机阅读转发赚钱 常德闻湘月赚钱吗 棋牌外挂修改器手机版 9A彩票游戏 网上兼职最赚钱的工作 乐走计步赚钱那门兑钱 攒劲甘肃麻将苹果版 电脑挖矿赚钱是怎么样回事