作為軟件研發人員，我們是軟件產品的直接締造者，軟件產品都要經我們之手來實現。所以，在軟件研發行業，研發人員的生產效率直接影響到研發的時間、成本和質量。
在實際工作中，往往有些人的業務能力或者技術能力并不比別人高出很多，但他的開發效率卻往往令人驚訝。所以，我們應當像追求技術一樣，追求效率。
這里，我個人總結了關于軟件開發效率的幾點心得。
一、思維方式
思想決定高度，要提高生產效率，首先要用思想武裝自己。
1.時刻準備變化
軟件研發與其他行業有個很大的不同，就是軟件產品的生產過程并不直觀，在客戶看來，開發到10%和開發到99%好像沒有什么不同，建房子少有建好一半突然推倒重做的，但做軟件卻頻繁需要重構、擴展、各種改造，容易出現大量變更（當然，變更需要增加工期和費用，這里不細說）。
所以在我們的思想里，開發軟件就要時刻準備好變化，這個準備，不是準備好修改軟件功能，而是從函數到文件到模塊到采用的框架，任何粒度都可能變更，我們必須時刻準備應對變化，應對的核心就是減少變更帶來的影響，降低波動帶來的風險和工作量。
從技術的角度，可以采用的手段有分層、模塊化、抽象化、可擴展、開發封閉、依賴倒轉等，實質就是通過分層、分模塊、抽象接口等方式，把軟件分割成不同粒度，既能方便團隊并行開發，又能靈活方便地進行修改、擴展或重構。
對細節感興趣的話，可以去看google在github上的示范項目android-architecture，MVP的分層、接口類的使用，甚至于對第三方框架的抽象依賴（連rxjava的線程類型都做了抽象）。
2.為失敗而設計
軟件研發是為了走通預先設計的業務邏輯，從而實現軟件價值，但是很多開發者特別是新手開發者容易有一個誤區，就是過度關注“正確”的環境和操作，自己開發時感覺什么都好，一到實際環境就崩，健壯性慘不忍睹。
軟件的運行環境是不可靠的，用戶操作是不可靠的，作為開發者，我們不能決定軟件運行在哪里，是誰在運行，我們能決定的，只有軟件本身。
所以，我們要在整個研發過程中考慮失敗的情況，如果設備型號太老怎么辦，如果網絡連不上怎么辦，如果磁盤沒空間怎么辦，如果用戶沒有點擊“下一步”怎么辦...一個負責任的開發者，要首先想到這些問題。同時，異常處理要遵循一定的原則，此前整理過一篇Java異常捕獲的設計原則
另外，我在開發時有個習慣，只要時間允許，就先從異常處理寫起，把異常分支都梳理出來，異常情況都做好處理和提示，然后再寫“正確”的業務邏輯，事實證明，前期的這點投入，越到后期就越會表現出巨大的優勢，bug的數量和對開發的干擾都降低很多。
3.復用化、配置化和自動化
軟件研發做熟了，就應該對復用化、配置化和自動化的巨大優勢有所領教了，這三個的價值不僅僅在于節約時間，還在于降低質量風險、降低變更成本、規避人為修改/操作帶來的潛在錯誤和不確定性，說到底，人會出錯，但是程序不會出錯，所以，開發者是不可信的、被大量應用所證明過的代碼才是可信的。
換個角度說，我們在開發軟件時，要有意識地去實現這三個特性，凡是兩處及以上重復的代碼/函數，就有必要抽出來做成接口/類庫；凡是邏輯不變但是需要切換參數的，就有必要做成配置化；凡是能用腳本、代碼去實現的邏輯，就有必要做成自動化任務。
不僅是開發、我們甚至可以在日常生活中應用這些思想，看程序員是如何把自動化做到極致的
4.全局觀
現在的軟件體量越來越大，軟件研發都是團隊行為，分工越來越細，每個開發者只負責軟件的一部分，這對于團隊來說可以提高效率、節省時間和成本，但是對開發者個人來說，容易陷入自己那一小部分技術和業務，久而久之，就缺少了全局觀。
對于軟件來說，他的價值在作為整體運轉起來時，才能體現。一葉障目的開發者，很容易卡在涉及軟件整體邏輯的問題上進行不下去，或者做出過于復雜的邏輯，事倍功半。
個人建議，開發者一定不能丟棄全局觀，平時多了解整個產品的業務和價值，知道整個軟件的結構都有哪些部分，明白自己負責的模塊在哪個位置，起什么作用。在做具體功能前，最好先想清楚整個邏輯，數據流向是什么樣子，邏輯分支都有哪些，有沒有限制條件制約，盡量在動手寫代碼前，先找到問題，多找同事或業務進行討論，胸有成竹，才能事半功倍。
5.自我管理
作為軟件研發人員，應該主動了解業務、積極提升技術，努力拓展視野，不過在這里，我們主要從生產效率的角度看看，怎么更好更快地完成開發任務。
首先要正確認識任務目標：我們前面說過，研發人員是軟件的直接締造者，所以我們自己要對開發任務有清楚的認識，目標產品在什么環境下運作，由誰操作，產生什么價值，有哪些風險，業務數據/流程從哪里來到哪里去...如果開發者自己都含糊不清，就很難產出合格的產品，更不用說生產效率。
然后要管理好工作計劃和任務清單：不論是團隊也好，單干也罷，研發工作都是有時間和進度要求的，一個明確的工作計劃和任務清單，可以直觀準確的反映自己的工作進度。
當前任務棧和工作記錄：程序員喜歡講“心流”，就是進入一種全身心投入編碼，失去時間概念的工作狀態，但是實際工作中，“心流”狀態很容易會被各種事情打斷，我們不能指望把所有人拒之門外，只能盡量把“心流”的進度保存下來。個人喜歡用一個記事本記錄當前要實現的任務目標，在工作中每遇到一個問題，就羅列出來，解決之后，再做好標記，這個記事本只增不刪，把記錄分組標記上日期，就是最好的每日工作記錄，既能保存思路，又有助于回頭梳理不足。
二、技術儲備、代碼儲備和團隊儲備
軟件研發是需要長期積累的，儲備越多，選擇越多，能用于提升生產效率的手段也就越多。我把儲備分為技術儲備、代碼儲備和團隊儲備三類。
1.跟蹤與分享新技術
軟件研發是個生命力和創造力很旺盛的行業，我們做軟件研發既要考慮成熟技術的穩健可靠，又要理解新技術的便利和突破，保持追蹤新的技術風向，才能更好地平衡新技術與成熟技術的應用。
技術儲備工作需要持續的投入和關注，單就Android開發來說，需要跟蹤的框架就包括：網絡訪問框架、圖片加載框架、緩存框架、Json解析框架、事件總線、ORM框架、自定義控件、自定義動畫、數據統計、異常搜集、推送、安全加固；另外編程思想或工具有MVC/MVP、RxJava鏈式編碼、注解式框架等。
當然技術儲備要有選擇的使用，在工程領域，不是最新的好，也不是成熟的好，視具體需要，合適的才最好。
2.建立共享代碼庫
每次研發完成之后，我們的收獲其實不止有軟件產品，也不止是獲得的經驗，我們在開發過程中，一定會抽象出一些工具類、甚至框架，這些代碼可以在團隊內部共享，既提高開發速度、避免二次開發，又能在廣泛的使用中暴露缺陷、迅速提高質量。
相對于每個項目自己的工具類，共享代碼庫雖然能提高開發效率，但是也放大了風險，一旦出現問題，會波及整個產品線上的多個產品，必須嚴格控制質量和性能，強調其擴展性和兼容性，建立持續改進機制。
至于代碼托管的問題，我此前分享過如何在AS+svn環境下建立和維護團隊通用庫，可以聊做參考。
3.建立團隊規范
在團隊開發中，我們要做的儲備工作主要是規范性，建立和遵循良好的代碼規范，既可以保證團隊成員之間的代碼可讀性，又能在代碼合并、工作移交等細節上節省大量時間。
三、輔助工具
每個程序員都有自己慣用的快捷鍵，也有自己偏好的一些輔助工具，這些能大大提升我們的開發效率。
個人此前整理過一部分輔助工具或配置項，包括：
后續還將增加一些插件類工具的使用介紹。
四、定期總結
很多程序員只喜歡寫代碼，不喜歡寫文字，這其實是一種浪費。
從技術角度上，定期總結能方便自己日后回顧，我自己就經常查閱自己以前的總結，當做技術字典來用，一些沒有及時記錄下來的思路或技術，就很遺憾地丟失或忘記了。
從交流的角度，定期總結能鍛煉我們的表達能力，如果我們的總結有問題，會有大神出來評論反饋，幫助我們認識到誤區。
另外，定期總結，即是鼓勵也是鞭策，能讓我們直觀認識到自己近期的成長和進度，敦促我們跟上時代，這樣，賺錢吃飯也有底氣...
