軟體開發的七條原則

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

原則#1：存在的原因

軟體系統存在的原因：為使用者提供價值。所有的決定都應該考慮到這一點。在指定系統需求之前，在關注系統的各個功能之前，在確定硬體平臺或開發過程之前，問問自己以下問題：這是否能為系統真正增加價值？如果答案是否定的，那就不要去做。所有其他原則都以這一條為先。

原則#2：KISS

軟體設計不是一個偶然的過程。任何設計工作都需要考慮許多因素。所有的設計應該儘可能簡單，但不要過於簡化。

複雜性是你的敵人。任何傻瓜都能讓事情變得複雜。反之則很難。
——Richard Branson

這有利於擁有更易於理解和易於維護的系統。但並不是說應該以簡單的名義拋棄功能，甚至是內部功能。當然，通常而言，更優雅往往意味著更簡單。

簡單是終極的複雜。
——Leonardo Da Vinci

簡單也並不意味著快速和骯髒。事實上，為了簡化，我們經常需要大量思考和多次迭代工作。收穫是更易於維護且不易出錯的軟體。

這一直是我的一個座右銘——集中和簡單。簡單或許會比複雜更難；你必須花很多力氣使自己的思維變得簡單、有條理。
——Steve Jobs

原則#3：維護願景

明晰的願景對於軟體專案的成功至關重要。否則，專案最終基本上都將陷入左右搖擺的境地。沒有概念的完整性，系統就很有可能成為不相容設計的拼湊物——被錯誤的螺絲釘連線在一起。

概念完整性是系統設計中要考慮的最重要因素。
——Fred Brooks

建立一個乾淨的內部結構對構建一個易於理解、可擴充套件和重組、並且可維護和可測試的系統而言至關重要。
——Stroustrup

只有清晰認識系統架構，才有可能發現常見的抽象和機制。利用這種通用性最終將使得系統更簡單，因此也會更輕巧、更可靠。
- Grady Booch

妥協軟體系統的架構願景會削弱並將最終破壞系統，甚至是設計得盡善盡美的系統。擁有一個能夠實現願景和執行合規性的授權架構師有助於確保軟體專案的成功。

原則#4：生產其他人消費的東西

很少有工業級的軟體系統是在真空中構建和使用的。其他人將以某種方式，或者其他依賴於能夠理解系統的方式使用、維護、記錄。因此，始終指定、設計，以及實現瞭解他人將有助於瞭解你在做什麼。任何軟體開發產品的受眾都可能很大。

指定使用者。設計，牢記實施者。關注那些必須維護和擴充套件系統的程式碼。有的人可能需要除錯你編寫的程式碼，這使得他們成為你的程式碼使用者。方便他們工作可以為你的系統增添價值。

原則#5：面向未來

壽命較長的系統具有更大的價值。在今天的計算環境中，當規格在剎那間發生變化並且硬體平臺過幾個月就變得過時時，軟體壽命常常用月來衡量而不是用年。然而，真正的工業級軟體系統必須能堅持更長時間。要做到這一點，系統必須能夠適應這些改變。可以成功實現這些目標的系統都是從一開始就以這種方式而設計的。切勿在設計時自找麻煩。總是問“假使這樣，那會怎麼樣”，並通過建立解決一般問題，而非僅僅是具體問題的系統來準備好所有可能的答案。這很可能促使整個系統的重用。

濫用這個原則是我看到很多開發者出錯的地方。擁有多年的經驗和其中許多人致力於單個專案的好處之一是你可以瞭解YouArentGonnaNeedIt的優點。作為開發者，除非我們也是該領域專家，否則我們經常會猜錯系統將如何改變。

系統確實發生了變化，但通常會殊途同歸，因而廣義的解決方案就變成了包袱。
——Sal Mangano

原則#6：預先規劃重用

重用可節省時間和精力。實現高水平的重用可以說是開發軟體系統最難的目標。程式碼和設計的重用已被宣稱為使用物件導向技術的主要優勢。但是，這項投資的回報並不是自動的。為了利用物件導向程式設計提供的重用可能性，我們需要預先考慮和規劃。在系統開發過程的每個級別都有很多技術可以用來實現重用。詳細設計和程式碼級別的重用技術不但眾所周知而且是有文件的。

新的文獻正在以軟體模式的形式尋覓設計的重用。然而，這只是戰鬥的一部分。與組織中的其他人交流重用的機會至關重要。如何重用你不知道的東西？提前規劃重用可降低成本並提高可重用元件及其所在系統的價值。

原則#7：三思而後行！

這最後一條原則可能是最容易被忽視的。在行動之前形成一條清晰和完整的思路幾乎總能夠產出更好的結果。只有你考慮到了某個問題，你才更有可能解決它。你還可以從中獲得有關如何再次正確做這件事的知識。

如果你確實考慮到了某件事情，但仍然做錯了，那麼這就是你寶貴的經驗。思考還有一個成果是可以學習到當你不知道某個東西，此時該如何研究答案的過程。

明確的思想進入到系統，就會產出價值。應用前六個原則需要深入的思考，當然潛在的回報也是不可估量。