【51CTO譯文】告別這些常見(jiàn)但卻糟糕的編碼實(shí)踐方式能夠讓我們的工作更為輕松——而開(kāi)發(fā)出的軟件也將更安全且更具可擴(kuò)展性。

根據(jù)“帕累托原則”的說(shuō)法，特定事件最終結(jié)果當(dāng)中的八成往往由由占二成的隨機(jī)性因素所決定。這種劃分方式被稱(chēng)為二八開(kāi)原則，而且?guī)缀跤绊懙搅巳祟?lèi)生產(chǎn)生活當(dāng)中的每一個(gè)領(lǐng)域。

在軟件開(kāi)發(fā)領(lǐng)域，該原則也可以這樣進(jìn)行解讀：大部分問(wèn)題實(shí)際都是由一小部分不良編碼實(shí)踐所引發(fā)。只要消除這部分因素，我們的工作就能變得更輕松也更加富有成效。

在今天的文章中，我們將一同了解十大給軟件開(kāi)發(fā)工作帶來(lái)無(wú)窮困擾的糟糕編碼實(shí)踐活動(dòng)。

1. 代碼當(dāng)中的拼寫(xiě)錯(cuò)誤

這類(lèi)問(wèn)題的出現(xiàn)頻率可能遠(yuǎn)遠(yuǎn)超出大家的想象。這樣的問(wèn)題之所以如此普遍而又難以扼制，主要是因?yàn)橐l(fā)問(wèn)題的根源與我們的編程技術(shù)水平并沒(méi)有必然聯(lián)系。再出色的開(kāi)發(fā)人員也有可能在代碼中不慎寫(xiě)出錯(cuò)誤的變量名或者函數(shù)名，而這最終將成為一股肆虐無(wú)忌而又極具破壞性的力量。更重要的是，準(zhǔn)確找出它們實(shí)在不是件容易的事。

那我們?cè)撊绾谓鉀Q這一難題呢？選擇一套良好的集成開(kāi)發(fā)環(huán)境（簡(jiǎn)稱(chēng)IDE）或者是專(zhuān)門(mén)面向程序員的文本編輯器，這樣能夠顯著降低拼寫(xiě)錯(cuò)誤出現(xiàn)的可能性。除此之外，我們可以選擇另一種解決途徑：有意選擇拼寫(xiě)難度不高的變量與函數(shù)名稱(chēng)，這樣一來(lái)即使出現(xiàn)錯(cuò)誤、發(fā)現(xiàn)難度也不會(huì)太高。最好不要使用receive這類(lèi)詞匯，因?yàn)椴还軝z查多少次、我們都不太可能發(fā)現(xiàn)它被錯(cuò)寫(xiě)成了recieve。

2.代碼內(nèi)容欠缺必要的縮進(jìn)或者格式調(diào)整

請(qǐng)大家一定記得為代碼行設(shè)定縮進(jìn)或者作出格式調(diào)整，否則最終一定會(huì)發(fā)現(xiàn)自己的代碼內(nèi)容既難于閱讀又不容易從中找出錯(cuò)誤。此外，簡(jiǎn)潔清晰的格式規(guī)劃還能提供更為統(tǒng)一的顯示效果，進(jìn)而降低繼任者對(duì)代碼的維護(hù)難度。

如果大家使用的IDE不提供代碼格式自動(dòng)調(diào)整功能，我們可以考慮使用Uncrustify等代碼美化工具，這類(lèi)軟件能夠根據(jù)用戶(hù)預(yù)告設(shè)定好的配置策略自動(dòng)完成格式轉(zhuǎn)換。

3. 未能實(shí)現(xiàn)代碼模塊化

在編寫(xiě)函數(shù)時(shí)，務(wù)必要保證其能且只能實(shí)現(xiàn)單一一種效果——這也是一項(xiàng)值得認(rèn)真遵循的良好編碼實(shí)踐。這種處理方式能夠讓代碼保持簡(jiǎn)潔，并因此更易于理解與維護(hù)。過(guò)長(zhǎng)的函數(shù)可能擁有多種可能的接入路徑，進(jìn)而使其更難于進(jìn)行測(cè)試。

這里我教大家個(gè)好辦法：一條函數(shù)最多不要超過(guò)單屏幕的內(nèi)容顯示極限。另外，如果代碼當(dāng)中包含十個(gè)甚至更多“if”語(yǔ)句或者循環(huán)，也就說(shuō)明其邏輯關(guān)系太過(guò)復(fù)雜、應(yīng)該立刻打回重寫(xiě)。

4.保持警惕：IDE功能帶來(lái)的安全感也許并不真實(shí)

IDE以及其它能夠自動(dòng)調(diào)整代碼的工具能夠奇跡般地提升生產(chǎn)效率。這類(lèi)工具會(huì)根據(jù)大家已經(jīng)輸入的內(nèi)容給出建議變量以及其它提示內(nèi)容。不過(guò)這類(lèi)工具在實(shí)際使用時(shí)也有可能帶來(lái)潛在問(wèn)題——由于可以毫不費(fèi)力地從看似正確無(wú)誤的選項(xiàng)里選出自己需要的內(nèi)容，大家往往會(huì)因此而放下戒心。不要這樣，請(qǐng)反復(fù)確認(rèn)以保證我們選擇的內(nèi)容與自己需要的內(nèi)容完全一致。從本質(zhì)上講，這類(lèi)功能相當(dāng)于把思考工作轉(zhuǎn)嫁到了工具身上，因此確保其思路正確當(dāng)然非常重要。

這相當(dāng)于給我們提供了一種新的思考基準(zhǔn)。代碼補(bǔ)全工具可以消除當(dāng)中的拼寫(xiě)等錯(cuò)誤并提高生產(chǎn)力，但它們同時(shí)也很可能在我們放松警惕時(shí)悄悄把錯(cuò)誤埋入其中。

