欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

本文最初發(fā)布于 Gergely Orosz 的個(gè)人博客，經(jīng)原作者授權由 InfoQ 中文站翻譯并分享。

我個(gè)人在大型系統的設計與構建方面擁有比較豐富的實(shí)踐經(jīng)驗。我參與重寫(xiě)了 Uber 的 分布式支付系統，設計并交付了 Skype on Xbox One，開(kāi)源了 Uber 的移動(dòng)架構框架 RIBs。所有這些系統都曾經(jīng)經(jīng)歷充分設計、多次迭代，并進(jìn)行過(guò)大量白板規劃與實(shí)際討論。此后，這些設計思路被整理成一份設計文件，且在實(shí)際著(zhù)手開(kāi)發(fā)之前進(jìn)行反復傳閱以盡量收集反饋意見(jiàn)。

這些系統都有一個(gè)共同的特點(diǎn)，就是規模龐大：成百上千的開(kāi)發(fā)人員共同進(jìn)行構建，它們同時(shí)也為數百萬(wàn)人使用的其它系統提供支持。另外，這些系統也并不是全新項目——重寫(xiě)的支付系統負責取代現有的兩套支付系統，而且要求不能對正在使用這兩套系統的其它數十套系統及團隊造成任何業(yè)務(wù)影響。我們還對 Uber 的 App 進(jìn)行了重寫(xiě)，其中同樣涉及幾百名工程師的協(xié)作，大家攜手將現有功能移植到新的架構當中。

這里，我先聊聊一些可能與大家印象中不同的情況。

第一，這些設計工作沒(méi)有使用任何標準軟件架構規劃工具。 是的，我們沒(méi)有使用 UML、4+1 模型、ADR、C4 或者是依賴(lài)關(guān)系圖。我們整理出了大量圖表，但這些圖表并未遵循任何嚴格的規則。這些只是非常簡(jiǎn)單的圖框加箭頭的組合，用于描述信息流或者類(lèi)結構與各組件之間的關(guān)系。事實(shí)上，同一設計文檔中的兩份圖表經(jīng)常采用完全不同的 Layout，而且往往由不同的工程師負責添加與修改。

第二，設計工作并不歸屬于團隊中的任何特定架構師。 我們壓根沒(méi)有設置 IT 架構師或者企業(yè)架構師職位。大家沒(méi)有聽(tīng)錯，Uber 以及微軟 /Skype 都沒(méi)有專(zhuān)門(mén)指定軟件架構師角色，即使是主管工程師這類(lèi)高級技術(shù)人員也得定期編寫(xiě)代碼。在全部項目當中，我們都引入了經(jīng)驗豐富的工程師，但架構或者設計本身并不歸屬于任何一位成員。他們?yōu)樵O計過(guò)程提供了巨大的幫助，但同時(shí)團隊中的初級成員也發(fā)揮著(zhù)重要作用，而且可以隨時(shí)提出反對意見(jiàn)并提供其它替代性方案。

第三，我們幾乎沒(méi)有參考任何常見(jiàn)的架構模式以及軟件架構文獻中的術(shù)語(yǔ)——例如 Martin Fowler 的架構指南。我們根本不提微服務(wù)、無(wú)服務(wù)器架構、應用程序邊界、事件驅動(dòng)架構這類(lèi)概念。雖然在頭腦風(fēng)暴期間偶爾會(huì )涉及，但我們覺(jué)得沒(méi)必要把它們寫(xiě)進(jìn)設計文檔當中。

那么，我們到底是怎么做的？為什么我們沒(méi)有遵循眾所周知的軟件架構建議方法？

就這個(gè)問(wèn)題，我與來(lái)自其他 FANG 技術(shù)公司（即 Facebook、亞馬遜、Netflix、谷歌）以及小型初創(chuàng )企業(yè)的同行工程師進(jìn)行過(guò)討論。事實(shí)證明，大多數團隊和項目（無(wú)論具體規模如何）都采用了以下幾種設計與實(shí)施方法：

