有哪些能夠提高編程效率的技巧和方法?

編程效率

編程

傳說程序員打字速度要快,不少人仍然會以這樣一個標準來片面判斷技術水平.前端

拜託,你是一個程序員,不是一個打字員,打字快能夠表明一些,但也並不表明什麼.android

互聯網行業還在糾結打字速度的,不是外行,就是一個沒有獨立思考的人.ios

如何提高

代碼

所謂提高,就是在現有的基礎上進行優化,讓結果比當前更好.程序員

提高編程效率,能夠理解爲一樣的或相似的一個項目,一個模塊,一個功能,可以更快更方便用更少的時間來實現.編程

這一次作過,下一次再作一樣的,由於熟悉因此耗時更少,這種提高不叫提高,叫作重複勞動.安全

重複勞動可以提高的效率頗有限,重複一萬次一樣的流程,除了增長熟悉度之外,沒有任何價值和效率可言.函數

既有比較,就應該記錄當前事物的耗時時間,對比下一次的耗時,來得出效率結果.性能

既有提高,就應當分析哪些模塊能夠作的更快,哪些事物致使了效率低下?字體

編碼習慣

習慣

因爲不一樣行業和技術有不一樣的適用場景,不可能一套方法適合全部.優化

如下內容僅爲隨筆,適合我的的獨立思考和分析(前端).

在項目提測上線以前,是最適合進行小步優化的時候,由於一旦上線,以前的代碼就不能隨意改動.

在開發週期內,即便任務再緊迫,加班多嚴重,精神多疲憊,也要儘可能以一天,三天,一週爲單位,進行整理和優化.

全局變量

變量

若是你發現一個值在多個頁面共享或者在不一樣地方使用過,那麼能夠及時設置爲全局變量.

常見的如H5判斷手機型號是android仍是ios,屏幕的可視區大小,統一的字體配色和背景色等.

這樣作的好處有如下幾點:

  • 存儲一次,屢次複用(不用每次在須要的地方都從新用方法獲取一遍)
  • 全局更改,只需修改值一次,全部用到的地方都自動統一(沒必要一個一個修改,不會有遺漏和改錯的問題)
  • 方便多模塊多系統共享,方即可視化數據(公共參數和配置一目瞭然,其做用也一目瞭然)

固然,考慮效率的同時也要考慮性能等問題,在合適的地方必定要及時用上,避免沒必要要的時間浪費.

函數封裝

封裝

一樣的,若是一個一樣或者相似的方法,重複使用了屢次,就能夠進行函數封裝.

函數封裝有不少優勢:

  • 代碼複用(提高效率的關鍵)
  • 提高程序的簡潔性和可讀性
  • 提升代碼的安全性和可移植性

沒有什麼比拿來即用的方式更快的.

如時間格式化,顯示不一樣風格的時間,年月日或者時分秒,或者時間戳等形式.

這種功能統一的代碼,沒有必要在每個地方都寫上一遍一樣的邏輯.

只須要封裝爲一個方法,在須要的時候調用便可,函數裏面的邏輯咱們只須要在建立的時候思考.

組件抽離

組件

相似於開源的第三方UI庫,把一些經常使用的UI整理成組件,須要的時候按配置使用便可.

於前端而言,界面的任務量佔據了很大的比例,抽離組件,勢在必行.

仍是一句老話,不作重複的勞動,但凡發現屢次使用同一個事物的時候,就應該考慮組件形式.

設計稿先出的前提下,基本能夠了解有哪些元素屢次使用,可是組件既要考慮解耦,也要考慮兼容.

操做說明

操做

有的時候,一個屢次重複的內容是隨着業務的增長和改變而致使的,不必定一開始就是.

這種狀況不少人會選擇複製黏貼代碼片斷,顯然這種方式會更快一些,符合拿來就用的形式.

以上的操做都創建在有必定時間的前提下,若是連基本的開發時間都不夠,再怎麼提高效率也是免談.

不管是從職場仍是我的角度上看,推薦在加班時梳理下代碼層面,在下班後梳理下思惟層面.

你不能期待一成不變的思惟和習慣會有什麼提高效率之類的效果.

前期作的多,是爲了後面作的更少和更快,是否須要,具體操做,自行斟酌.

相關文章
相關標籤/搜索