5. 硬編碼密碼

以硬編碼方式創(chuàng)建秘密賬戶(hù)與密碼具有相當(dāng)突出的吸引力，大家可以借此在隨后的使用過(guò)程中直接進(jìn)入系統(tǒng)。我相信大家都知道這種作法不正確也不科學(xué)——沒(méi)錯(cuò)，這種方式確實(shí)非常方便，但同時(shí)也相當(dāng)于給任何打算窺探源代碼的家伙提供了可趁之機(jī)。

真正的問(wèn)題在于，硬編碼密碼最終總會(huì)被散布到我們預(yù)期之外的人群當(dāng)中。這就使其成為一種巨大的安全威脅，而且很難得到徹底修復(fù)。

6.沒(méi)有利用良好的加密機(jī)制進(jìn)行數(shù)據(jù)保護(hù)

敏感數(shù)據(jù)必須在網(wǎng)絡(luò)傳輸?shù)倪^(guò)程中受到加密，這是因?yàn)槠浜芸赡茉趥鬟f期間遭遇惡意人士的攔截。這并不僅僅是什么最佳沖或者推薦方案，這是一種管理要求——甚至可以上升到法律強(qiáng)制的高度。

也就是說(shuō)，直接發(fā)送數(shù)據(jù)明文的作法必須被“嚴(yán)格禁止”。此外，大家也最好不要使用自己編寫(xiě)的加密或者模糊處理方案。編寫(xiě)自己的安全加密系統(tǒng)難度很高——看過(guò)WEP的遭遇相信各位就會(huì)明白——因此請(qǐng)務(wù)必選擇符合相關(guān)行業(yè)標(biāo)準(zhǔn)的加密庫(kù)并正確使用。

7. 過(guò)早對(duì)代碼進(jìn)行優(yōu)化

傳奇編程大師Donald Knuth曾經(jīng)說(shuō)過(guò)，“程序員們把大量時(shí)間浪費(fèi)在了考慮或者擔(dān)心程序中非關(guān)鍵性部件的執(zhí)行速度身上，但這類(lèi)處理措施往往會(huì)給代碼的調(diào)試與維護(hù)工作帶來(lái)嚴(yán)重的負(fù)面影響?！?/p>

在我們的代碼上多花心思可能確實(shí)會(huì)使其執(zhí)行速度不斷提升，但同時(shí)也會(huì)給調(diào)試與維護(hù)帶來(lái)更高難度。最好的辦法是：以簡(jiǎn)潔明確的方式編寫(xiě)代碼，然后在真正有必要的時(shí)候通過(guò)優(yōu)化提升其性能表現(xiàn)。

8. 缺乏超前思維能力

我們的項(xiàng)目到底會(huì)起到什么樣的作用、預(yù)計(jì)將會(huì)擴(kuò)展到怎樣的程度、有多少用戶(hù)會(huì)對(duì)其進(jìn)行操作、又將以怎樣的速度加以運(yùn)行？這些問(wèn)題的答案在開(kāi)發(fā)過(guò)程中往往并不明確——但如果大家不能提前作好規(guī)劃，則肯定無(wú)法準(zhǔn)確選擇合適的框架并開(kāi)發(fā)出能夠滿足這些需求的應(yīng)用程序。

Twitter公司的技術(shù)團(tuán)隊(duì)就遇到過(guò)這樣的實(shí)際情況：如果對(duì)未來(lái)實(shí)際使用強(qiáng)度估計(jì)不足，想要后期補(bǔ)救將極為困難。Twitter不得不徹底放棄Ruby on Rails并利用Scale與其它技術(shù)方案對(duì)代碼進(jìn)行重新編寫(xiě)，這是因?yàn)樵鹊腞uby代碼在初始設(shè)計(jì)上完全沒(méi)有考慮到Twitter會(huì)擁有如此迅猛的用戶(hù)群體增長(zhǎng)速度。

9.增加開(kāi)發(fā)者數(shù)量以提高開(kāi)發(fā)進(jìn)度

幾乎沒(méi)有幾個(gè)軟件項(xiàng)目都?jí)蛘嬲凑疹A(yù)定時(shí)間完成進(jìn)度。增加開(kāi)發(fā)者數(shù)量來(lái)提高開(kāi)發(fā)進(jìn)度乍聽(tīng)起來(lái)似乎是個(gè)不錯(cuò)的主意，但這僅僅是種理論而非現(xiàn)實(shí)、有時(shí)候甚至屬于嚴(yán)重失誤。在現(xiàn)實(shí)情況下，向項(xiàng)目中添加新人往往總要拉低團(tuán)隊(duì)的整體生產(chǎn)效率。

10.明知時(shí)間規(guī)劃無(wú)法實(shí)現(xiàn)卻仍勉力苦撐

與此同時(shí)，我們還應(yīng)該保持清醒的頭腦、意識(shí)到在團(tuán)隊(duì)規(guī)模不變的前提下進(jìn)度滯后的情況根本無(wú)法扭轉(zhuǎn)——這樣的理性思維能力非常重要。如果大家沒(méi)能完成原有時(shí)間表，那很可能是因?yàn)檫@份進(jìn)度規(guī)劃在制定時(shí)存在著失誤。換句話來(lái)說(shuō)，大家需要出臺(tái)一份新的項(xiàng)目時(shí)間表而非盲目堅(jiān)持原先這份已經(jīng)被現(xiàn)實(shí)證明為不可能的錯(cuò)誤方案。

英文：http://www./article/2393057/developer/10-bad-coding-practices-that-wreck-software-development-projects.html

【編輯推薦】