Android 高效開發之研發效能

在現在紅海廝殺的移動互聯網，快速試錯變得愈來愈重要，敏捷開發也被愈來愈多的團隊所推崇。有些時候爲了效率咱們甚至願意犧牲部分性能，而選擇在合適的時間去償還這些「債務」。咱們都但願在保證質量的前提下，爲本身的團隊提速。

1、組織的研發效能

1.1 何爲研發效能

在討論如何優化組織研發效能以前，先思考一下什麼是研發效能。

咱們日常開發的過程，是從產品的一個需求想法，轉變爲功能而且發佈上線。這個過程會涉及產品、設計、開發、測試，更多的時候可能還會拉上前端、後臺。

產品的交付涉及不少的流程和人員，雖然設計人員出圖很快、咱們開發效率很高，但也並不能表明研發效能一樣很高，研發效能是對整個產品最終交付的速度和質量負責。

研發效能的五個衡量標準：

對於客戶端研發來講，咱們是否是隻要保證按時按質實現需求就能夠了呢？有不少公司，儘管實行 「 996 」 甚至 「 247 」 ，產品、開發和測試看起來的確都很忙了，可是交付速度和質量卻仍然不使人滿意：產品埋怨開發效率低、開發埋怨產品需求不明確、測試埋怨開發質量差、開發埋怨測試發現不了問題等。這在咱們平常開發中太常常出現了。

這是由於什麼呢？對於研發效能這個話題，我觀察了不少團隊和項目，且根據我的的工做經驗，主要有如下兩點思考：

• 提效是每一個人的職責。儘管在 BAT 這些大廠，會有專門的研發效能部門，可是效能的提高並非單單隻依靠效能部門，或者認爲是領導的事情，而是組織裏面每個人都應該去思考的事情。例如天貓設立的效能目標是 「 211 」，也就是 2 周交付週期、1 周開發週期以及 1 小時發佈時長。那團隊中的每個人都應該爲這一共同目標而努力，回顧在每一個發佈迭代中遇到的問題以及改進的建議。
• 提效不只限於寫 Android 代碼。儘管咱們是 Android 開發工程師，可是咱們的工做不該該侷限在寫 Android 代碼上，關鍵仍是解決需求場景。還有需求流程上溝通訊任的優化。只要是對提高效能有幫助的，咱們均可以嘗試去實踐。在創建了這種總體統籌的思惟以後，將來咱們想轉後端、前端，甚至是產品都會有很大的幫助。

參考 Google 的OKR績效考覈制度，Android 團隊應該制定 「 質量 」 「 效能 」 和 「 影響力 」 這三個目標。例如針對 「 效能 」 來講，有的人抽離一個 UI 庫或者動畫庫，有的人寫一個監控工具，有的人提高編譯速度，有的人寫一個 Web 的值班頁面，有的人優化需求評審的流程…

這樣你們集思廣益，一塊兒思考、一塊兒討論，爲達成組織的共同目標而努力。

1.2 應用交付的流程

前面從整個組織的角度，瞭解了研發效能的含義以及衡量它的五個標準。可能大部分開發人員仍是感受整個產品的交付流程相似產品、UI 設計這些環節是研發人員沒法把控的。一個應用至少會通過開發、編譯 CI、測試、灰度和發佈這幾個階段。下面從效能的角度，分別看看每一個階段須要關注什麼問題。

• 開發階段。開發階段解決的是如何用盡量短的時間，完成儘量多的需求，而且保證開發的質量，不至於後期過多的返工。項目的架構應該如何選擇？例如應該採用原生開發，仍是 Web、React Native、Flutter 這樣的跨平臺方案。如何提高團隊人員的能力以及工具和框架的成熟度？有哪些提高團隊工做效率的技巧？
• 編譯、CI 階段。編譯 CI 階段解決的是如何發現和優化開發階段的一些編碼問題，以及快速構建出最終產物。Google 的 Gradle、Facebook 的 Buck 爲編譯速度作了哪些努力？Flutter 的 Hot Reload 爲何能夠這麼快？AspectJ、ASM、ReDex 這三種插樁方法的原理和差異是什麼？
• 測試階段。測試階段是爲了發現交付過程的質量問題。測試的確不容易，自動化測試成本高，也不容易把控發佈質量。那如何可讓測試覆蓋更多的場景，Monkey、性能測試、UI 測試應該怎麼實踐？看看大廠的夥伴是如何作到人人都是測試？
• 灰度、發佈階段。灰度發佈是爲了驗證產品的效果。發佈並非把包丟出去就能夠了，咱們須要對本身的產品負責。那如何準確、快速地評估產品數據？頭條、快手是如何作到精準運營和 A/B 測試？若是遇到疑難的線上問題應該怎麼解決？複雜多變的網絡問題又應該怎樣去定位和分析？