1. 從業(yè)務(wù)問(wèn)題入手。 我們想要解決什么問(wèn)題？我們希望構建怎樣的產(chǎn)品？為什么？我們如何衡量成功程度？
2. 通過(guò)頭腦風(fēng)暴探尋合適方法。 匯聚團隊并通過(guò)充分對話(huà)找到可行的解決方案。盡量控制頭腦風(fēng)暴的對話(huà)規模，先從宏觀(guān)問(wèn)題開(kāi)始，再逐步落地至具體需求。
3. 通過(guò)白板探尋合適方法。 將團隊聚集在一起，由一個(gè)人負責匯總團隊提出的整體方法。我們應該能夠在白板上明確闡述系統 / 應用程序的架構，同樣首先從宏觀(guān)起步，并在必要時(shí)深入探討。如果發(fā)現解釋過(guò)程存在困難或者無(wú)法表述清楚，則證明細節還需要進(jìn)一步打磨。
4. 根據白板上的說(shuō)明，通過(guò)簡(jiǎn)單的文檔與圖表對內容進(jìn)行歸納。 盡量不使用那些晦澀難懂的術(shù)語(yǔ)：確保初級工程師們也能很快理解文檔的表意。另外，使用清晰易懂的語(yǔ)言。在 Uber，我們使用 RFC 類(lèi)文檔并配合一套基礎模板。
5. 討論權衡取舍與替代性方案。 良好的軟件設計與理想的架構，在本質(zhì)上就是做出了正確的權衡取舍。設計選擇本身并沒(méi)有好壞之分，一切都取決于背景與目標。你的架構是否被劃分為多項不同服務(wù)？為什么不使用大型整體服務(wù)，畢竟這能帶來(lái)其它一些優(yōu)勢，比如更直接且更快的部署方式。再有，你是否選擇使用新功能擴展服務(wù)或模塊？對每一項服務(wù)或模塊的選擇做出權衡，充分評估既定方法的優(yōu)勢與缺點(diǎn)。
6. 在團隊 / 組織之內傳閱設計文檔并整理反饋意見(jiàn)。 在 Uber，我們一直堅持向所有工程師發(fā)送軟件設計文件，直到工程師隊伍達到約 2000 人級別?，F在我們的規模更大了，但設計文件的傳閱范圍仍然很廣——當然，我們同時(shí)也會(huì )考慮信噪比平衡問(wèn)題。我們鼓勵大家提問(wèn)并提出替代性方案。另外，設定合理的時(shí)間限制討論反饋內容，并酌情將其納入考量。某些直接反饋可能會(huì )當場(chǎng)解決，而更具體的反饋則可以由相關(guān)人員協(xié)商處理。

為什么我們的方法跟軟件架構文獻中的說(shuō)法有這么大的差別？

實(shí)際上，對于大多數架構指南而言，我們的方法在原則上并沒(méi)有多大區別。幾乎所有指南都建議從業(yè)務(wù)問(wèn)題起步，繼而概述解決方案與權衡結論：我們也是這么做的。我們的區別，在于沒(méi)有使用那么多架構師或者架構文獻所強調的高復雜度工具。我們盡可能只選擇簡(jiǎn)單的工具，例如 Google Docs 或者 Office 365 等，同時(shí)保證設計記錄簡(jiǎn)潔明確。

我認為，這種方法與相關(guān)企業(yè)的工程文化息息相關(guān)。高度自治加層次分明，是這些科技企業(yè)與初創(chuàng )企業(yè)的共同特質(zhì)：這些特質(zhì)，在相對比較傳統的公司內則很少見(jiàn)到。正因為如此，傳統企業(yè)才必須在流程驅動(dòng)設計當中遵循更為嚴格的規則，以進(jìn)行更多“符合常識的設計”。

