建站
咨詢
售后
建站咨詢
新聞中心
創(chuàng)新互聯(lián)服務(wù)項目包括應(yīng)城網(wǎng)站建設(shè)、應(yīng)城網(wǎng)站制作、應(yīng)城網(wǎng)頁制作以及應(yīng)城網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，應(yīng)城網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到應(yīng)城省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
【譯文】告別這些常見但卻糟糕的編碼實踐方式能夠讓我們的工作更為輕松——而開發(fā)出的軟件也將更安全且更具可擴展性。
根據(jù)“帕累托原則”的說法，特定事件最終結(jié)果當(dāng)中的八成往往由由占二成的隨機性因素所決定。這種劃分方式被稱為二八開原則，而且?guī)缀跤绊懙搅巳祟惿a(chǎn)生活當(dāng)中的每一個領(lǐng)域。
在軟件開發(fā)領(lǐng)域，該原則也可以這樣進(jìn)行解讀：大部分問題實際都是由一小部分不良編碼實踐所引發(fā)。只要消除這部分因素，我們的工作就能變得更輕松也更加富有成效。
在今天的文章中，我們將一同了解十大給軟件開發(fā)工作帶來無窮困擾的糟糕編碼實踐活動。
1. 代碼當(dāng)中的拼寫錯誤
這類問題的出現(xiàn)頻率可能遠(yuǎn)遠(yuǎn)超出大家的想象。這樣的問題之所以如此普遍而又難以扼制，主要是因為引發(fā)問題的根源與我們的編程技術(shù)水平并沒有必然聯(lián)系。再出色的開發(fā)人員也有可能在代碼中不慎寫出錯誤的變量名或者函數(shù)名，而這最終將成為一股肆虐無忌而又***破壞性的力量。更重要的是，準(zhǔn)確找出它們實在不是件容易的事。
那我們該如何解決這一難題呢？選擇一套良好的集成開發(fā)環(huán)境（簡稱IDE）或者是專門面向程序員的文本編輯器，這樣能夠顯著降低拼寫錯誤出現(xiàn)的可能性。除此之外，我們可以選擇另一種解決途徑：有意選擇拼寫難度不高的變量與函數(shù)名稱，這樣一來即使出現(xiàn)錯誤、發(fā)現(xiàn)難度也不會太高。***不要使用receive這類詞匯，因為不管檢查多少次、我們都不太可能發(fā)現(xiàn)它被錯寫成了recieve。
2.代碼內(nèi)容欠缺必要的縮進(jìn)或者格式調(diào)整
請大家一定記得為代碼行設(shè)定縮進(jìn)或者作出格式調(diào)整，否則最終一定會發(fā)現(xiàn)自己的代碼內(nèi)容既難于閱讀又不容易從中找出錯誤。此外，簡潔清晰的格式規(guī)劃還能提供更為統(tǒng)一的顯示效果，進(jìn)而降低繼任者對代碼的維護(hù)難度。
如果大家使用的IDE不提供代碼格式自動調(diào)整功能，我們可以考慮使用Uncrustify等代碼美化工具，這類軟件能夠根據(jù)用戶預(yù)告設(shè)定好的配置策略自動完成格式轉(zhuǎn)換。
3. 未能實現(xiàn)代碼模塊化
在編寫函數(shù)時，務(wù)必要保證其能且只能實現(xiàn)單一一種效果——這也是一項值得認(rèn)真遵循的良好編碼實踐。這種處理方式能夠讓代碼保持簡潔，并因此更易于理解與維護(hù)。過長的函數(shù)可能擁有多種可能的接入路徑，進(jìn)而使其更難于進(jìn)行測試。
這里我教大家個好辦法：一條函數(shù)最多不要超過單屏幕的內(nèi)容顯示極限。另外，如果代碼當(dāng)中包含十個甚至更多“if”語句或者循環(huán)，也就說明其邏輯關(guān)系太過復(fù)雜、應(yīng)該立刻打回重寫。
4.保持警惕：IDE功能帶來的安全感也許并不真實
IDE以及其它能夠自動調(diào)整代碼的工具能夠奇跡般地提升生產(chǎn)效率。這類工具會根據(jù)大家已經(jīng)輸入的內(nèi)容給出建議變量以及其它提示內(nèi)容。不過這類工具在實際使用時也有可能帶來潛在問題——由于可以毫不費力地從看似正確無誤的選項里選出自己需要的內(nèi)容，大家往往會因此而放下戒心。不要這樣，請反復(fù)確認(rèn)以保證我們選擇的內(nèi)容與自己需要的內(nèi)容完全一致。從本質(zhì)上講，這類功能相當(dāng)于把思考工作轉(zhuǎn)嫁到了工具身上，因此確保其思路正確當(dāng)然非常重要。
這相當(dāng)于給我們提供了一種新的思考基準(zhǔn)。代碼補全工具可以消除當(dāng)中的拼寫等錯誤并提高生產(chǎn)力，但它們同時也很可能在我們放松警惕時悄悄把錯誤埋入其中。
5. 硬編碼密碼
以硬編碼方式創(chuàng)建秘密賬戶與密碼具有相當(dāng)突出的吸引力，大家可以借此在隨后的使用過程中直接進(jìn)入系統(tǒng)。我相信大家都知道這種作法不正確也不科學(xué)——沒錯，這種方式確實非常方便，但同時也相當(dāng)于給任何打算窺探源代碼的家伙提供了可趁之機。
真正的問題在于，硬編碼密碼最終總會被散布到我們預(yù)期之外的人群當(dāng)中。這就使其成為一種巨大的安全威脅，而且很難得到徹底修復(fù)。
6.沒有利用良好的加密機制進(jìn)行數(shù)據(jù)保護(hù)
敏感數(shù)據(jù)必須在網(wǎng)絡(luò)傳輸?shù)倪^程中受到加密，這是因為其很可能在傳遞期間遭遇惡意人士的攔截。這并不僅僅是什么***沖或者推薦方案，這是一種管理要求——甚至可以上升到法律強制的高度。
也就是說，直接發(fā)送數(shù)據(jù)明文的作法必須被“嚴(yán)格禁止”。此外，大家也***不要使用自己編寫的加密或者模糊處理方案。編寫自己的安全加密系統(tǒng)難度很高——看過WEP的遭遇相信各位就會明白——因此請務(wù)必選擇符合相關(guān)行業(yè)標(biāo)準(zhǔn)的加密庫并正確使用。
7. 過早對代碼進(jìn)行優(yōu)化
傳奇編程大師Donald Knuth曾經(jīng)說過，“程序員們把大量時間浪費在了考慮或者擔(dān)心程序中非關(guān)鍵性部件的執(zhí)行速度身上，但這類處理措施往往會給代碼的調(diào)試與維護(hù)工作帶來嚴(yán)重的負(fù)面影響?！?/p>
在我們的代碼上多花心思可能確實會使其執(zhí)行速度不斷提升，但同時也會給調(diào)試與維護(hù)帶來更高難度。***的辦法是：以簡潔明確的方式編寫代碼，然后在真正有必要的時候通過優(yōu)化提升其性能表現(xiàn)。
8. 缺乏超前思維能力
我們的項目到底會起到什么樣的作用、預(yù)計將會擴展到怎樣的程度、有多少用戶會對其進(jìn)行操作、又將以怎樣的速度加以運行？這些問題的答案在開發(fā)過程中往往并不明確——但如果大家不能提前作好規(guī)劃，則肯定無法準(zhǔn)確選擇合適的框架并開發(fā)出能夠滿足這些需求的應(yīng)用程序。
Twitter公司的技術(shù)團(tuán)隊就遇到過這樣的實際情況：如果對未來實際使用強度估計不足，想要后期補救將極為困難。Twitter不得不徹底放棄Ruby on Rails并利用Scale與其它技術(shù)方案對代碼進(jìn)行重新編寫，這是因為原先的Ruby代碼在初始設(shè)計上完全沒有考慮到Twitter會擁有如此迅猛的用戶群體增長速度。
9.增加開發(fā)者數(shù)量以提高開發(fā)進(jìn)度
幾乎沒有幾個軟件項目都夠真正按照預(yù)定時間完成進(jìn)度。增加開發(fā)者數(shù)量來提高開發(fā)進(jìn)度乍聽起來似乎是個不錯的主意，但這僅僅是種理論而非現(xiàn)實、有時候甚至屬于嚴(yán)重失誤。在現(xiàn)實情況下，向項目中添加新人往往總要拉低團(tuán)隊的整體生產(chǎn)效率。
10.明知時間規(guī)劃無法實現(xiàn)卻仍勉力苦撐
與此同時，我們還應(yīng)該保持清醒的頭腦、意識到在團(tuán)隊規(guī)模不變的前提下進(jìn)度滯后的情況根本無法扭轉(zhuǎn)——這樣的理性思維能力非常重要。如果大家沒能完成原有時間表，那很可能是因為這份進(jìn)度規(guī)劃在制定時存在著失誤。換句話來說，大家需要出臺一份新的項目時間表而非盲目堅持原先這份已經(jīng)被現(xiàn)實證明為不可能的錯誤方案。
英文：http://www.javaworld.com/article/2393057/developer/10-bad-coding-practices-that-wreck-software-development-projects.html
分享名稱：足以搞砸軟件開發(fā)項目的十大糟糕編碼實踐
轉(zhuǎn)載來源：http://m.5511xx.com/article/cccjhdp.html