固然爲了提高在這個過程的效率，咱們會用到一些頗有用的第三方工具，例如用於 CodeReview 的 Gerrit、持續集成的 Jenkins、代碼審計的 Coverity 等。工具不只能夠將大量人工操做變成自動化，也能夠方便團隊更好的協做。

項目管理、需求管理、代碼託管、構建 / 部署、測試平臺…都是咱們經常使用的工具，從需求發起到分支管理、代碼 review，再到測試發佈。在過去，這些工具都是各大公司研發效能部門多年的結晶，通常都不肯意對外提供。可是得益於雲時代的到來，如今都願意打包成商品供咱們使用。

固然每一個項目都會有本身特殊的狀況，這些工具也不必定能夠徹底符合咱們的須要，咱們能夠根據本身的狀況選擇合適的服務，或者直接開發本身的工具。

2、我的的研發效率

我的做爲整個組織的一部分，咱們效率的提高也會對組織有正向的做用。特別是對某些小團隊或者獨立開發者來講，我的可能就表明了整個團隊。關於我的效率的提高和時間的管理，有不少書籍專門在講這個內容。下面從我看到的一些很差的現象，談談兩個比較深的體會專一、方法。

2.1 專一

千萬不要碰的東西之一，即是能得到短時間快感的軟件。它們會在不知不覺中偷走你的時間，消磨你的意志力，摧毀你向上的勇氣。

隨着咱們接觸到的信息愈來愈多，愈來愈多的人很難保持對事情的專一力。工做期間常常想着去刷一下抖音、頭條、微信、王者榮耀，強行把時間打破成碎片。

跟產品開了一天的會，他的需求有了，你的代碼呢？

可能也有一部分同窗他們不刷抖音和頭條，可是在上班時間也會被各類郵件、釘釘、會議折磨得痛不欲生。針對這個問題，個人作法是天天上午和下午都會至少保留一個小時「目空一切」的時間，不看郵件、不看釘釘、不接會議。固然有的時候也是沒法避免被老闆當面拉回到「現實」。

常常看到團隊裏面的一些人也存在這種現象，最終表現多是這我的常常「996」，看起來很忙，可是產出並不高，並且我的成長也不明顯。

天天咱們應該須要有一段時間真正的靜下心來工做，並且每過一段時間也要從新審視一下本身的工做，有哪些地方作的不夠好？有沒有什麼事情是本身或者團隊的人正在反覆而低效在作的，是否能夠優化。

2.2 方法

關於方法，也是同窗們常常會出現的問題。

• 作事的方法。曾經看到一些開發人員，很是喜歡用二分法來排查問題。當測試給他報 Bug 時，他會很是熟練的操做 Git 命令，花上一兩個小時打出幾十個驗證包，不辭勞苦地嘗試。固然二分法我也使用過，在毫無頭緒的時候的確能夠「死馬當活馬醫」。可是咱們在使用這個「大殺器」以前，起碼應該通過本身的思考，嘗試正面去迎擊 Bug 自己。
• 提問的方法。在微信和 QQ 羣裏面，常常會看到有些同窗在羣裏問一個問題，可能 Google 一下就能夠獲得答案。而後他們在羣裏灌了一個小時水，最後仍是沒有任何答案。事實上提問題是很是體現技術和職業素養的，咱們在提問題以前須要通過本身的思考和努力。

3、總結

「吾日三省吾身」，不管是組織的研發效能，仍是我的的工做效率，咱們都須要學會常常去回顧和思考，快速演進、快速迭代，爭取將來作得更好。

須要更多相關的代碼源碼等等的能夠加我羣討論哦 本專欄爲那些想要進階成爲高級Android工程師所準備。 從初中級轉向高級工程師須要從技術的廣度，深度上都有必定的造詣。因此本專欄就主要爲你們分享一些技術，技術原理等。 包含源碼解析，自定義View，動畫實現，架構分享等。 內容難度適中，篇幅精煉，天天只需花上十幾分鍾閱讀便可。 你們能夠跟我一塊兒探討，歡迎加羣探討，有flutter—底層開發-性能優化—移動架構—資深UI工程師 —NDK-人工智能相關專業人員和視頻教學資料 。後續還有最新鴻蒙系統相關內容分享。羣號：892872246(進羣能夠選取以下部分資料分享）