架構的通俗定義?架構是一個充滿了自由度的工作，是一個最不适合用過去的成功指導下一波策略設計的領域，無論你過去的領域和這個領域有多相像，你過去的成功經驗都隻能拿來參考，不适合用來拷貝，下面我們就來說一說關于架構的通俗定義?我們一起去了解并探讨一下這個問題吧!

架構的通俗定義

架構是一個充滿了自由度的工作，是一個最不适合用過去的成功指導下一波策略設計的領域，無論你過去的領域和這個領域有多相像，你過去的成功經驗都隻能拿來參考，不适合用來拷貝。

因為即使是完全相同的領域，時間已經不同了，行業生态，技術發展已經不同了，你面對的人不同了，業務的瓶頸已經不同了，生态的各個利益體的投資已經不同了，成熟的領域人員可能減少，當初的績優股可能已經失敗，你面對的是一個新的領域，我們做架構，永遠不能被過去的“定義”，左右了我們的判斷。所以，做新的架構設計，你可以參考過去的成功pattern，但你的分析，必須建立在現在的條件上，不能離開對現在問題的調查，直接打算使用過去的模式。

這是我對我們進行産品戰略設計的第一個建議。

架構設計是一個非常微妙的設計領域，它是完全建立在形而上的邏輯上的，它是抽象的，非具象的。但這種抽象必須要以可以實施為底線，否則就淪為紙上談兵了。所謂高以下為基，貴以賤為本。所以，我們不要出現“架構上我們應該如何如何，但我們現在人力不足啊”這樣的思維角度，這是廢話，架構就是建立在準備實施這個角度上的，你不能把架構設計和實施隔離，說一堆“我們要如何如何，隻是某某條件不成熟。”這樣的鬼話，如果某某條件不成熟，你就不該做出這個設計來浪費我們的時間。

架構設計是實施團隊的一部分，沒有獨立于實施的架構設計。架構設計90%的工作是輔助實施團隊實施架構戰略和挑戰架構戰略，不是實施之外的獨立設計。把人分離出來是為了保證投入，不是為了讓這個團隊成為實施團隊的競争者。

但反過來說，你不能說我們現在隻有多少多少人，我們就做一個基于現在有多少人的方案，因為事情是變化的，在架構設計初期，給你很多的人，你也用不了，人力多了是個累贅，看在财報上每個月花出去的錢就讓人害怕，但如果你的設計隻是現在有多少人，那後面開始展開了，你根本就發展不了。沒有準備，未來有可能給你補人你也接受不了。如果人力不是這樣從小到多的一個變化過程，我們也不需要架構設計，架構設計必須可以響應這種人力，資源，市場等各方面的變化。

所以，我們從一開始就做好了做這種多步的策略的打算，考慮整體目标的時候，要用整個市場域的機會作為我們發展的上限，在實施的時候，要考慮好怎麼一步步增強投資者和市場的信心，從而可以有序擴大整個業務，不要用“我的架構沒有錯，錯的是市場，錯的是人力資源沒給夠人，錯的是……”來給自己做理由。架構設計包括對這些“别人的錯”的預判。架構設計和實施是和整個産品的所有其他力量（開發，銷售，維護，财務，法務等等）融合在一起的，沒有獨立于這些開發力量的架構設計。

這是第二個建議。

但對于這個建議，我有個直接的工作技巧可以分享。當我們确切落筆寫一個架構設計的時候，要考慮：以客戶為目标，以工程為準繩。

什麼意思呢？就是說，你在架構設計的第一個部分，要明确說你打算賣一個什麼樣的東西到市場上去，你的客戶打算買你的東西，這個決定的控制要素是什麼？有這樣一個标準在最前面，我們中間的所有變化，遇到的障礙，我們都知道往哪裡繞。也知道我們繞完了，應該繼續向什麼方向走。

而在你的架構設計的最後一段，你要把你的所有設計落實為“版本”和“項目”。所有的人力管理，都是以項目為基礎的，因為項目有确切的目标和人力資源投入，而不是“小李你去幫幫他們”這種盡力而為的東西，架構策略一旦展開，所有人都會面對無限的要求，沒有确切的資源分割，凡是長遠的東西都會被忽略和放棄。所以，要把架構策略得以實施的希望建立在人力資源管理上，不要建立在“期望”，“正義”，“道德”，“道理”這些依賴上。所謂子非不辨也，老子忙起來誰都不認也。另外，搜索公衆号頂級架構師後台回複“offer”，獲取一份驚喜禮包。

當然，我這裡說的項目，是廣義的項目，不一定是你流程中說的那個項目。

而項目，要輸出确切的版本，你有硬件，有軟件，有插件，這些都是有版本的，不要說什麼做一個my-wonderful-app，裡面支持這特性，那特性的。

你的軟件上了市場，遇到一堆的客戶，這些客戶的要求都會不一樣，你是用一個版本還是用多個版本去響應他們？産品是會有Bug的，是要有新特性開發的，修複Bug和增加新特性是會引入新的Bug的，所以，客戶可能可以接納升級你修複他的Bug的版本，可不一定肯接納你發布的修複其他人問題的版本的。

