很多人都會忽略但又極其重要的一點——代碼質量

PHP自學 / 2019-01-02 18:58:05

工作了的人都知道,每個公司都有自己的代碼規范,尤其是bat這樣的大公司更是嚴格要求代碼規范的,所以編寫出高質量的代碼非常重要,最直接的影響就是決定了你的薪資。

下面是對于編寫高質量代碼的一點思考。

信息隱藏原則

信息隱藏是面向對象設計的一個原則,是對封裝和模塊化的一個更高維度的概括。從Java的整個訪問限制設計就體現了信息隱藏的原則,各種訪問修飾符:

public,protect,private

,在類設計的時候,我們就要決定什么暴露給外部,什么隱藏起來。

舉一個例子下面的代碼表示一個有自增ID的

Person

類。

上面的類設計有什么問題呢?它違反了信息隱藏的原則,直接將ID分配的方式暴露了,這會給后面的維護帶來很多問題:當你想給id的范圍做出限制的時候怎么辦?當你在所有代碼中使用

G_MAX_ID

分配ID時突然需要修改ID分配的算法怎么辦?是不是需要去改所有

G_MAX_ID

出現的地方?更好的設計是將ID的分配算法隱藏起來。

咋一看只是將

G_MAX_ID

寫到一個方法里面而已,但是它隱藏了ID分配的算法,讓調用者不需要關心里面的實現,同時控制了變化,不管ID分配算法怎么變,都不會影響其他的代碼。調用者了解的信息越多,受到的影響就越大,信息隱藏可以降低復雜度,控制變化的范圍。

上面的例子只是信息隱藏的一個簡單應用,下面我們來舉幾個其他的應用例子:

為什么不推薦使用魔法值(即未經定義的常量)?:這個明顯違反了信息隱藏的原則,當你將字面量直接寫在代碼里面時,就將信息直接暴露了,后面需要修改的時候,一旦少改了某個地方的字面量,bug就出現了。

循環依賴(即A調用B,B調用A的情況):類或方法之間的循環依賴會破壞信息隱藏,一個很直接的影響就是在測試的時候,A,B都需要同時準備好才能進行測試,而無法mock任意一方。

使用全局變量:這個就不用說了,所有人都可以訪問你的時候信息就暴露無疑了,全局變量能不用就不用。

考慮性能損失:有時候我們為了一些性能上的考慮就破壞信息隱藏原則,將一些變量全局化,這樣性能提高得不多,維護成本卻上升不少,完全是得不償失。

最后總結一下信息隱藏的好處:

隱藏信息即隱藏了復雜度,降低了編程的負擔。

隱藏信息即隱藏了底層變化,以便于在局部控制變化。

一些不太常見的編程技巧

函數(function)與過程(procedure)的選擇

我們先來看看函數與過程區別:

Function:有返回值的方法

Procedure:沒有返回值的方法

平時我們編程其實沒有太區別函數與過程,什么時候用函數,什么時候用過程其實沒有過多的考慮,感覺都可以用。一個選擇的規則就是當你的方法的目的是想返回跟你方法名稱相符的值的時候用函數,否則用過程

舉個例子,我看過很多

XXProcessor

接口里面的方法都是

XX process()

,嚴格來講,這樣的命名是不符合上面的規則的,

process

是一個沒有含義的命名,但是卻有返回值,如果沒有返回值那它的命名才是合理的。

當然了,上面的規則僅供參考,世事無絕對,具體情況具體分析,當你不清楚用函數還是用過程的時候,可以參考這個規則。

使用boolean值來給程序做注釋

相信大家看到一個if語句有很多條件的時候都會特別頭痛,因為很難理解。例如下面的例子:

但如果換成下面的寫法,用boolean值的名字來給if語句注釋,看起來就很好理解了。

下面就如何提高代碼質量給出幾個建議,從現在做起,很重要!!!

1. 打好基礎

寫出高質量代碼,并不是搭建空中樓閣,需要有一定的基礎,這里我重點強調與代碼質量密切相關的幾點:

掌握好開發語言,比如做Android就必須對Java足夠熟悉,《Effective Java》一書就是教授大家如何更好得掌握Java, 寫出高質量Java代碼。

