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