這樣，你在市場上就會有很多版本，這是天然的，版本一多，開發，測試，維護，管理的成本會大幅上升，這是一個重要的工程控制要素。你用my-wonderful-app這一個概念來考慮你的設計，你實施的時候就會怎麼搞怎麼不正常，因為你以為你開發的是my-wonderful-app，其實你開發的是my-wonderful-app-v1、my-wonderful_app-v2、my-wonderful-app-v2.1、my-wounderful-app-v2.1-without-tso-llvm_v7_specific-edition……你對人力和項目的預判都是錯誤的，當然執行不下去了。

所以，很多人其實不明白“開源交付”是個什麼東西，開源交付其實是一種減少版本的方法，一個源代碼樹是可以編譯出很多二進制版本的，我給你源代碼，編譯産生多個版本的的維護成本就是你的了，很多人以為交付源代碼是對用戶友好，是為行業做貢獻——那得看客戶是想當你的競争對手，還是想解決他的問題了。（但即使你用“源代碼交付”，如果是商業交付，你的測試還是需要落實到一組二進制版本上的，而且你必須很清楚，這些二進制版本都是會升級的，死版本支持的生态是死的生态）

但無論如何，架構設計一個基本的要求，高以下為基，不要離開你的工程成本想得天花亂墜，隻要涉及工程，什麼美好想法都得給我從天上掉下來。

第三個建議：調查和設計也是要結合起來的。架構設計初期，我們有無數的“未知”：競争對手的戰略是什麼？客戶的期望是什麼？研究機構有什麼新的突破？市場份額的預測是什麼？國家政策的走向是什麼？……

如果你要調查完這些東西才做決定，你就永遠都不用做了。所以，進行架構設計，要勇敢進行“猜”，“預判”，哪怕錯了，你也要“猜”，因為這是架構設計工作的基礎。你的決策要同時決策：使用猜這個結論和再調查一下，哪個投資收益比更低？然後就要去實施。我在這個專欄中經常強調“守弱”，其本質就是這個：架構本身就是一種猜，我們在猜的基礎上執行，如果你非要維護面子，在執行的時候收到當時猜錯了的反饋，你死要面子不肯調整，那這個架構執行就失敗了。

所以，做架構不能要面子，你眼中隻能有産品的最後成功，到成功的時候，你坐在那裡，旁邊的人說什麼，你都可以冷冷看着他，由他講他的道理，你根本不用在乎。

這樣就要提到第四個建議了：你不要指望實施團隊會很喜歡你，你做的所有事情，都是為了未來讓他們“繞路”走，你的結論他們不會喜歡的。你可以用你所有的個人魅力去盡量soften這種沖突，你可以下去和他們一起分擔開發調試的壓力，讓他們沒有那麼恨你，但你要知道，如果實施團隊很舒服，你的架構設計肯定變成在旁邊說胡話了，根本沒有設計效果。

所以，你決定來做架構了，就不要期望你有多nice。這是這個工作的特性，不能調和的。不要為了實施團隊的一般抱怨就去改變你的設計去迎合，否則産品失敗的時候，就沒有人跟你抱怨了。吾之所以有大患者，為吾有身，及吾無身，何患之有？你應該多聽實施團隊的抱怨，但你要分清楚哪些是真正在反饋問題，哪些隻是你戰略實施的成本。

最後一個建議：架構團隊來自不同的領域，不要用“領域代表”看待自己。不要說我隻是做芯片設計，我隻是做安全的，我隻是做内核的，我隻是做數據庫的。架構團隊存在的目的，就是為了設計那些多個模塊互相甩鍋的Gap，然後所有模塊和協同起來，達到最優的效率。你盡然進來架構組了，你就不是某個模塊的“甩鍋代表”，你就是整個産品。

大部分投資者都是不懂技術的，就算他們來自技術背景，他們對你實施的這個技術也是外行，因為細節隻是我們知道，否則他就不用你來做了，他自己做就好了。這些人決策的方式就是“多方确認”。

如果架構組自己都達不成共識，各說各話，那怎麼說服投資人（其實包括準備用你的客戶），所以，架構組每個人都應該對整個架構策略都很熟悉。我不要求做芯片的人就會寫程序，但我需要做芯片的人知道軟件部分的構架要求，在解決方案中所處的地位。你不要告訴我你隻懂UEFI，不懂Kernel是怎麼做的，我需要你知道ACPI表那些信息是給Kernel的哪個模塊看的，你不是在做實施，等着别人給要求，你是那個負責知道少給一張EINJ表，Kernel會不會起不來的人。

推廣起來說，作為一個産品的架構團隊，你也不能隻管“我的産品如何如何”，你必須從整個産業生态上開始設計。狼吃羊，羊吃草，你不能說你是狼，不管羊的死活。沒有羊了，狼也死了。做架構設計的人，必須知道狼可以吃多少羊，吃到什麼時候就要開始收手了。

所以，對于一個産品的架構師，必須知道整個生态鍊是怎麼運作的，要為了整個生态的平衡，不怕把自己部分自己的業務讓給其他産品，其他企業，也不怕自己背上别人不肯實施的業務，這樣你才會有掌控生态的力量。

大概就是這樣一些吧，再往下，就是具體業務怎麼做的問題的。但當我們碰到困難的時候，不妨回頭來看看我們的總體思路，也許覺得無路走的時候又發現有路了，覺得很順利的時候，說不定就是危機的開始了。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!