以銀行與汽車(chē)制造企業(yè)為例，開(kāi)發(fā)人員幾乎無(wú)權跨越上級提出任何關(guān)于架構的決策，全部相關(guān)工作都由不同級別的多位架構師負責，而他們也需要隨時(shí)監督多個(gè)技術(shù)團隊。這就讓整個(gè)流程變得相當緩慢，架構師本身也往往被大量請求吞沒(méi)。正因為如此，常見(jiàn)架構文獻中才提到盡量使用標準工具、整理出更加正式的文檔，希望借此讓系統設計思路更為清晰。再有，這些文檔還強化出一種自上而下的工作執行思路，畢竟在架構師的約束之下，普通工程師根本就無(wú)權對當前采取的正式方法或者決策提出質(zhì)疑。所以，他們通常也就懶得費那個(gè)心。公平地講，傳統企業(yè)同樣希望開(kāi)發(fā)人員之間能夠更多交換資源與意見(jiàn)，從而在短時(shí)間之內靈活分配人員以應對不同項目，只是對他們來(lái)講這樣的目標很難實(shí)現?？紤]到這一點(diǎn)，我們在不同環(huán)境中使用不同工具的靈活作法其實(shí)也沒(méi)那么離經(jīng)叛道。

設計系統應該始終秉持簡(jiǎn)單為先的目標。 系統越簡(jiǎn)單，理解難度也就越低，越易于發(fā)現問(wèn)題，實(shí)現門(mén)檻也就更低。另外，語(yǔ)言描述越清晰，設計思路也越容易為他人所接受。因此，請避免使用那些團隊成員無(wú)法理解的術(shù)語(yǔ)：即使是經(jīng)驗最少的成員，也應該能夠弄明白團隊到底在干什么、又為什么這么干。

干凈的設計類(lèi)似于干凈的代碼：易于閱讀，易于理解。編寫(xiě)干凈的代碼，我們可以選擇多種可行方法；但是，很少有人會(huì )建議在代碼開(kāi)發(fā)之初就采用 Gang of Four 設計模式。相反，干凈代碼的起步工作也同樣單純：?jiǎn)我回熑?、明確命名與易于理解的約定。這些原則也同樣適用于干凈的架構。

既然是這樣，那么架構模式還有什么意義？ 我認為架構模式的意義跟編碼設計模式差不多，主要負責為我們提供如何改進(jìn)代碼或者架構的基本思路。在編碼模式方面，當我發(fā)現一種模式時(shí)，往往會(huì )精神一振，嘗試深入探索并將其與單例模式聯(lián)系起來(lái)。但是，我可不打算硬性上升到“抽象生產(chǎn)模式”的高度。一般來(lái)講，只要我能弄明白這種模式的作用，并搞清要如何將其廣泛起效就足夠了。我承認，我也花了不少時(shí)間研究并嘗試理解 Gang of Four 設計模式，但是需要強調：這些對我編碼水平的提升，遠不及從其他工程師那里得到的反饋。

同樣的，了解常見(jiàn)架構模式也是好事：這有助于簡(jiǎn)化同事之間的討論流程，確保大家能夠以相同的方式溝通并相互理解。但是，架構模式本身并不是目標，也永遠不該被用于取代那些真正簡(jiǎn)單的系統設計方法。在設計系統時(shí)，我們可能會(huì )意外發(fā)現自己用到了某種眾所周知的模式：這挺好的。但這不是強制要求，大家應該放松心態(tài)選擇自己的辦法?？偠灾?，千萬(wàn)別把架構模式當成“錘子”，到處尋找合適或者不合適的“釘子”來(lái)敲。

架構模式的出現，源自工程師們在觀(guān)察到某些情況下存在著(zhù)共通的設計選擇傾向，而且這些設計選擇同樣會(huì )經(jīng)過(guò)命名、記錄以及廣泛討論。換言之，架構模式是解決方案出現之后才產(chǎn)生的工具，旨在讓其他開(kāi)發(fā)者能夠更輕松地解決問(wèn)題。作為一名工程師，大家的目標應該是更好地解決問(wèn)題，讓解決方案變成自己的有力工具，而不是強行運用那些時(shí)髦的架構模式，然后祈禱它們真能適合你的實(shí)際需求。

