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