譯文 | 爲何軟件架構如此重要？

拋開某項特定的技術或某個特定的項目不說，這篇文章我想講講關於犯錯這個話題。編程

談論和讚賞成功也許很輕鬆，可是我發現犯錯還是個頗有意思的話題。主要是由於它們在學習的過程當中很有用處。設計模式

一開始我將講一些背景知識，而後闡述一下我對軟件架構的見解。後者是我認爲在軟件開發過程當中最重要的一部分，而且談下如何避免陷入常見的開發陷阱。架構

預熱階段

當任何一個程序員被問到：框架

「哪一種方式你更爲熱衷：從零開始一個項目，或者維護一個已存在的項目?」編程語言

他們一般回答：工具

「從零開始一個項目」學習

答案是顯而易見的，由於成就感給人帶來的感受更棒。咱們能夠這樣說：「這是我作的（至少是其中至關的一部份內容）。以前並不存在，而如今，看！就在眼前。」測試

但其中的意義每每不止於此。人類的大腦是喜歡有秩序的，它喜歡從一些混亂和看似隨機的信息中尋找規律（模式），在軟件開發中，這點也同樣。url

可是在一個已存在的項目中會發生什麼？極可能這個項目已經摻雜必定程度的混亂，而且它的混亂程度顯然比一個不存在的項目嚴重多了。

所以，最直接的迴應（作法）是從頭開始一個項目，這樣的話你就能夠徹底經過你的經驗來把控它的混亂度。

固然，在軟件的烏托邦，咱們永遠不會由於疏忽大意而（給項目）形成混亂的局面。遺憾的是，咱們並非生活在那個世界，可是咱們能夠用工具和原則來指導咱們。

咱們所擁有的用來處理迴歸復原、修復BUG等使人厭惡的任務的最好方式就是提早作規劃。一個優秀的架構是咱們的朋友。

一個優秀的設計解決方案頂得上數千個小時的時間，畢竟在將來它真的幫咱們省掉了不少時間。

咱們大多數都看過一些書，咱們知道要作什麼。咱們一樣應該認真地進行（軟件）測試和應用設計模式。「讓咱們真正專一併貫徹於MVC（譯註：一種將業務邏輯、數據和界面顯示分離的軟件設計模式）；讓咱們爲此採用BDD模式（譯註：行爲驅動開發，敏捷開發技術的一種）；讓咱們在寫生產代碼前先設計特性測試。」

有時候，咱們忘記了第一步該作什麼的重要性，甚至在那以前。

固然，在你寫功能性代碼前，是的，請寫下你的第一個測試案例。

但在你寫下第一個測試案例以前，設計團隊有可能已經收集了全部的需求，已經與客戶和其餘利益相關方達成了協議，他們甚至可能已經出來了多個版本的產品設計方案並進行了多加驗證，因此你可能會認爲你應該當即進行代碼的編寫。

整個團隊應該坐下來討論關於他們將要開發的產品。他們應該拿出一張紙或者到白板面前，而後開始列舉將來產品將要有的特性。

清晰地肯定出全部的技術要求和提議方案的可行性。考慮在實施不一樣的實現方案中每一步所面臨的挑戰併爲此想出解決措施，多是（採用）不一樣的框架，甚至是不一樣的編程語言。

兜底地說，（在軟件開發中）沒有其餘事情能值得你花的時間與花在架構同樣多。

對於我來講，最好的學習方式之一就是犯錯。

儘管犯錯會讓人感到困窘和沮喪，但當咱們真犯了錯，咱們就會投入精力去弄明白究竟發生了什麼，會努力地尋找解決方案，找到再也不犯一樣錯誤的最好辦法。

這就等同於經驗。

經驗就是錯誤的別稱。

—— 奧斯卡·王爾德

最近我在作一個很是複雜的IOS項目。在項目剛開始的時候，有幾件事情是沒作好的。需求並無百分百肯定，先決條件並無百分之百知足，APIs（應用程序接口）還沒準備好……

但最重要的多是：咱們沒有像咱們應該作的那樣定義出項目的架構。

**固然，我是在出現損失時才意識到這點的。**咱們（當時）作了大量的還原、改寫的工做，有幾回我一直追問本身說：「爲何我沒有采用正確的方式？」

**一個陷阱是：沒有使用測試框架。**歸根到底，測試和驗證是經過用戶測試和代碼檢視來完成的。而後當一個測試框架真正地被引進項目時，這已經太晚了。

一個熱門的被衆人所承認的IOS開發框架並非都能適用於全部的複雜狀況的，也並不必定適用於各類開發語言和彌補在設計產品架構時（從技術的角度來看）所做出的糟糕決策。

敲黑板。你接到一個新項目，可能你在需求收集階段就已經開始參與了。拋開腦海中已有的針對這項目的總體技術解決方案的想法，我會建議：

**寫下全部的東西。**製做圖表，畫組件圖、類圖、流程圖，寫下全部你以爲有助於你和團隊快速瞭解問題全貌的東西。

平時常拿出來進行反覆思考，在寫下第一行代碼前可能會對其作屢次的更改修正。
**當全部的組件/模塊已經定義好了，嘗試爲其找一些現有的可靠的解決方案。**開源框架是一個很好的方向，由於它們已經被不少人測試過和使用過，所以也會比你本身實現的方案少不少的BUG。
**當選擇一個外部或第三方的框架時，確保它們與其餘框架「合得來」。**儘可能找出足夠的證據證實你將使用到的框架之間都可以很好地進行兼容。

在開發過程當中你不得不更換某些框架，由於你發現某些部分在其餘框架中運行時並無像預期那樣進行工做，無論怎樣這都會迫使你耗費時間去另尋解決方案，同時這也會耗費你更多時間去作那些並不想作的迴歸工做。
**選擇一個好的測試框架。**跟上一條類似，確保測試框架無需耗費你額外的精力就能與其餘框架一塊兒工做。

一個測試框架的好壞取決於它針對項目所能覆蓋的測試範圍。若是它對你將使用到的特定的技術和模塊不是很合適或者不能徹底進行覆蓋，那就不要依賴它。

八個蓋子十個鍋並非一個好的主意

對於下一個我將會參與到的項目，我會不遺餘力遵循這些原則而且在有必要的時候進行更新。也許這裏的假定有一個或多個會有所改動或者被改善。

對於開始實施一個新項目時首先應該作什麼這事，若是你的經歷告訴你有不一樣的觀點，你能夠自由地分享你的觀點和建議。