我聽(tīng)說(shuō)，很多朋友都希望了解如何提升自身在架構與系統設計方面的水平。有些經(jīng)驗豐富的從業(yè)者會(huì )推薦大家閱讀與架構模式以及軟件架構相關(guān)的書(shū)籍。當然，多讀書(shū)肯定是好事，一般書(shū)籍的內容在深度上要遠遠超過(guò)網(wǎng)站上的帖子；但我個(gè)人的建議是，親自動(dòng)手永遠比單純閱讀效果更好。

• 召集同事，用白板解釋你的設計方法。 闡述你正在做什么，以及為什么要這么做，同時(shí)確保同事們能夠真正理解。在過(guò)程當中，請認真傾聽(tīng)他們的反饋。
• 把你的設計思路整理成一份簡(jiǎn)單的說(shuō)明文檔，并與其他團隊成員分享以征求反饋意見(jiàn)。 無(wú)論你手頭的工作有多簡(jiǎn)單或者說(shuō)多復雜，做做總結都是必要的環(huán)節。請以方便自己及他人理解的方式整理文檔，Uber 公司就一直有這種良好的習慣。另外，在分享中也要對反饋意見(jiàn)敞開(kāi)胸懷，允許大家通過(guò) Google Docs 或者 Office 365 等平臺添加評論與注釋?zhuān)璐肆私馑说南敕ㄅc疑問(wèn)。
• 采取兩種不同的方式，并對兩種設計方案作出比對。 大多數在設計架構時(shí)，往往只會(huì )拿出一套方案，也就是他們腦海中首先浮現的處理辦法。但是，架構選擇絕不是非黑即白的，因此請嘗試整理出第二種可行的設計成果。對二者加以對比，并說(shuō)明為什么其中一種比另一種更好。最后，簡(jiǎn)要列出第二套備選設計方案，并在討論中確定為什么不予采用。
• 明確說(shuō)明你的權衡思路，為什么要做出這樣的權衡，以及你據此進(jìn)行的優(yōu)化。 明確強調當前存在的約束條件，并將其充分納入考量。
• 審查其他人的設計，取其精華。 假設你所在的企業(yè)鼓勵大家通過(guò)白板、會(huì )議或者文檔的形式分享自己的設計，那么請務(wù)必多花心思從中汲取營(yíng)養。在審查期間，大多數人只是被動(dòng)接受現有方案，這是一種單向的觀(guān)察行為，毫無(wú)實(shí)際意義。相反，我們應該弄清那些自己不太明確的部分，包括向發(fā)布者詢(xún)問(wèn)他們是否考慮過(guò)其它替代性方案。此外，詢(xún)問(wèn)他們采取了怎樣的權衡取舍，以及假設中的約束條件。合適的時(shí)候不妨唱唱反調，提出可能更為簡(jiǎn)單的選項——即使未必更好——然后聽(tīng)取對方的看法。即使最終沒(méi)有被選中，這樣的思維過(guò)程也足以帶來(lái)實(shí)際價(jià)值并幫助我們學(xué)到更多。

最好的軟件設計應當簡(jiǎn)單易懂。 在啟動(dòng)下一個(gè)新項目之前，請不要再思考“我該如何構建這套系統、應該采用哪些經(jīng)過(guò)實(shí)踐驗證的模式，又選擇哪種正式方法進(jìn)行記錄？”相反，想想“我要怎樣才能以他人更易于理解的方式，拿出最簡(jiǎn)單的設計？”

最后還得強調一句，軟件架構最佳實(shí)踐、企業(yè)架構模式以及系統描述的正式方法都是非常重要且實(shí)用的工具，相信總會(huì )有合適的場(chǎng)景讓它們發(fā)揮作用。但在設計系統時(shí)，請從簡(jiǎn)單始、以簡(jiǎn)單終，盡可能避免一切會(huì )無(wú)謂提高復雜度的架構與正式工具。

原文鏈接：

https://blog.pragmaticengineer.com/software-architecture-is-overrated/

今日薦文

點(diǎn)擊下方圖片即可閱讀