如何寫出優(yōu)秀的代碼

?

小閆語錄：不要讓過重的負(fù)擔(dān)，在起步時(shí)壓垮你。輕裝上陣，簡化目標(biāo)，堅(jiān)持不懈就夠了。

?

寫了太多屎一樣的代碼，終于不臭了！更多精彩文章請關(guān)注公眾號『Pythonnote』或者『全棧技術(shù)精選』

1.第一坨屎-變量

為了不讓下任『接盤俠』看到代碼罵娘，我勸你善良。請不要使用如下方式命名變量：

1.拼音命名（不會英文就去下載個(gè)某道詞典，翻譯一下嘛。name 總比 mingzi 好辨認(rèn)吧？字?jǐn)?shù)還少，還能國際通用）

2.使用簡單字母命名（a/b等等，別說其他人，過兩天自己都不曉得寫了個(gè)什么鬼）更多精彩文章請關(guān)注公眾號『Pythonnote』或者『全棧技術(shù)精選』

3.異想天開（不要隨便拍腦袋起名，要做到見名知義?？偛荒芤粋€(gè) id 的列表，你叫個(gè) item 吧？xxx_id_list 稍微強(qiáng)一些吧？）

4.不要命名沖突（最起碼在一個(gè)函數(shù)內(nèi)，不能重復(fù)。project 既是生產(chǎn)項(xiàng)目又是測試項(xiàng)目？變量不斷被覆蓋，奇奇怪怪的 bug 就夠你喝一壺的了）

?

這種病的病根兒一般是詞匯量匱乏，治療建議某道翻譯。

?

5.查詢數(shù)據(jù)庫時(shí)，變量與字段名、模型類或者表名不一致（查的 Product 就不要叫 Mobiles；查的 name ，就不要叫 leader ）

2.第二坨屎-注釋

為了第二天代碼還認(rèn)識你，請你添加注釋。

1.一定要添加注釋，最起碼重要的邏輯部分覆蓋到。

2.注釋要清晰、易懂、簡單明了。

3.注釋不是流水賬，不是每一行代碼的解釋，而是某一塊邏輯的說明。

4.對于復(fù)雜的數(shù)據(jù)結(jié)構(gòu)請舉例說明。

5.每個(gè)函數(shù)的說明文檔起碼要有。更多精彩文章請關(guān)注公眾號『Pythonnote』或者『全棧技術(shù)精選』

3.第三坨屎-嵌套

1.不要里三層外三層的 if-else，邏輯判斷可以有，但是一定有更加簡明的表示方法。嵌套的層級太多，不僅難理解，還影響美觀。

2.簡單的一層 if-else ，有時(shí)三元運(yùn)算符會更加方便。

3.若想你的程序執(zhí)行效率高一些，就不要循環(huán)套循環(huán)。

4.無論何時(shí)何地都不要在循環(huán)里面有查詢數(shù)據(jù)庫的語句。也許一次訪問，只需要查詢幾次數(shù)據(jù)庫，但是用戶量大時(shí)，能把你數(shù)據(jù)庫搞癱。多使用一些 bulk_create 或者 bulk_update 等等類似的批量操作方法，一次訪問遠(yuǎn)比多次訪問數(shù)據(jù)庫效率高。

4.第四坨屎-邏輯

1.請將復(fù)雜的邏輯單獨(dú)抽出來做成函數(shù)或者類，不要讓你的接口內(nèi)部過于復(fù)雜。否則即使有注釋，也太晦澀難懂。

?

將復(fù)雜邏輯抽調(diào)后，不光能被其他地方調(diào)用，還能使你的接口清晰明了。

?

2.實(shí)現(xiàn)一個(gè)功能，肯定不止一種方法，要不斷的去優(yōu)化，去尋找一條最快最簡單的路徑。

?

當(dāng)然優(yōu)化的前提是存在，即使用笨辦法也得先實(shí)現(xiàn)再說。

?

5.第五坨屎-校驗(yàn)

1.一定要添加必要的校驗(yàn)操作！一定要添加必要的校驗(yàn)操作！一定要添加必要的校驗(yàn)操作！重要的事情說三遍，想要保證程序的健壯性，永遠(yuǎn)不要相信用戶的任何操作?。ㄓ脩舨皇情_發(fā)人員，一定會做出你想不到的操作。為了保證程序安全、數(shù)據(jù)安全，請?zhí)砑有ｒ?yàn)）更多精彩文章請關(guān)注公眾號『Pythonnote』或者『全棧技術(shù)精選』

2.常用的校驗(yàn)有：為空校驗(yàn)、長度校驗(yàn)、規(guī)則校驗(yàn)、常識性校驗(yàn)（最起碼上限不能低于下限）、業(yè)務(wù)校驗(yàn)、邊界情況校驗(yàn)等。

6.第六坨屎-單元測試

1.自動化遠(yuǎn)比人工可靠。

?

不是說人工偷懶，而是重復(fù)的點(diǎn)點(diǎn)點(diǎn)難免會有遺漏的情況。添加單元測試，就要可靠的多。

?

2.單元測試并不是負(fù)擔(dān)，當(dāng)你重構(gòu)代碼時(shí)，你會發(fā)現(xiàn)它的重要作用！

?

有單元測試做保障，測試通過就代表重構(gòu)成功。不需要重復(fù)界面點(diǎn)點(diǎn)點(diǎn)，太浪費(fèi)時(shí)間。當(dāng)然前提是：你的單元測試是可靠的。

?

3.重要的方法、邏輯，單元測試一定要覆蓋到，它會保證你的程序安全上線！更多精彩文章請關(guān)注公眾號『Pythonnote』或者『全棧技術(shù)精選』

4.code_review 只能是看規(guī)范，看邏輯，肉眼能核對運(yùn)行結(jié)果嗎？提交代碼先跑一遍單元測試，是否可靠的多？

?

這就體現(xiàn)出來自動化測試的好處了，最簡單的方法，在 GitLab 上集成單元測試，這樣提交代碼后自動運(yùn)行單元測試，不通過肯定不會合并到 master ?分支，保證線上環(huán)境安全。

?

7.第七坨屎-重用

1.將公共的代碼抽調(diào)出來，做成公共模塊、通用組件。「減少程序代碼量」，讓程序起飛。

2.重用的優(yōu)點(diǎn)不光是省代碼這么簡單，如果相同的代碼這也有，那也有，出錯怎么辦？改幾遍？「便于維護(hù)」

3.將常用的數(shù)字抽出一個(gè)常數(shù)文件，其他地方調(diào)用變量的形式使用，這樣維護(hù)一個(gè)常數(shù)文件比維護(hù)分散在各個(gè)角落的代碼要好的多。