熟悉開發平臺, 不同的開發平臺,有不同的API, 有不同的工作原理,同樣是Java代碼,在PC上寫與Android上寫很多地方不一樣,要去熟悉Android編程的一些特性,iOS編程的一些特性,了解清楚這些,才能寫出更加地道的代碼,充分發揮各自平臺的優勢。

基礎的數據結構與算法,掌握好這些在解決一些特定問題時,可以以更加優雅有效的方式處理。

基礎的設計原則,無需完全掌握23種經典設計模式,只需要了解一些常用的設計原則即可,甚至你也可以只了解什么是低耦合,并在你的代碼中堅持實踐,也能寫出很不錯的代碼。

2. 代碼標準

代碼標準在團隊合作中尤為重要,誰也不希望一個項目中代碼風格各異,看得讓人糟心,即便是個人開發者,現在也需要跟各種開源項目打交道。標準怎么定是一個老生常談的話題,我個人職業生涯中經歷過很多次的代碼標準討論會議,C , C#, Java等等,大家有時會堅持自己的習慣不肯退讓。可現如今時代不一樣了,Google等大廠已經為我們制定好了各種標準,不用爭了,就用這些業界標準吧。

3. 想好再寫

除非你很清楚你要怎么做,否則我不建議邊做邊想。

你真的搞清楚你要解決的問題是什么了嗎?你的方案是否能有效?有沒有更優雅簡單的方案?準備怎么設計它,必要的情況下,需要有設計文檔,復雜一些的設計需要有同行評審,寫代碼其實是很簡單的事情,前提是你得先想清楚。

4. 代碼重構

重構對于代碼質量的重要性不言而喻,反正我是很難一次把代碼寫得讓自己滿意、無可挑剔,《重構》這本書作為業內經典也理應人人必讀,也有其他類似的教授重構技巧的書,有些也非常不錯,遺憾的是我發現很多工作多年的同學甚至都沒有了解過重構的概念。

5. 代碼審查

我曾經聽過一些較高級別的技術分享,竟然還不時聽到一些呼吁大家要做代碼審查的主題,我以為在這個級別的技術會議上,不應再討論代碼審查有什么好,為什么要做代碼審查之類的問題。同時我接觸過相當多所謂國內一線互聯網公司,竟有許多是不做代碼審查的,這一度讓我頗為意外。

這里也不想多談如何做好代碼審查,只是就代碼質量這點,不客氣地說:沒有過代碼審查經歷的同學,往往很難寫出高質量的代碼,尤其是在各種追求速度的糙快猛創業公司。

6. 靜態檢查

很多代碼上的問題,都可以通過一些工具來找到,某些場景下,它比人要靠譜得多,至少不會出現某些細節上的遺漏,同時也能有效幫助大家減少代碼審查的工作量。

Android開發中有Lint, Find bugs, PMD等優秀靜態檢查工具可用,通過改進這些工具找出的問題,就能對語法的細節,規范,編程的技巧有更多直觀了解。

建議最好與持續集成(CI),代碼審查環境配套使用, 每次提交的代碼都能自動驗證是否通過了工具的代碼檢查,通過才允許提交。

7. 充分自測

有一種說法:程序員最害怕的是他自己寫的代碼,尤其是準備在眾人面前show自己的工作成果時,因此在寫完代碼后,需要至少跑一遍基本的場景,一些簡單的異常流。在把你的工作成果提交給測試或用戶前,充分自測是基本的職業素養,不要總想著讓測試幫你找問題,隨便用幾下就Crash的東西,你好意思拿給別人嗎?

8. 善用開源

并非開源的東西,質量就高,但至少關注度較高,使用人數較多,口碑較好的開源項目,質量是有一定保證的,這其中的道理很簡單。即便存在一些問題,也可以通過提交反饋,不斷改進。最重要的是,你自己花時間造的輪子,需要很多精力維護,而充分利用開源項目,能幫助你節省很多時間,把精力專注在最需要你關心的問題上。

從另一個方面來說,開源項目中的一些知名項目,往往是領域內的翹楚所寫,學習這些高手的代碼,能讓你了解到好的代碼應該是怎樣的,培養出更靈敏的嗅覺,識別代碼中的各種味道。

青海快三开奖信息