在從事軟體開發若干年之後，我已經對“軟體應該如何設計”有些心得。實際上，我有了這樣一個結論：所有的事情最後都濃縮成10個原則，如果我們很好地執行這些原則，任何軟體開發都應該會取得成功。
0. 客戶至上
“如果我們沒有關注客戶……其他人將會取代我們。”
從客戶的角度出發，客戶首先會把焦點集中在產品開發的真正價值，其他方面（例如概念、需求、技術等等)在專案中是次要的。
不關注客戶，就是程式設計師常犯的5個非技術性錯誤的其中之一。
1. 程式碼質量
即使程式碼質量是一些非常主觀性的東西，（甚至有人說所有的程式碼都有問題），它卻影響著很多重要的方面，比如：如何去維護應用程式，或者如何去帶一個新手程式設計師。
在我看來，程式碼質量的指標在於：簡單性、可讀性、健壯性和可測試性。其他特性，例如外觀或者可擴充套件性，如果沒有要求的話，在你的應用程式中可以靈活設計。
2. 授權
軟體開發過程中最重要的資源是人力，而非技術。人力決定產品的好壞，但他們需要得到授權。
授權是一個鼓勵開發者積極做事和制定決策的過程。一些高效的機構的授權體現為：指導配合或者委派。 不知你是否也有過和Derek相同的經歷，每隔5分鐘就有員工跑過來向他請示這個和那個問題？如果有，可以通過《管理者的困境：放權或者崩潰》這篇文章看看Derek如何解決這個問題的。
3. 持續整合
從我的經驗看來，整合是軟體開發的主要問題。在專案後期或者大型功能模組完成後，等著整合是一個令人糾結的過程。
持續的整合是保證每部分委託的程式碼在系統中自動整合的過程。請記住，持續整合優先於持續編譯。
Martin Fowler的這篇文章是網上關於持續整合的最優秀的參考文獻之一。
4. 迭代
迭代提供了持續的反饋資訊。持續反饋很重要，因為它降低了軟體開發的不穩定性。
雖然迭代經常與敏捷方法有關係，不過有其他方法例如RUP，也使用迭代，他們卻不是敏捷方法家族中的一員，記住這一點很重要。
5. 自動化測試
允許重構和遞迴，給開發者帶來自信，如果得到有效貫徹的話，會提高最終產品的正確性。對於自動化測試，你可以考慮與測試有關的一些情況和如何編寫一個良好測試元件的建議。
6. 重構
不管你如何關注編碼，在你邁出第一步的時候，你將會走錯路。重構是我們用來保持程式碼修改的做法，以滿足系統說明的必要更迭。
7. 非正式架構
前期的大型設計，除非你是NASA，能夠把專案50-60%的時間花在這上面，否則這完全是浪費，毫無準備去編碼情形也一樣。非正式架構是一種折衷解決方案，它在專案發展的基礎上進行討論，並存留於檔案，留言板或者類似的物件之中。
8. 溝通
軟體開發只與溝通有關。客戶向軟體開發團隊闡述他想要達到的目標，以便於軟體開發團隊能通過編碼形式向計算機解釋。
9. 避免浪費
浪費是軟體開發過程的主要生產力殺手之一。毫無必要的會議、毫無必要的要求、毫無必要的過程和毫無必要的檔案成為最常見和最危險的浪費。
原文：Alberto Gutierrez 翻譯：伯樂線上 – 李盛暉
【如需轉載，請標註並保留原文連結、譯文連結和譯者等資訊，謝謝合作！】