軟體開發的10個錯誤實踐

　　帕雷託法則說80%的成果取決於20%的原因。這也被稱為28原則，人類幾乎每一個領域的嘗試都和它有關。

　　在軟體開發領域，這個原則可以總結為大多數問題都是由少數的糟糕的編碼實踐導致的。消除這些問題，你的工作會變得更輕鬆，效率也會得到提升 .

　　程式碼拼寫錯誤

　　令人驚訝的是，這是最常見的，由於它和你的編碼水平高低沒有關係，因此很讓人抓狂。變數名或者函式名的一個拼寫錯誤就會給你的程式碼造成嚴重的破壞。更嚴重的是，它們通常不易察覺。

　　那怎麼解決？在一個好的IDE或者程式設計師專用的文字編輯中工作可以顯著地減少拼寫錯誤的問題。還可以做的一件事情是：儘量選擇容易拼寫的變數或函式名，這樣當寫錯的時候就很容易能發現了。避免使用類似receive這樣的單詞，因為它很容易寫成recieve。

　　程式碼沒有縮排或者格式化

　　將程式碼進行縮排或者別的格式化可以使得它易於理解，因此也方便定位錯誤。同時由於程式碼的風格一致，其它人維護你的程式碼會變得更簡單。

　　如果你用的IDE沒有自動進行程式碼縮排，可以考慮使用一個類似Uncrustify這樣的程式碼美化器，它能根據你配置的規則進行格式化。

　　程式碼沒有模組化

　　一個好的編碼實踐就是實現的函式做且只做一件事情。這使得函式更短因此也更易於閱讀及維護。長函式會有許多可能的路徑，這使得它們很難進行測試。

　　一條好的經驗是：一個函式應該佔用不超過一螢幕的空間。還有一點是，如果它有超過10個if語句或者迴圈語句，那就說明它太複雜了，應該得重寫。

　　你的IDE讓你誤以為很安全

　　IDE以及其它提供程式碼補全的工具對於提高效率非常有效。它們會根據作用域以及你的輸入來建議變數名或者其它東西。不過這種型別的工具有一個危險——你會因為某個選項看起來像是你所要的而選擇了它，卻沒有確保這的確是你所想要的東西。事實上，工具只是替你去思考了，但你得自己去確保這個東西是正確的。

　　將密碼硬編碼

　　你可能會硬編碼一個安全帳號及密碼，這樣後面你可以登入到系統裡。你也知道不應該這麼做——是的，這的確很方便，但對於能訪問到原始碼的人來說也同樣很方便。

　　真正的問題在於硬編碼的密碼最終會被比你預料中更多的人所獲取到。這是一個非常巨大的安全隱患，更別提修復起來有多麻煩了。

　　沒有使用正確的加密手段來保護資料

　　敏感資料需要在網路傳輸的過程中進行加密，只有這麼做才不容易被截獲。這不是什麼好的點子，而是管制要求，儘管它還算不上是規章制度。

　　這意味著你堅決不能直接傳送資料。同時也不要自己去加密或者混淆。自己寫安全加密系統非常困難——看一下WEP發生了什麼就明白了，因此最好用一個業界證明過的標準加密庫，並正確地使用它。

　　過早地進行程式碼的優化

　　傳奇程式設計師Donald Knuth曾經說過，“程式設計師浪費了大量的時間在考慮或者擔心他們程式的非關鍵部位的執行效率，而這些努力對後續除錯和維護的效率起到了很大的負面作用。”

　　在程式碼上費盡心思卻只能讓它執行得稍微快一點而已，但卻使得它更難除錯及維護了。更好的一個策略是：清晰地寫好你的程式碼，然後如果有什麼地方的確需要優化的時候才去提升它的效能。

　　沒有提前規劃

　　你的專案是做什麼的，它需要擴充套件到多大的規模，有多少使用者會使用它，它的執行速度需要有多快？這些問題可能並沒有答案——不過如果你沒有提前預估的話，那你如何能選擇出一個合適的應用開發的框架，能讓你的程式滿足這些要求？

　　如果你低估了未來的需求會遭遇什麼問題，這個事情上Twitter是一個很好的案例。Twitter放棄了Ruby On Rails並用Scala及其它技術重寫了大部分的程式碼，這是由於最初架構所使用的Ruby程式碼，它的擴充套件能力無法跟上Twitter快速增長的使用者基數。

　　增長人手來追趕工期

　　許多軟體專案都趕不上進度。增派人手到專案中來讓進度趕上正軌聽起來是個不錯的主意，但這是錯誤的。事實上，增加新人到專案中來通常都會延誤整個的開發進度。

　　時間評估錯誤卻仍然繼續

　　同時很重要的是，不要想像不需要給專案加人也能趕上原先的進度。如果你已經落後於時間表了，這是由於你預估的時間是錯誤的。這也意味著你得重新評估下整個專案的週期，而不是盲目地堅持已經被證明是錯誤的評估時間。

　　原文：javaworld.com　翻譯：deepinmind.com