帕雷託法則明確指出，20％的因導致80％的果。又稱為80-20法則，它適用於幾乎每乙個需要人作為勞動主體的相關領域。
在軟體開發領域，這個法則可以概括為，大多數的問題都是由少數不良編碼習慣造成的。改變這些習慣，你會更有效率。
下面講講最要不得的編碼習慣：
讓我特別訝異的是，為什麼大家明知這個習慣百害而無一利，竟然還是任其在**中肆虐橫行，以致於經常出現拼寫錯誤的變數名和函式名。更加悲劇的是，錯誤的拼寫常常隱蔽得很好，很難發現。至於解決方法，可以在乙個良好的整合開發環境（ide）上寫**，或者乾脆用程式設計師專用的文字編輯器，這些都可以顯著減少拼寫錯誤。還可以選擇特定的變數名和函式名，一方面容易拼寫，另一方面即便寫錯了也能輕易發現。盡量避免使用很容易拼錯的單詞，例如「receive」，很容易拼寫成「recieve」。總的來說，還是要細心。
縮排和格式化，能讓我們的**一目了然、易於理解，有什麼錯誤也能一覽無餘。而且也方便別人理解和維護。 **不規範或者不加注釋從某種程度上可以說是 沒有職業道德的，你的**是給別人看的，亂七八糟的**格式肯定會被別人罵。
乙個函式對應乙個指令的習慣相當好，因為簡短所以易於理解和維護。長函式實現的可能路徑太多，所以測試起來就特別麻煩。第乙個規範原則：乙個函式最多只能佔一顯示屏的空間。第二個：如果有10個以上的if語句或者迴圈語句，那麼你就可以考慮重寫了。
毫無疑問，ide和其他一些工具能讓你的**寫得又快又好。在一定範圍內它們能提供變數和其他很多東西，給出你想要輸入內容的多種選擇提示。但是這種型別的工具也存在著風險——如果你不能保證自己有火眼金睛，那麼很容易誤選相似的變數名。從本質上說，這類工具替代了人的一部分思維，但實際上這是你自己的責任。工具的確是我們的好幫手，例如可以消除拼寫錯誤，以及提高工作效率等，但是如果你自己不仔細的話，同樣會有寫錯**的問題出現。
很多人傾向於硬編碼乙個秘密帳戶和密碼，這樣之後就可以自由進入系統。但是這是不對的——沒錯，這於你而言的確是大大的方便了，但同時這也大大方便了別人去訪問你的源**。究其原因在於，硬編碼的**比你想象的還要脆弱，這就使得它成為了乙個巨大的安全隱患，而且還是乙個很不好修復的安全隱患。
敏感資料在網際網路上傳輸時是需要加密的，因為在這個過程中它很有可能被攔截。不要抱怨麻煩，這是最基本的安全要求。這也意味著以明文形式傳送資料是不被認可的，同時也排除了我們使用自己的加密方式和混淆目標的措施。寫安全加密系統是很難的——看看wep的情況就知道了——所以我們不妨使用經過驗證的標準加密庫。
10個對開發專案有害的程式設計習慣
1.拼寫錯誤 讓我特別訝異的是，為什麼大家明知這個習慣百害而無一利，竟然還是任其在 中肆虐橫行，以致於經常出現拼寫錯誤的變數名和函式名。更加悲劇的是，錯誤的拼寫常常隱蔽得很好，很難發現。至於解決方法，可以在乙個良好的整合開發環境 ide 上寫 或者乾脆用程式設計師專用的文字編輯器，這些都可以顯著減少...
10個對開發專案有害的程式設計習慣
避免這些常見的編碼習慣，會讓我們的工作更輕鬆 軟體更安全且更易於擴充套件。帕雷託法則明確指出，20 的因導致80 的果。又稱為80 20法則，它適用於幾乎每乙個需要人作為勞動主體的相關領域。在軟體開發領域，這個法則可以概括為，大多數的問題都是由少數不良編碼習慣造成的。改變這些習慣，你會更有效率。10...
常人對開發的誤解
步入職場，對比剛畢業時的那段創業時間，覺得自己有一些做的不對的地方，或者整個創業團隊導致失敗的地方。失敗原因很多，天時 地利 人和都有因素，這次只想說說關於大家對開發的誤解，這也是失敗的原因之一。最終的結果就是，走的時候發現自己好像沒有做什麼東西。高估了開發的力量，低估了產品的生命週期，不是奔著產品...