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