本文翻譯自： "Why Software Architecture Matters" (https://www.imaginarycloud.com/blog/why software architecture matters/) 拋開某項特定的技術或某個特定的項目不說，這篇文章我想講講關於犯錯這個 ...
本文翻譯自：Why Software Architecture Matters
(https://www.imaginarycloud.com/blog/why-software-architecture-matters/)
拋開某項特定的技術或某個特定的項目不說，這篇文章我想講講關於犯錯這個話題。
談論和贊揚成功也許很輕鬆，但是我發現犯錯仍是個很有意思的話題。主要是因為它們在學習的過程中頗有用處。
一開始我將講一些背景知識，然後闡述一下我對軟體架構的看法。 後者是我認為在軟體開發過程中最重要的一部分，並且談下如何避免陷入常見的開發陷阱。
預熱階段
當任何一個程式員被問到：
“哪種方式你更為熱衷：從零開始一個項目，或者維護一個已存在的項目?”
他們通常回答：
“從零開始一個項目”
答案是顯而易見的，因為成就感給人帶來的感覺更棒。我們可以這樣說：“這是我做的（至少是其中相當的一部分內容）。之前並不存在，而現在，看！就在眼前。”
但其中的意義往往不止於此。人類的大腦是喜歡有秩序的，它喜歡從一些混亂和看似隨機的信息中尋找規律（模式），在軟體開發中，這點也一樣。
但是在一個已存在的項目中會發生什麼？很可能這個項目已經摻雜一定程度的混亂，並且它的混亂程度顯然比一個不存在的項目嚴重多了。
因此，最直接的回應（做法）是從頭開始一個項目，這樣的話你就可以完全通過你的經驗來把控它的混亂度。
當然，在軟體的烏托邦，我們永遠不會因為疏忽大意而（給項目）造成混亂的局面。遺憾的是，我們並不是生活在那個世界，但是我們可以用工具和原則來指導我們。
優秀的架構省時省力
我們所擁有的用來處理回歸複原、修複BUG等令人厭惡的任務的最好方式就是提前做規劃。一個優秀的架構是我們的朋友。
一個優秀的設計解決方案頂得上數千個小時的時間，畢竟在未來它真的幫我們省掉了很多時間。
我們大多數都看過一些書，我們知道要做什麼。我們同樣應該認真地進行（軟體）測試和應用設計模式。“讓我們真正專註並貫徹於MVC（譯註：一種將業務邏輯、數據和界面顯示分離的軟體設計模式）；讓我們為此採用BDD模式（譯註：行為驅動開發，敏捷開發技術的一種）；讓我們在寫生產代碼前先設計特性測試。”
有時候，我們忘記了第一步該做什麼的重要性，甚至在那之前。
架構
當然，在你寫功能性代碼前，是的，請寫下你的第一個測試案例。
但在你寫下第一個測試案例之前，設計團隊有可能已經收集了所有的需求，已經與客戶和其他利益相關方達成了協議，他們甚至可能已經出來了多個版本的產品設計方案併進行了多加驗證，所以你可能會認為你應該立即進行代碼的編寫。
你應該做的
整個團隊應該坐下來討論關於他們將要開發的產品。他們應該拿出一張紙或者到白板面前，然後開始列舉未來產品將要有的特性。
清晰地確定出所有的技術要求和提議方案的可行性。考慮在實施不同的實現方案中每一步所面臨的挑戰併為此想出解決措施，可能是（採用）不同的框架，甚至是不同的編程語言。
兜底地說，（在軟體開發中）沒有其他事情能值得你花的時間與花在架構一樣多。
從錯誤中學習
對於我來說，最好的學習方式之一就是犯錯。
儘管犯錯會讓人感到困窘和沮喪，但當我們真犯了錯，我們就會投入精力去弄明白究竟發生了什麼，會努力地尋找解決方案，找到不再犯同樣錯誤的最好辦法。
這就等同於經驗。
經驗就是錯誤的別稱。
—— 奧斯卡·王爾德
最近我在做一個非常複雜的IOS項目。在項目剛開始的時候，有幾件事情是沒做好的。需求並沒有百分百確定，先決條件並沒有百分之百滿足，APIs（應用程式介面）還沒準備好……
但最重要的可能是：我們沒有像我們應該做的那樣定義出項目的架構。
當然，我是在出現損失時才意識到這點的。我們（當時）做了大量的還原、改寫的工作，有幾次我一直追問自己說：“為什麼我沒有採用正確的方式？”
一個陷阱是：沒有使用測試框架。歸根到底，測試和驗證是通過用戶測試和代碼檢視來完成的。然後當一個測試框架真正地被引進項目時，這已經太晚了。
一個熱門的被眾人所認可的IOS開發框架並不是都能適用於所有的複雜情況的，也並不一定適用於各種開發語言和彌補在設計產品架構時（從技術的角度來看）所作出的糟糕決策。
更好的方法：一些經驗法則
敲黑板。你接到一個新項目，可能你在需求收集階段就已經開始參與了。拋開腦海中已有的針對這項目的整體技術解決方案的想法，我會建議：
寫下所有的東西。製作圖表，畫組件圖、類圖、流程圖，寫下所有你覺得有助於你和團隊快速瞭解問題全貌的東西。
平時常拿出來進行反覆思考，在寫下第一行代碼前可能會對其做多次的更改修正。
當所有的組件/模塊已經定義好了，嘗試為其找一些現有的可靠的解決方案。開源框架是一個很好的方向，因為它們已經被很多人測試過和使用過，因此也會比你自己實現的方案少很多的BUG。
當選擇一個外部或第三方的框架時，確保它們與其他框架“合得來”。儘量找出足夠的證據證明你將使用到的框架之間都能夠很好地進行相容。
在開發過程中你不得不更換某些框架，因為你發現某些部分在其他框架中運行時並沒有像預期那樣進行工作，不管怎樣這都會迫使你耗費時間去另尋解決方案，同時這也會耗費你更多時間去做那些並不想做的回歸工作。
選擇一個好的測試框架。跟上一條相似，確保測試框架無需耗費你額外的精力就能與其他框架一起工作。
一個測試框架的好壞取決於它針對項目所能覆蓋的測試範圍。如果它對你將使用到的特定的技術和模塊不是很合適或者不能完全進行覆蓋，那就不要依賴它。
八個蓋子十個鍋並不是一個好的主意
對於下一個我將會參與到的項目，我會竭盡全力遵循這些原則並且在有必要的時候進行更新。也許這裡的假定有一個或多個會有所改動或者被改善。
對於開始實施一個新項目時首先應該做什麼這事，如果你的經歷告訴你有不同的觀點，你可以自由地分享你的觀點和建議。
