轉(zhuǎn)載架構(gòu)漫談專欄系列文章 來源自微信公眾號(hào)聊聊架構(gòu)，

http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=409047489&idx=1&sn=7d934240f51580b545fe9d08aeee4251&scene=0#wechat_redirect

架構(gòu)漫談是由資深架構(gòu)師王概凱Kevin執(zhí)筆的系列專欄，專欄將會(huì)以Kevin的架構(gòu)經(jīng)驗(yàn)為基礎(chǔ)，逐步討論什么是架構(gòu)、怎樣做好架構(gòu)、軟件架構(gòu)如何落地、如何寫好程序等問題。專欄的目的是希望能拋出一些觀點(diǎn)，并引發(fā)大家思考，如果你有感觸或者新的感悟，歡迎聯(lián)系專欄負(fù)責(zé)人Gary（微信greenguolei）深聊。

完整版pdf下載：

http://q.infoqstatic.com/ppt/Informal-Discussion-on-Architecture.pdf#rd?sukey=ecafc0a7cc4a741b5845e6edfad7f5b364cf4c840d99548dedd53bfffb334224282c1c3b5f2d004c648e99248e18b129

架構(gòu)漫談（一）：什么是架構(gòu)？

本文是漫談架構(gòu)專欄的第一篇，作者將會(huì)通過類比的方式來介紹什么是架構(gòu)以及為什么會(huì)產(chǎn)生架構(gòu)。 緣起一直以來，在軟件行業(yè)，對(duì)于什么是架構(gòu)，都有很多的爭(zhēng)論，每個(gè)人都有自己的理解。甚至于很多架構(gòu)師一說架構(gòu)，就開始談?wù)撌裁磻?yīng)用架構(gòu)、硬件架構(gòu)、數(shù)據(jù)架構(gòu)等等。我曾經(jīng)也到處尋找過架構(gòu)的定義，請(qǐng)教過很多人，結(jié)果發(fā)現(xiàn)，沒有大家都認(rèn)可的定義。套用一句關(guān)于big data流行的笑話，放在架構(gòu)上也適用： Architecture is like teenage sex，everybody talks about it，nobody really knows what is it。 事實(shí)上，架構(gòu)在軟件發(fā)明時(shí)的N多年以前，就已經(jīng)存在了，這個(gè)詞最早是跟隨著建筑出現(xiàn)的。所以，我覺得有必要從源頭開始，把架構(gòu)這個(gè)概念先討論清楚，只有這樣，軟件行業(yè)架構(gòu)的討論才有意義。 什么是架構(gòu)？架構(gòu)的英文是Architecture，在Wikipedia上，架構(gòu)是這樣定義的： Architecture (Latin architectura, from the Greek ?ρχιτ?κτων arkhitekton”architect”, from ?ρχι- “chief” and τ?κτων “builder”) is both the process and the product of planning, designing, and constructing buildings and other physical structures。 從這個(gè)定義上看，架構(gòu)好像是一個(gè)過程，也不是很清晰。為了講清楚這個(gè)問題，我們先來看看為什么會(huì)產(chǎn)生架構(gòu)。 為什么會(huì)產(chǎn)生架構(gòu)？想象一下，在最早期，每個(gè)人都完全獨(dú)立生活，衣、食、住、行等等全部都自己搞定，整個(gè)人類都是獨(dú)立的個(gè)體，不相往來。為了解決人類的延續(xù)的問題，自然而然就有男女群居出現(xiàn)，這個(gè)時(shí)候就出現(xiàn)了分工了，男性和女性所做的事情就會(huì)有一定的分工，可是人每天生活的基本需求沒有發(fā)生變化，還是衣食住行等生活必須品。 但是一旦多人分工配合作為生存的整體，力量就顯得強(qiáng)大多了，所以也自然的形成了族群：有些人種田厲害，有些人制作工具厲害，有些地方適合產(chǎn)出糧食，有些地方適合產(chǎn)出棉花等，就自然形成了人的分群，地域的分群。當(dāng)分工發(fā)生后，實(shí)際上每個(gè)人的生產(chǎn)力都得到了提高，因?yàn)樽龅亩际敲總€(gè)人擅長(zhǎng)的事情。 整個(gè)人群的生產(chǎn)力和抵抗環(huán)境的能力都得到了增強(qiáng)。為什么呢？因?yàn)槊總€(gè)人的能力和時(shí)間都是有限的，并且因?yàn)槿说慕Y(jié)構(gòu)的限制，人同時(shí)只能專心做好一件事情，這樣不得已就導(dǎo)致了分工的產(chǎn)生。既然分工發(fā)生了，原來由一個(gè)人干生存所必需的所有的事情，就變成了很多不同分工的角色合作完成這些事情，這些人必須要通過某些機(jī)制合在一起，讓每個(gè)人完成生存所必需的事情，這實(shí)際上也導(dǎo)致了交易的發(fā)生（交易這部分就不在這里展開了，有機(jī)會(huì)再討論）。 在每個(gè)人都必須自己完成所有生活必須品的生產(chǎn)的時(shí)候，是沒有架構(gòu)的（當(dāng)然在個(gè)人來講，同一時(shí)刻只能做有限的事情，在時(shí)間上還是可能會(huì)產(chǎn)生架構(gòu)的）。一旦產(chǎn)生的分工，就把所有的事情，切分成由不同角色的人來完成，最后再通過交易，使得每個(gè)個(gè)體都擁有生活必須品，而不需要每個(gè)個(gè)體做所有的事情，只需要每個(gè)個(gè)體做好自己擅長(zhǎng)的事情，并具備一定的交易能力即可。 這實(shí)際上就形成了社會(huì)的架構(gòu)。那么怎么定義架構(gòu)呢？以上面這個(gè)例子為例，把一個(gè)整體（完成人類生存的所有工作）切分成不同的部分（分工），由不同角色來完成這些分工，并通過建立不同部分相互溝通的機(jī)制，使得這些部分能夠有機(jī)的結(jié)合為一個(gè)整體，并完成這個(gè)整體所需要的所有活動(dòng)，這就是架構(gòu)。由以上的例子，也可以歸納出架構(gòu)產(chǎn)生的動(dòng)力： 必須由人執(zhí)行的工作（不需要人介入，就意味著不需要改造，也就不需要架構(gòu)了） 每個(gè)人的能力有限（每個(gè)人都有自己的強(qiáng)項(xiàng)，個(gè)人的產(chǎn)出受限于最短板，并且由于人的結(jié)構(gòu)限制，同時(shí)只能專注于做好一件事情，比如雖然有兩只眼睛，但是只能同時(shí)專注于一件事物，有兩只手，無法同時(shí)做不同的事情。ps. 雖然有少部分人可以左手畫圓右手畫框，但是不是普遍現(xiàn)象） 每個(gè)人的時(shí)間有限（為了減少時(shí)間的投入，必然會(huì)導(dǎo)致把工作分解出去，給擅長(zhǎng)于這些工作的角色來完成，見2，從而縮短時(shí)間） 人對(duì)目標(biāo)系統(tǒng)有更高的要求（如果滿足于現(xiàn)狀，也就不需要進(jìn)行架構(gòu)了） 目標(biāo)系統(tǒng)的復(fù)雜性使得單個(gè)人完成這個(gè)系統(tǒng)，滿足條件2，3（如果個(gè)人就可以完成系統(tǒng)的提高，也不需要?jiǎng)e的人參與，也就不需要架構(gòu)的涉及，只是工匠，并且一般這個(gè)工作對(duì)時(shí)間的要求也不迫切。當(dāng)足夠熟練之后，也會(huì)有一定的架構(gòu)思考，但考慮更多的是如何提高質(zhì)量，提高個(gè)人的時(shí)間效率） 有人可能會(huì)挑戰(zhàn)說，如果一個(gè)人對(duì)目標(biāo)系統(tǒng)進(jìn)行分解，比如某人建一棟房子，自己采購(gòu)材料，自己搭建，難道也不算架構(gòu)嘛？如果對(duì)于時(shí)間不敏感的話，是會(huì)出現(xiàn)這個(gè)情況的，但是在這種情況下，并不必然導(dǎo)致架構(gòu)的發(fā)生。如果有足夠的自覺，以及足夠的熟練的話，也會(huì)產(chǎn)生架構(gòu)的思考，因?yàn)檫@樣對(duì)于提高生產(chǎn)力是有幫助的，可以縮短建造的時(shí)間，并會(huì)提高房子的質(zhì)量。事實(shí)上建筑的架構(gòu)就是在長(zhǎng)期進(jìn)行這些活動(dòng)后，積累下來的實(shí)踐。 當(dāng)這5個(gè)條件同時(shí)成立，一定會(huì)產(chǎn)生架構(gòu)。從這個(gè)層面上來說，架構(gòu)是人類發(fā)展過程中，由懵懵懂懂的，被動(dòng)的去認(rèn)識(shí)這個(gè)世界，變成主動(dòng)的去認(rèn)識(shí)，并以更高的效率去改造這個(gè)世界的方法。以下我們?cè)倌媒ㄖ砼e例加強(qiáng)一下理解。 最開始人類是住在山洞里，住在樹上的，主要是為了躲避其他猛獸的攻擊，以及減少自然環(huán)境的變化，對(duì)人類生存的挑戰(zhàn)。為了完成這些目標(biāo)，人類開始學(xué)會(huì)在平地上用樹木和樹葉來建立隔離空間的設(shè)施，這就是建筑的開始。但是完全隔離也有很多壞處，慢慢就產(chǎn)生了門窗等設(shè)施。 建筑的本質(zhì)就是從自然環(huán)境中，劃出一塊獨(dú)占的空間，但是仍然能夠通過門窗等和自然環(huán)境保持溝通。這個(gè)時(shí)候架構(gòu)就已經(jīng)開始了。對(duì)地球上的空間進(jìn)行切分，并通過門窗，地基等，保持和地球以及空間的有機(jī)的溝通。當(dāng)人類開始學(xué)會(huì)用火之后，茅棚里面自然而然慢慢就會(huì)被切分為兩部分，一部分用來燒飯，一部分用來生活。當(dāng)人的排泄慢慢移入到室內(nèi)后，洗手間也就慢慢的出現(xiàn)了。這就是建筑內(nèi)部的空間切分。 這個(gè)時(shí)候人們對(duì)建筑的需求也就慢慢的越來越多，空間的切分也會(huì)變成很多種，組合的方式也會(huì)有很多種，比如每個(gè)人住的房子，群居所產(chǎn)生的宗教性質(zhì)的房子，集體活動(dòng)的房子等等。這個(gè)時(shí)候人們就開始有意識(shí)的去設(shè)計(jì)房子，架構(gòu)師就慢慢的出現(xiàn)了。一切都是為了滿足人的越來越高的需求，提升質(zhì)量，減少時(shí)間，更有效率的切分空間，并且讓空間之間更加有機(jī)的進(jìn)行溝通。這就是建筑的架構(gòu)以及建筑的架構(gòu)的演變 總結(jié)一下，什么是架構(gòu)，就是： 根據(jù)要解決的問題，對(duì)目標(biāo)系統(tǒng)的邊界進(jìn)行界定。 并對(duì)目標(biāo)系統(tǒng)按某個(gè)原則的進(jìn)行切分。切分的原則，要便于不同的角色，對(duì)切分出來的部分，并行或串行開展工作，一般并行才能減少時(shí)間。 并對(duì)這些切分出來的部分，設(shè)立溝通機(jī)制。 根據(jù)3，使得這些部分之間能夠進(jìn)行有機(jī)的聯(lián)系，合并組裝成為一個(gè)整體，完成目標(biāo)系統(tǒng)的所有工作。 同樣這個(gè)思考可以展開到其他的行業(yè)，比如企業(yè)的架構(gòu)，國(guó)家的架構(gòu)，組織架構(gòu)，音樂架構(gòu)，色彩架構(gòu)，軟件架構(gòu)等等。套用三國(guó)演義的一句話，合久必分，分久必合。架構(gòu)實(shí)際上就是指人們根據(jù)自己對(duì)世界的認(rèn)識(shí)，為解決某個(gè)問題，主動(dòng)地、有目的地去識(shí)別問題，并進(jìn)行分解、合并，解決這個(gè)問題的實(shí)踐活動(dòng)。架構(gòu)的產(chǎn)出物，自然就是對(duì)問題的分析，以及解決問題的方案：包括拆分的原則以及理由，溝通合并的原則以及理由，以及拆分，拆分出來的各個(gè)部分和合并所對(duì)應(yīng)的角色和所需要的核心能力等。

架構(gòu)漫談（二）：認(rèn)識(shí)概念是理解架構(gòu)的基礎(chǔ)

本文是漫談架構(gòu)專欄的第二篇，作者通過幾個(gè)例子，討論了一下認(rèn)識(shí)概念的誤區(qū)，如何有效的去認(rèn)識(shí)概念，明白概念背后的含義，以及如何利用對(duì)概念的理解，快速的進(jìn)行學(xué)習(xí)。 在前一篇文章（點(diǎn)擊閱讀原文，查看第一篇文章）中，我們討論了什么是架構(gòu)。事實(shí)上，這些基礎(chǔ)概念對(duì)于做架構(gòu)是非常重要的，大部分人對(duì)于每天都習(xí)以為常的概念，都自以為明白了，但實(shí)際上都是下意識(shí)的，并不是主動(dòng)的認(rèn)識(shí)。比如說“什么是桌子？”，做培訓(xùn)的時(shí)候，我經(jīng)常拿這個(gè)例子來問大家，回答千奇百怪。這實(shí)際上就導(dǎo)致了做架構(gòu)的時(shí)候，不同角色的溝通會(huì)出很多問題，那么結(jié)果也就可想而知了。 如前一篇所說，架構(gòu)實(shí)際上解決的是人的問題，而概念是人認(rèn)識(shí)這個(gè)世界的基礎(chǔ)，自然概念的認(rèn)識(shí)就非常的重要。這篇文章嘗試討論一下，如何去認(rèn)識(shí)概念。當(dāng)然這篇不是語(yǔ)言學(xué)的文章，我這里所討論的，和語(yǔ)言學(xué)可能不太一樣，如果大家對(duì)語(yǔ)言學(xué)感興趣，也可以去參考一下。 首先我要先聲明一下，這一系列的文章，都是以人的認(rèn)識(shí)為主體去討論的，解決的都是人的問題，任何沒有具體申明的部分，都隱含這一背景，以免大家誤解。 概念也屬于人認(rèn)識(shí)這個(gè)世界并用來溝通的手段，包括“概念”這個(gè)概念，也是一樣的。在古代，不叫“概念”，稱之為“名相”。 何為相？一般我們認(rèn)為：看到一個(gè)東西，比方說杯子，“杯子”就是一個(gè)名字，指代的看到的東西就是相，就是事務(wù)的相狀。我們一聽到“杯子”這個(gè)詞，腦海里就會(huì)浮現(xiàn)出一個(gè)杯子的形象。而“杯子”這個(gè)詞，是用來指代的是這個(gè)相狀的，叫做名。合起來就叫做“名相”。 可是當(dāng)我們把杯子打碎了的時(shí)候，我們還會(huì)稱這個(gè)碎了的東西叫杯子嗎？ 肯定不會(huì)，一般會(huì)叫“碎瓦片”，如果我們把碎瓦片磨碎了呢，名字又變了，叫做“沙子”。這就奇怪了，同樣一個(gè)東西，怎么會(huì)變出這么多的名字出來？ 那究竟什么才是相？實(shí)際上“相“表達(dá)的不是一個(gè)具體的東西，如上面所提的一個(gè)瓷器杯子，并不是指這個(gè)瓷器，而是這個(gè)瓷器所起的一個(gè)作用：一手可握，敞口（一般不超過底的大小，太大口就叫碗了），并且內(nèi)部有一個(gè)空間可乘東西的這么一個(gè)作用。并不是指這個(gè)瓷器本身。這也是為什么我們從電視上看到一個(gè)人拿杯子的時(shí)候，我們知道這個(gè)是杯子。但是實(shí)際上我們看到的都是光影而已。所以說相實(shí)際上代表的是這個(gè)作用，并不是具體的某個(gè)東西，而名是用來標(biāo)識(shí)這個(gè)作用的，用來交流的。 為何需要這個(gè)作用？這個(gè)作用其實(shí)是為了解決“人需要一個(gè)可單手持握，但是希望避免直接接觸所盛物體”這個(gè)問題。 所以說，每個(gè)概念實(shí)際上所解決的，還是人遇到的某個(gè)特定的問題，我們把解決問題的解決方案，給定了一個(gè)名字，這個(gè)名字就是對(duì)應(yīng)的某個(gè)特定的概念。對(duì)于概念這個(gè)詞本身，為了統(tǒng)一指代這些名字，我們稱起這類作用的名字稱為“概念”。我們上次討論的“架構(gòu)”也是是同樣的一個(gè)特定概念，這里不再詳述。同樣，什么是“建筑”？ “建筑”實(shí)際上解決的就是“人需要獨(dú)占的空間，并還能夠比較流暢的和外部世界溝通”的問題。 再拿前面的“桌子”來舉例，什么叫“桌子”？ 很多人回答，四條腿，或者說有腿，有一個(gè)平面，等等，柜子不也是這樣嗎？為什么我們看到柜子，不會(huì)認(rèn)為是桌子呢？即使我們放在柜子上吃飯，我們看到仍然會(huì)問，為什么在柜子上吃飯？ 不會(huì)叫桌子。如果明白了上面的道理，就很簡(jiǎn)單了，桌子實(shí)際上是為了解決人坐在椅子上，手還能夠支撐在一個(gè)平面上繼續(xù)開展活動(dòng)的問題，一般會(huì)和椅子配對(duì)出現(xiàn)。坐在椅子上工作，對(duì)著柜子有一個(gè)很嚴(yán)重的問題–不知道大家試過沒有–就是腿無法展開的問題。當(dāng)這么坐著超過半小時(shí)就知道是什么痛苦了。所以桌子的平面下方一定會(huì)有一個(gè)足夠容納膝部和小腿的空間，來解決這個(gè)問題。解決了這些問題的裝置，才能稱之為桌子。 類似也可以定義出來椅子，由此可見，桌子和椅子的高度也是有限定的，都是是解決人的問題，要符合人的身高：椅子的高度和深度，必須符合小腿和大腿的長(zhǎng)度；椅背的高度要配合脊柱的高度；桌子的高度要配合小腿和脊柱的高度之和；成人和小孩的自然也就有區(qū)別了。這又變成生理學(xué)了，事實(shí)上要做好桌子和椅子，必須要理解人的生理結(jié)構(gòu)，才能正確的理解桌子和椅子的概念。 同理，為何我們可以在不同的語(yǔ)言間進(jìn)行翻譯，是因?yàn)殡m然語(yǔ)言不同，但是人類所面臨的的問題是一樣的，所使用的名不同而已。對(duì)于不同的動(dòng)物之間的翻譯也是同理。 關(guān)于抽象在討論桌子這個(gè)概念的過程中，很多人會(huì)提出抽象這個(gè)概念，認(rèn)為定義桌子實(shí)際上就是抽象的一個(gè)過程。這里，我覺得有必要要澄清一下抽象這個(gè)概念，我認(rèn)為這個(gè)里面有誤解。我注意到，在做架構(gòu)師的群體中，不談抽象好像就不是一個(gè)合格的架構(gòu)師。 抽象這個(gè)詞代表的含義，實(shí)際上是把不同的概念的相似的部分合并在一起，形成一個(gè)新的概念。這個(gè)里面問題很多：首先“相似的部分”在不同的人看來，并不一定那么相似；其次，抽象之后形成的是一個(gè)新的概念，和原來那個(gè)概念并不一樣，所解決的問題也不一樣。所以我們不能用抽象來定義一個(gè)事物，抽象實(shí)際上是一個(gè)分類的過程，完全是另一碼事。再舉一個(gè)例子，杯子和容器，很多人認(rèn)為容器是杯子的抽象，但是實(shí)際上杯子是杯子，容器是容器，它們所解決的問題是不一樣的。當(dāng)我們需要解決裝東西的問題的時(shí)候，會(huì)說容器；當(dāng)我們需要解決單手持握要裝東西的時(shí)候，會(huì)說要一個(gè)杯子。 回過頭來，根據(jù)架構(gòu)的定義，要做好架構(gòu)所首先必須具備的能力，就是能夠正確的認(rèn)識(shí)概念，能夠發(fā)現(xiàn)概念背后所代表的問題，進(jìn)而才能夠認(rèn)識(shí)目標(biāo)領(lǐng)域所需要解決的問題，這樣才能夠?yàn)樽龊眉軜?gòu)打好基礎(chǔ)。事實(shí)上，這一能力，在任何一個(gè)領(lǐng)域都是適用的，比如我們?nèi)绻胍獙W(xué)習(xí)一項(xiàng)新的技術(shù)，如Hibernate、Spring、PhotoShop、WWW、Internet等等，如果知道這些概念所要解決的問題，學(xué)習(xí)這些新的技術(shù)或者概念就會(huì)如虎添翼，快速的入手；學(xué)習(xí)一個(gè)新的領(lǐng)域，也會(huì)非常的快速有效；使用這些概念來解釋問題，甚至發(fā)明新的概念都是很容易的事。為什么強(qiáng)調(diào)這個(gè)呢，因?yàn)樽黾軜?gòu)的時(shí)候，很多時(shí)候都是在一個(gè)新的領(lǐng)域解決問題，必須要快速進(jìn)入并掌握這個(gè)領(lǐng)域，然后才能夠正確的解決問題。 以上通過幾個(gè)例子，討論了一下認(rèn)識(shí)概念的誤區(qū)，如何有效的去認(rèn)識(shí)概念，明白概念背后的含義，以及如何利用對(duì)概念的理解，快速的進(jìn)行學(xué)習(xí)。掌握了這些原則，會(huì)有利于幫助我們?cè)诩軜?gòu)階段，快速的識(shí)別和定位問題。 下一篇我們會(huì)來討論一下，如何快速的定位和識(shí)別問題，這是架構(gòu)的起始。

架構(gòu)漫談（三）：如何做好架構(gòu)之識(shí)別問題

本文是漫談架構(gòu)專欄的第三篇。接之前的第二篇，作者將會(huì)討論如何做好架構(gòu)，并根據(jù)實(shí)際經(jīng)驗(yàn)分析如何找出實(shí)際工作中需要解決的問題。 按照之前架構(gòu)的定義，做好架構(gòu)首先需要做的就是識(shí)別出需要解決的問題。一般來說，如果把真正的問題找到，那么問題就已經(jīng)解決了80%了。這個(gè)能力基本上就決定了架構(gòu)師的水平。 那么面對(duì)問題有哪些困難呢? 我們先看一則笑話。女主人公：老公，把袋子里的土豆切一半下鍋。結(jié)果老公是把袋子里的每個(gè)土豆都削了一半，然后下鍋。 當(dāng)然很多人會(huì)說，這個(gè)是溝通問題，然后一笑了之。其實(shí)，出現(xiàn)這個(gè)現(xiàn)象是由于我們大部分時(shí)候過于關(guān)注解決問題，急于完成自己的工作，而不關(guān)心“真正的問題是什么”而造成的。當(dāng)我們?nèi)ソ鉀Q一個(gè)問題的時(shí)候，一定要先把問題搞清楚。這也是我為什么要單獨(dú)寫一篇文章講這個(gè)的原因。去看看軟件開發(fā)工作者的時(shí)間分配也可以看出，大家大部分時(shí)間花在討論解決方案和實(shí)現(xiàn)的細(xì)節(jié)上，基本都不會(huì)花時(shí)間去想“問題是什么”。或者即使想了一點(diǎn)點(diǎn)，也是一閃而過，憑自己的直覺下判斷。只有真正投入思考問題是什么的工程師，才可能會(huì)真正的成長(zhǎng)為架構(gòu)師 以這個(gè)笑話為例，看看在我們處理問題的時(shí)候，都會(huì)犯什么樣的錯(cuò)誤： 被告知要處理一個(gè)問題，但是交過來的實(shí)際上是一個(gè)解決方案，不是問題本身。 被告知要處理一個(gè)問題，直接通過直覺就有了一個(gè)解決方案，馬上考慮解決方案如何落地，或者有幾種解決方案，選哪個(gè)合適。 那么如何識(shí)別問題呢? 所有的概念基本都有一個(gè)很大的問題，就是缺乏主語(yǔ)。而我們大家都心照不宣的忽略這個(gè)主語(yǔ)，溝通的時(shí)候也都以為大家都懂得對(duì)方說的主語(yǔ)是誰(shuí)，結(jié)果大家都一起犯錯(cuò)誤。識(shí)別問題的一個(gè)最大的前提就是要搞清楚：是誰(shuí)的問題。這個(gè)搞清楚了，問題的邊界也就跟著確定了，再去討論問題才有意義。 以上面切土豆的例子來分析： 女主人提出一個(gè)問題，要切土豆下鍋煮。 男主人有一個(gè)問題，女主人交代了自己必須要完成的一個(gè)任務(wù)。 每個(gè)人都是優(yōu)先處理自己的問題，自然就選擇了2，完成了這個(gè)任務(wù)。這也是大部分軟件工程師處理的方式，以自己認(rèn)為對(duì)的方式完成自己的問題，沒什么不對(duì)啊，也難怪能得到我們的共鳴。這個(gè)里面犯的錯(cuò)誤是什么呢? 首先，女主人公提出的實(shí)際上是解決方案，而不是燒土豆這個(gè)問題本身。女主人當(dāng)時(shí)執(zhí)行這個(gè)解決方案可能有困難，就把執(zhí)行解決方案作為一個(gè)任務(wù)，委托給了男主人。 其次，男主人得到了一個(gè)任務(wù)，盡心盡職地把這個(gè)任務(wù)完成了。 最后的結(jié)果是什么呢，每個(gè)人都做了很多工作，每個(gè)人都認(rèn)為自己做的是對(duì)的，因此沒有一個(gè)人對(duì)結(jié)果滿意。因?yàn)檎嬲膯栴}沒有被發(fā)現(xiàn)，自然也就沒有被解決，那么后續(xù)還得收拾殘局，還要繼續(xù)解決問題。事實(shí)上自己的工作并沒有完成，反而更多了。把原因歸結(jié)為溝通問題也是可以的，但對(duì)于解決問題似乎并沒有太多的幫助。因?yàn)橐倪M(jìn)溝通，這也是一個(gè)大問題。搞明白目標(biāo)問題“是誰(shuí)的問題，是什么問題”，當(dāng)然也是需要溝通的。為了幫助自己更快的搞明白，首先要做的事是問正確的問題。架構(gòu)師應(yīng)該問的第一個(gè)正確的問題就是：目標(biāo)問題是誰(shuí)的問題。 當(dāng)我們處理問題的時(shí)候，如果發(fā)現(xiàn)自己正在致力于把自己的工作完成，要馬上警惕起來，因?yàn)檫@樣下去會(huì)演變成沒有ownership的工作態(tài)度。在面對(duì)概念的時(shí)候，也會(huì)不求甚解，最終會(huì)導(dǎo)致沒有真正的理解概念。 作為軟件工程師或者架構(gòu)師，我們大部分時(shí)候是要去解決別人的問題，“別人”是誰(shuí)，是值得好好思考的。在這個(gè)故事里面，男主人要解決的，實(shí)際上是這個(gè)家庭晚餐需要吃土豆的問題，目標(biāo)問題的主體實(shí)際上是這個(gè)家庭的成員。 明白了問題的主體，這個(gè)主體就自然會(huì)帶來很多邊界約束，比如土豆是要吃的，要給人吃的，而且還是要給自己的家人吃的?！扒型炼瓜洛仭边@個(gè)問題，因?yàn)樽R(shí)別了問題的主體，自然而然的就附帶了這么多的信息。后續(xù)如何煮，是否放高壓鍋煮，放多少水，煮多長(zhǎng)時(shí)間等等，就自然而然能夠問出來其他問題來了，說不定還能夠識(shí)別出來，女主人給的這個(gè)解決方案可能是有問題的。這個(gè)時(shí)候才算是真正的明白了問題?？梢韵胂?#xff0c;這樣下去最后的結(jié)果一定是大家都滿意的，因?yàn)檎嬲膯栴}解決了。只有真正明白了是誰(shuí)的問題，才能夠真正地完成自己的任務(wù)，真正地把自己的問題解決掉，而不是反過來。 由上面的分析可以看出，找出問題的主體，是做架構(gòu)的首要問題。這也是我一再?gòu)?qiáng)調(diào)的，我們要解決的問題，一定都是人的問題。更進(jìn)一步，架構(gòu)師要解決的，基本都是別人的問題，不是自己的問題。再進(jìn)一步，我們一定要明白，任何找上架構(gòu)師的問題，絕對(duì)都不是真正的問題。為什么呢? 因?yàn)槿绻钦嬲膯栴}的話，提問題過來的人肯定都能夠自己解決了，不需要找架構(gòu)師。架構(gòu)師都要有這個(gè)自覺：發(fā)現(xiàn)問題永遠(yuǎn)都比解決問題來的更加重要。 當(dāng)問題的主體離架構(gòu)師越遠(yuǎn)，就會(huì)讓找出問題主體的過程越加困難，我們?cè)倥e一個(gè)軟件行業(yè)比較熟悉的例子：用戶給產(chǎn)品經(jīng)理提出要求，想要一把錘子。這是典型的拿解決方案作為問題的。真正的問題的主體是誰(shuí)，是用戶還是設(shè)計(jì)師還是施工隊(duì)? 如果產(chǎn)品經(jīng)理當(dāng)成是自己的問題，那么毫無疑問就給了錘子了。 我們需要識(shí)別：用戶究竟是二傳手，還是問題的真正主體。如果是設(shè)計(jì)師，那么問題的邊界就變成了設(shè)計(jì)師的問題，如果是施工隊(duì)，那么問題就變成了施工隊(duì)的問題，如果是用戶，那么就要看看用戶到底有什么困難，絕對(duì)不是要一個(gè)錘子這么簡(jiǎn)單。這也說明了，問題的主體對(duì)問題的邊界確定有多么的重要。 當(dāng)明白了問題的主體，我們才可能真正的認(rèn)識(shí)問題是什么。因?yàn)閱栴}的主體是問題的隱含邊界，邊界不確定下來，問題就是不確定的。一旦確定了主體，剩下的就是去搞明白主體有哪些問題。這個(gè)就比較直接了，常用的方式就是直接面對(duì)主體進(jìn)行訪談，深入到主體的工作生活當(dāng)中，體驗(yàn)并感受這些問題，甚至通過數(shù)據(jù)的反饋來定位問題。這個(gè)大家就比較熟悉了，我就不展開了。 一般來說，從問題暴露的點(diǎn)，一點(diǎn)點(diǎn)去溯源查找，一定會(huì)找出來誰(shuí)的問題，以及是什么問題。最壞情況就是當(dāng)我們時(shí)間或者能力有限，實(shí)在是無法定位出是誰(shuí)的問題的時(shí)候，比如系統(tǒng)出故障，也就意味著我們無法根本解決問題。這時(shí)最好的辦法就是去降低問題發(fā)生所帶來的成本，盡量去隔離問題影響的范圍。給我留出時(shí)間和空間去識(shí)別真正的問題。 總結(jié)一下，要正確的認(rèn)識(shí)問題，需要問兩個(gè)問題： 這是誰(shuí)的問題？ 有什么問題？ 當(dāng)?shù)玫降幕卮鹗侵е嵛岬臅r(shí)候，我們就知道正確的方向在哪兒，以及需要做哪些事了。以我的經(jīng)驗(yàn)，問題1會(huì)花比較多的時(shí)間，也是支支吾吾最多的地方，因?yàn)榧軜?gòu)要解決的問題都是人的問題。但是一旦確定了答案，問題2就會(huì)變得非常容易。可以這樣說，架構(gòu)師的能力大部分會(huì)體現(xiàn)在問題1的識(shí)別上。

架構(gòu)漫談（四）：如何做好架構(gòu)之架構(gòu)切分

本文是漫談架構(gòu)專欄的第四篇，作者將會(huì)介紹架構(gòu)的切分，并直戳切分的本質(zhì)其實(shí)就是利益的調(diào)整。文中作者將會(huì)討論為什么需要切分、切分的原則、切分與建模、切分的輸出和組織架構(gòu)等問題。歡迎閱讀和反饋。 前一篇（點(diǎn)擊文末閱讀原文鏈接查看）已經(jīng)講了如何識(shí)別問題。在識(shí)別出是誰(shuí)的問題之后，會(huì)發(fā)現(xiàn)，在大部分情況下，問題都迎刃而解，不需要做額外的動(dòng)作。很多時(shí)候問題的產(chǎn)生都是因?yàn)闇贤ǖ恼`解，或者主觀上有很多不必要的利益訴求導(dǎo)致的。但是總還有一部分確實(shí)是有問題的，需要做調(diào)整，那么就必須要有所動(dòng)作，做相應(yīng)的調(diào)整。這個(gè)調(diào)整就是架構(gòu)的切分。 切分就是利益的調(diào)整我們要非常的清楚，所有的切分調(diào)整，都是對(duì)相關(guān)人的利益的調(diào)整。為什么這么說呢，因?yàn)榫S護(hù)自己的利益，是每個(gè)人的本性，是在骨子里面的，我們不能逃避這一點(diǎn)。我們以第一篇文章里面的例子為例來做解釋。 我們已經(jīng)知道，隨著社會(huì)的發(fā)展，分工是必然的，為什么呢?這個(gè)背后的動(dòng)力就是每個(gè)人自己的利益。每個(gè)人都希望能夠把自己的利益最大化，比如：生活的更舒適，更輕松，更安全，占用并享有更多的東西。但是每個(gè)人的能力和時(shí)間都非常的有限，不可能什么都懂，所以自然需要舍掉一些自己不擅長(zhǎng)的東西，用自己擅長(zhǎng)的東西去換取別人擅長(zhǎng)的東西。 對(duì)比一個(gè)人干所有的事情，結(jié)果就是大家都能夠得到更多，當(dāng)然也產(chǎn)生了一個(gè)互相依賴的社會(huì)，互相誰(shuí)都離不開誰(shuí)。這就是自然而然而產(chǎn)生的架構(gòu)切分，背后的原動(dòng)力就是人們對(duì)自己利益的渴望。人們對(duì)自己利益的渴望也是推動(dòng)社會(huì)物質(zhì)發(fā)展的原動(dòng)力。 在這個(gè)模式下，比較有意思的是，每個(gè)人必須要舍掉自己的東西，才能夠得到更多的東西。有些人不愿意和別人進(jìn)行交換，不想去依賴于別人，這些人的生活就很明顯的差很多，也辛苦很多，自然而然的就被社會(huì)淘汰了。如果需要在這個(gè)社會(huì)上立足，判斷標(biāo)準(zhǔn)就變成了：如何給這個(gè)社會(huì)提供更好更有質(zhì)量的服務(wù)。提供的更好更多的服務(wù)，自然就能夠換取更多更好的生活必需品。實(shí)際上這就是我們做人的道理。 為什么需要切分？當(dāng)人們認(rèn)識(shí)到要主動(dòng)的去切分一個(gè)系統(tǒng)的時(shí)候，毫無疑問，我們不能忘掉利益這個(gè)原動(dòng)力。所有的切分決策都不能夠違背這一點(diǎn)，這是大方向。結(jié)合前一篇“識(shí)別問題”，一旦確定了問題的主體，那么系統(tǒng)的利益相關(guān)人（用現(xiàn)代管理學(xué)語(yǔ)言叫：stakeholder）就確定了下來。所發(fā)現(xiàn)的問題，會(huì)有幾種情況： 某個(gè)或者某些利益相關(guān)人負(fù)載太重。 時(shí)間上的負(fù)載太重。 空間上的負(fù)載太重，本質(zhì)上還是時(shí)間上的負(fù)載太重。 某個(gè)或者某些利益相關(guān)人的權(quán)利和義務(wù)不對(duì)等。 切分的原則情況1是切分的原因，情況2是切分不合理而導(dǎo)致的新的問題，最終還是要回到情況1。對(duì)于情況1，本質(zhì)上都是時(shí)間上的負(fù)載。因?yàn)槊總€(gè)人的時(shí)間是有限的，怎么在有限的時(shí)間內(nèi)做出更多的事情？那么只有把時(shí)間上連續(xù)的動(dòng)作，切分成時(shí)間上可以并行的動(dòng)作，在空間上橫向擴(kuò)展。所以切分就要有幾個(gè)原則： 必須在連續(xù)時(shí)間內(nèi)發(fā)生的一個(gè)活動(dòng)，不能切分。比如孕婦懷孕，必須要10月懷胎，不能夠切成10個(gè)人一個(gè)月完成。 切分出來的部分的負(fù)責(zé)人，對(duì)這個(gè)部分的權(quán)利和義務(wù)必須是對(duì)等的。比方說媽媽10月懷胎，媽媽有權(quán)利處置小孩的出生和撫養(yǎng)，同樣也對(duì)小孩的出生和撫養(yǎng)負(fù)責(zé)。為什么必須是這樣呢? 因?yàn)槿绻麢?quán)利和義務(wù)是不對(duì)等的話，會(huì)傷害每個(gè)個(gè)體的利益，分出來執(zhí)行的效率會(huì)比沒有分出來還要低，實(shí)際上也損害了整體的利益，這違背了提升整體利益的初衷。 切分出來的部分，不應(yīng)該超出一個(gè)自然人的負(fù)載。當(dāng)然對(duì)于每個(gè)人的能力不同，負(fù)載能力也不一樣，需要不斷的根據(jù)實(shí)際情況調(diào)整，這實(shí)際上就是運(yùn)營(yíng)。 切分是內(nèi)部活動(dòng)，內(nèi)部無任怎么切，對(duì)整個(gè)系統(tǒng)的外部應(yīng)該是透明的。如果因?yàn)榍蟹謱?dǎo)致整個(gè)系統(tǒng)解決的問題發(fā)生了變化，那么這個(gè)變化不屬于架構(gòu)的活動(dòng)。當(dāng)然很多時(shí)候當(dāng)我們把問題分析的比較清楚的時(shí)候，整個(gè)系統(tǒng)的邊界會(huì)進(jìn)一步的完善，這就會(huì)形成螺旋式的進(jìn)化。但這不屬于架構(gòu)所應(yīng)該解決的問題。進(jìn)化的發(fā)生，也會(huì)導(dǎo)致新的架構(gòu)的切分。 原則2是確保我們不能違反人性，因?yàn)榫S護(hù)自己的利益，是每個(gè)人的本性。只有權(quán)利和義務(wù)對(duì)等才能做到這一點(diǎn)。從原則2的也可以推理，所有的架構(gòu)分拆，都應(yīng)該是形成樹狀的結(jié)果，不應(yīng)該變成有向圖，更不應(yīng)該是無向圖。很多人一談架構(gòu)，必談分層，但是基本上都沒意識(shí)到，是因?yàn)榘岩粋€(gè)整體分拆為了一棵樹，因?yàn)橛辛藰?#xff0c;才有層。 從某種意義上來說，談架構(gòu)就是談分層，似乎也沒有錯(cuò)，但是還是知道為什么比較好。從根節(jié)點(diǎn)下來，深度相同的是同一層。這個(gè)是數(shù)學(xué)概念，我就不展開了，感興趣可以去復(fù)習(xí)一下數(shù)學(xué)。 同樣我們看一個(gè)組織架構(gòu)，也可以做一個(gè)粗略的判斷，如果一個(gè)企業(yè)的組織架構(gòu)出現(xiàn)了“圖”，比方說多線匯報(bào)，一定是對(duì)stakeholder的利益分析出現(xiàn)了問題，這就會(huì)導(dǎo)致問題2的發(fā)生。問題2一旦出現(xiàn)，我們必須馬上要意識(shí)到，如果這個(gè)問題持續(xù)時(shí)間長(zhǎng)，會(huì)極大的降低企業(yè)的運(yùn)作效率，對(duì)相關(guān)stakeholder的利益都是非常不利的，同樣對(duì)于企業(yè)的利益也是不利的。必須快速調(diào)整相關(guān)stakeholder的職責(zé)，使得企業(yè)的組織架構(gòu)成為一個(gè)完美的樹狀，并且使得數(shù)的層數(shù)達(dá)到盡可能的低。只有平衡數(shù)可以比較好的達(dá)到這個(gè)效果。 當(dāng)然如果某個(gè)節(jié)點(diǎn)的能力很強(qiáng)，也可以達(dá)到減小樹的高度的結(jié)果。技術(shù)的提升，也是可以提升每個(gè)節(jié)點(diǎn)的能力，降低樹的層數(shù)。很多管理學(xué)都在討論如何降低組織架構(gòu)的層數(shù)，使得管理能夠扁平化，原因就在于此，這里就不展開討論了。從這里也基本可以得出一個(gè)結(jié)論，一個(gè)好的組織的領(lǐng)導(dǎo)，一定也是一個(gè)很好的架構(gòu)師。 切分與建模實(shí)際上切分的過程就是建模的過程，每次對(duì)大問題的切分都會(huì)生成很多小問題，每個(gè)小問題就形成了不同的概念。這也是系列第二篇文章嘗試表達(dá)的。這些不同的概念大部分時(shí)候人們自發(fā)的已經(jīng)建好了，架構(gòu)師更多的是要去理解這些概念，識(shí)別概念背后所代表的的人的利益。比如人類社會(huì)按照家庭進(jìn)行延續(xù)，形成了家族，由于共享一片土地資源，慢慢形成了村莊，村莊聯(lián)合體，不同地域結(jié)合，形成了國(guó)家。由于利益分配的原因，形成了政權(quán)。每次政權(quán)的更迭，都是利益重新分配的動(dòng)力所決定的。 同樣對(duì)于一個(gè)企業(yè)也是一樣的，一開始一個(gè)人干所有的事情。當(dāng)業(yè)務(wù)量逐漸變大，就超過了一個(gè)人能夠處理容量，這些內(nèi)容就會(huì)被分解出來，開始招聘人進(jìn)來，把他們組合在一起，幫助處理企業(yè)的事務(wù)。整個(gè)企業(yè)的事務(wù)，就按照原則2，分出來了很多新的概念：營(yíng)銷，售前，售中，售后，財(cái)務(wù)，HR等等。企業(yè)的創(chuàng)始人的工作就變成了如何組合這些不同的概念完成企業(yè)的工作。如果業(yè)務(wù)再繼續(xù)增大，這些分出來的部分還要繼續(xù)分拆，仍然要按照原則2才能夠讓各方達(dá)到利益最大化。如果某個(gè)技術(shù)的提升，提高了某個(gè)角色的生產(chǎn)力，使得某個(gè)角色可以同時(shí)在承擔(dān)更多的工作，就會(huì)導(dǎo)致職責(zé)的合并，降低樹的層數(shù)。 切分的輸出和組織架構(gòu)架構(gòu)切分的輸出實(shí)際上就是一個(gè)系統(tǒng)的模型，對(duì)于一個(gè)整體問題，有多少的相關(guān)方，每個(gè)相關(guān)方需要承擔(dān)哪些權(quán)利和義務(wù)，不同的相關(guān)方是如何結(jié)合起來完成系統(tǒng)的整體任務(wù)的。有的時(shí)候是從上往下切（企業(yè)），有的時(shí)候是從下往上合并，有的時(shí)候兩者皆有之（人類社會(huì)的發(fā)展）。而切分的結(jié)果最終都會(huì)體現(xiàn)在組織架構(gòu)上，因?yàn)槲覀兦蟹值膶?shí)際上就是人的利益。 從這方面也可以看出，任何架構(gòu)調(diào)整都會(huì)涉及到組織架構(gòu)，千萬(wàn)不可輕視。同樣，如果對(duì)于stakeholder的利益分析不夠透徹，也會(huì)導(dǎo)致架構(gòu)無法落地，因?yàn)闆]有入愿意去損壞自己的利益。一旦強(qiáng)制去執(zhí)行，人心就開始潰散。這個(gè)也不一定是壞事，只要滿足原則2就能夠很好的建立一個(gè)新的次序和新的利益關(guān)系，保持組織的良性發(fā)展，長(zhǎng)久來看是對(duì)所有人的利益都有益的，雖然短期內(nèi)有對(duì)某些既得利益者會(huì)有損害。 總結(jié)一下： 架構(gòu)的切分的導(dǎo)火索是人的負(fù)載太重。 架構(gòu)的切分實(shí)際就是對(duì)stakeholder的利益進(jìn)行切分或合并，使得每個(gè)stakeholder的權(quán)責(zé)是對(duì)等的，每個(gè)stakeholder可以為自己的利益負(fù)責(zé)。 架構(gòu)切分的最終結(jié)果都會(huì)體現(xiàn)在組織架構(gòu)上，只有這樣才能夠讓架構(gòu)落地并推進(jìn)。 架構(gòu)切分的結(jié)果一定是一個(gè)樹狀，這也是為什么會(huì)產(chǎn)生分層。層數(shù)越多溝通越多，效率越低，分層要越少越好。盡可能變成一顆平衡樹，才能讓整個(gè)系統(tǒng)的效率最大化。

架構(gòu)漫談（五）：什么是軟件

本文是漫談架構(gòu)專欄的第五篇，作者將會(huì)從自己的認(rèn)知角度再次反思什么是軟件，文中作者探討了軟件發(fā)展火熱的根本原因以及軟件扮演的角色等問題。如前幾天一位架構(gòu)師所說，我們并不缺架構(gòu)實(shí)踐，而是缺少對(duì)于架構(gòu)的反思，希望這系列文章能幫你重新理解架構(gòu)，重新認(rèn)識(shí)軟件。 方式三，貨幣直接補(bǔ)償；對(duì)已有住房保障而不需要安置住房、且本人自愿的棚戶區(qū)改造居民，直接給予貨幣補(bǔ)償（圖8）。��域內(nèi)同類商品房的平均市價(jià)（圖7）；��6）；??考，并應(yīng)用到自己所在的領(lǐng)域中。在這篇文章開始，我們用同樣的思考，來看看軟件是怎么回事，以及如何運(yùn)用架構(gòu)思維，更好的設(shè)計(jì)和實(shí)現(xiàn)軟件。 http://y2.ifengimg.com/a/2015_49/651557e4e3330d4.jpg52.jpg??實(shí)際上可以說是用機(jī)器模擬人的歷史。不管大家（包括在這個(gè)歷史過程中的參與者）有沒有意識(shí)到，我們都有意無意的在計(jì)算機(jī)上模仿人類的行為。從馮諾依曼結(jié)構(gòu)開始，程序邏輯開始脫離硬件，采用二進(jìn)制編碼。加上存儲(chǔ)，配合輸入輸出，一個(gè)簡(jiǎn)化的大腦就出現(xiàn)了。圖靈機(jī)則是模擬大腦的計(jì)算，用數(shù)學(xué)的方式把計(jì)算的過程定義了出來，著名的邱奇-圖靈論題：一切直覺上能行可計(jì)算的函數(shù)都可用圖靈機(jī)計(jì)算，反之亦然。軟硬件兩者一結(jié)合，一個(gè)可編程的大腦出現(xiàn)了，這也是現(xiàn)在為什么我們把計(jì)算機(jī)叫做電腦。在硬件上編寫出的程序，就是軟件，是用來控制硬件的行為的。 第二，對(duì)存量房的利用能夠滿足被拆遷人多樣化的住房需求。實(shí)物安置通常由安置房承建方根據(jù)被拆遷房屋群的面積統(tǒng)一設(shè)計(jì)若干標(biāo)準(zhǔn)戶型，被拆遷人選擇安置房時(shí)一般根據(jù)被拆遷房屋的面積上靠標(biāo)準(zhǔn)戶型。而選擇貨幣安置的被拆遷人在獲得貨幣安置款后，可以在市場(chǎng)上選擇區(qū)位、面積、設(shè)計(jì)等更加貼近自身需求的住房。��的語(yǔ)言的高級(jí)語(yǔ)言，比如C/C++/Java等，這使得人類可以用類似于人的語(yǔ)言來和計(jì)算機(jī)溝通。軟件工程師慢慢越來越多，開發(fā)軟件的成本也越來越低。計(jì)算機(jī)就好像是一個(gè)只需要電，不需要休息的人，可以無休無止的工作。 （1） 貨幣化安置之錢從哪里來？�做的事情，交給計(jì)算機(jī)來做。結(jié)果就導(dǎo)致軟件越來越豐富，能夠做的事情也越來越多，成本也越來越低?？梢赃@么說，成本是我們?yōu)槭裁床捎密浖闹饕獎(jiǎng)恿?#xff0c;可以節(jié)省大量的人員培訓(xùn)，減少雇員的數(shù)目。隨著互聯(lián)網(wǎng)的發(fā)展，人類社會(huì)也開始軟件化了。原來必須實(shí)體店來進(jìn)行售賣的，搬到互聯(lián)網(wǎng)上，開店成本更低，并且能夠接觸到更多的人。想象一下，一個(gè)門店每天的人流達(dá)到百萬(wàn)級(jí)別是很恐怖的，由實(shí)體空間大小來決定。但是在互聯(lián)網(wǎng)上，訪問量千萬(wàn)級(jí)別都不算什么。最終的結(jié)果就變成，每個(gè)人能夠負(fù)擔(dān)的工作越來越多，成本越來越低。這也是為什么軟件這么熱的原因。 軟件扮演的角色隨著軟件的規(guī)模的變大，做好一個(gè)軟件也變得越來越難了。早期的程序員寫程序，主要是為了幫助自己研究課題。這些程序員熟練了之后，提高了自己的生產(chǎn)力，并發(fā)現(xiàn)還可以幫助別人寫程序，慢慢軟件就變成了一個(gè)獨(dú)立的行業(yè)。程序從早期由一個(gè)人完成，也逐漸變成了由很多不同角色的人共同合作來完成。以下討論的前提，都是基于幫助別人寫程序，多人合作的基礎(chǔ)上的。結(jié)論對(duì)于單人為自己寫程序也適用。 總體而言，棚改貨幣化安置的資金由央行通過PSL提供給國(guó)開行，國(guó)開行向各省省級(jí)融資平臺(tái)貸款后，省級(jí)平臺(tái)轉(zhuǎn)貸給 有了軟件之后，實(shí)際上，我們是把我們?nèi)粘Ｉ钪兴龅氖虑?#xff0c;包括我們自己本人都一起虛擬化到了計(jì)算機(jī)中。而人則演化成了，通過計(jì)算機(jī)的輸入輸出設(shè)備，控制計(jì)算機(jī)中的自己，來完成日常的工作，以及與其他人的溝通。也就是說，軟件一直以來的動(dòng)力，始終都是來模擬人和這個(gè)社會(huì)的。比如模擬大氣運(yùn)動(dòng)（天氣預(yù)報(bào)），模擬人類社會(huì)（互聯(lián)網(wǎng)社交），模擬交易，包括現(xiàn)在正在流行的VR，人工智能等等。模擬的對(duì)象越來越高級(jí)，難度越來越大。 三、貨幣化安置能在多大程度上緩解商品房庫(kù)存壓力？也就是說，軟件的主要目的，還是把人類的生活模擬化，提供更低成本，高效率的新的生活。從這個(gè)角度來看，軟件主要依賴的還是人類的生活知識(shí)。軟件更多的是扮演一個(gè)cost center，這也是為什么會(huì)出現(xiàn)很多的軟件代工。 軟件開發(fā)的架構(gòu)演變軟件工程師是實(shí)現(xiàn)這個(gè)模擬過程的關(guān)鍵人物，他必須先理解人是怎么在日常生活中完成工作的，才能夠很好的把這些工作在計(jì)算機(jī)中模擬出來?？墒擒浖こ處熜枰獙W(xué)習(xí)大量的計(jì)算機(jī)語(yǔ)言和計(jì)算機(jī)知識(shí)，還需要學(xué)習(xí)各行各業(yè)的專業(yè)知識(shí)。軟件工程師本身的培養(yǎng)就比較難，同時(shí)行業(yè)知識(shí)也要靠時(shí)間的積累，這樣就遠(yuǎn)遠(yuǎn)超出了軟件工程師的能力了。所以軟件開發(fā)就開始有分工了，行業(yè)知識(shí)和業(yè)務(wù)的識(shí)別，會(huì)交給BA，系統(tǒng)的設(shè)計(jì)會(huì)交給架構(gòu)師，設(shè)計(jì)的實(shí)現(xiàn)交給架構(gòu)師，實(shí)現(xiàn)的檢驗(yàn)交給測(cè)試，還有很多其他角色的配合。為了組織這些角色的工作，還有項(xiàng)目經(jīng)理。這就把原來一個(gè)人的連續(xù)工作，拆分成了不同角色的人的連續(xù)配合，演化成了不同的軟件開發(fā)的模式。然后慢慢演變出專門為別人開發(fā)軟件的軟件公司。 軟件架構(gòu)的出現(xiàn)如同前面描述的架構(gòu)的定義，軟件架構(gòu)的出現(xiàn)也是同樣的。一開始是懵懵懂懂的去寫軟件，后來慢慢的就有意識(shí)的去切分，演變成了不同的架構(gòu)。這個(gè)背后的動(dòng)力也是一樣的，就是提升參與的人的利益，降低成本。導(dǎo)火索也是軟件工程師的任務(wù)太重，我們需要把很多工作拆分出來。拆分的原則也是一樣的，如何讓權(quán)責(zé)一致。同樣，這個(gè)拆分也是需要組織架構(gòu)的調(diào)整，來保證架構(gòu)的落地。具體如何分拆，如何調(diào)整，我們將在另外一篇中著重討論。 以上通過簡(jiǎn)�y0.ifengimg.com/�和軟件的發(fā)展歷史，闡明軟件的本質(zhì)，其實(shí)就是通過把人類的日常工作生活虛擬化，減少成本，提升單個(gè)人員的生產(chǎn)力，提升人類自己的利益。軟件工程師的職責(zé)在這個(gè)浪潮中，不堪重負(fù)，自然而然就分拆為不同的角色，形成了一個(gè)獨(dú)特的架構(gòu)體系。這一切的背后，仍然是為了提升人類自己的利益，解決人類自己的問題。

架構(gòu)漫談（六）：軟件架構(gòu)到底是要解決什么問題？

本文是漫談架構(gòu)專欄的第六篇，作者Kevin繼續(xù)沿著前幾篇文章的思路，探討了軟件架構(gòu)為什么要有軟件架構(gòu)，進(jìn)而再去解釋什么是軟件架構(gòu)。這和最近網(wǎng)上瘋傳的黃金圓環(huán)（Why-How-What）思路非常貼合。 前一篇文章簡(jiǎn)述了什么是軟件。那么什么是軟件架構(gòu)呢？按照慣例，我們來看看是什么問題，是誰(shuí)的問題。 要解決誰(shuí)的問題？如前所述，軟件實(shí)際上就是把現(xiàn)實(shí)生活模擬到計(jì)算機(jī)中，并且軟件是需要在計(jì)算機(jī)的硬件中運(yùn)行起來的。要做到這一點(diǎn)需要解決兩個(gè)問題： 一、業(yè)務(wù)問題 具體的現(xiàn)實(shí)生活狀態(tài)下，沒有軟件的時(shí)候，所解決的問題的主體是誰(shuí)，解決的是什么問題，是如何解決，如何運(yùn)作的？ 二、計(jì)算機(jī)問題 如何把現(xiàn)實(shí)生活用軟件來模擬？ 模擬出來的軟件，需要哪些硬件設(shè)施才能夠滿足要求？ 并且當(dāng)訪問量越來越大的時(shí)候，軟件能否支持硬件慢慢長(zhǎng)大，性能線性擴(kuò)展？ 因?yàn)橛布强赡軙?huì)失效的，軟件如何在硬件失效的情況下，仍然能夠保證可用性，讓用戶能夠不中斷的訪問軟件提供的服務(wù)？ 怎么收集軟件產(chǎn)生的數(shù)據(jù)，為下一階段的工作提供依據(jù)？ 分別是誰(shuí)的問題呢？業(yè)務(wù)的owner需要提升業(yè)務(wù)的效率，降低業(yè)務(wù)的成本，這是動(dòng)機(jī)。這個(gè)實(shí)際上就是業(yè)務(wù)的問題，所以一般軟件開發(fā)的出發(fā)點(diǎn)就在這里。 是軟件工程師的問題，要解決業(yè)務(wù)owner把業(yè)務(wù)虛擬化的問題，并且要解決軟件開發(fā)和運(yùn)營(yíng)的生命周期的問題。 分別有什么問題？業(yè)務(wù)問題的本質(zhì)，是業(yè)務(wù)所服務(wù)的對(duì)象的利益問題，明白了這個(gè)，就很容易搞清業(yè)務(wù)的概念和組織方式。再次強(qiáng)調(diào)一下，有了軟件，可以降低業(yè)務(wù)的成本，沒有軟件的情況下，業(yè)務(wù)是一樣跑的。如果只是為了跟風(fēng)要用軟件，說不定反而提高了成本，這個(gè)是采用軟件之前首先要先搞清楚的。我們經(jīng)常說軟件和技術(shù)是業(yè)務(wù)的enabler，實(shí)際就是把原來成本很高的降到到了很低的程度而已，并不是有了什么新的業(yè)務(wù)。另外軟件也不是降低業(yè)務(wù)成本的唯一方式。 為了能夠讓軟件很好的跑起來，軟件工程師必須理解業(yè)務(wù)所服務(wù)的對(duì)象，他們的利益所在，即業(yè)務(wù)問題。業(yè)務(wù)面對(duì)這些問題是如何分拆解決的？ 涉及到了哪些概念？ 這些概念分別解決了哪些哪些問題？ 我們不能自己按照自己的理解，用自己的一套概念體系來表述。如果這么做的話，會(huì)導(dǎo)致兩個(gè)問題： 業(yè)務(wù)無法和我們交流，因?yàn)樗麄儫o法明白我們所自己創(chuàng)建的概念，所以他們無法確認(rèn)我們的理解是否正確。 我們所表述的東西，并沒有在實(shí)際生活中實(shí)踐過，我們也不知道這些概念是否能夠解決業(yè)務(wù)的問題。 軟件工程師還必須要考慮，用什么樣的硬件把軟件跑起來，怎樣跑得好，跑得快，并且可以隨著業(yè)務(wù)的流量逐漸的長(zhǎng)大？ 分析問題對(duì)于2，在有限的時(shí)間下，軟件工程師毫無疑問無法一個(gè)人去完成這么多事情，那么我們需要把所做的事情列出來，進(jìn)行分析。 一、虛擬化業(yè)務(wù)需要完成這些事情： 學(xué)習(xí)業(yè)務(wù)知識(shí)，認(rèn)識(shí)業(yè)務(wù)所涉及的stakeholders的核心利益述求，以及業(yè)務(wù)是如何分拆滿足這些利益述求，并通過怎樣的組織架構(gòu)完成整個(gè)組織的核心利益的，以及業(yè)務(wù)運(yùn)作的流程，涉及到哪些概念，有哪些權(quán)利和責(zé)任等。 通過對(duì)業(yè)務(wù)知識(shí)的學(xué)習(xí)，針對(duì)這些概念所對(duì)應(yīng)的權(quán)利和責(zé)任以及組織架構(gòu)，對(duì)業(yè)務(wù)進(jìn)行建模，把并把建模的結(jié)果用編程語(yǔ)言實(shí)現(xiàn)。這是業(yè)務(wù)的模型，通常是現(xiàn)實(shí)生活中利益斗爭(zhēng)的結(jié)果，是非常穩(wěn)定的。 學(xué)習(xí)業(yè)務(wù)所參與的stakeholder是如何和業(yè)務(wù)打交道，并完成每個(gè)人的權(quán)利和義務(wù)的，并通過編程語(yǔ)言，結(jié)合業(yè)務(wù)模型實(shí)現(xiàn)這些打交道的溝通通道。這部分是變化最頻繁的，屬于組合關(guān)系。明白了這一點(diǎn)，對(duì)后續(xù)的實(shí)現(xiàn)非常有幫助。 如何把業(yè)務(wù)運(yùn)行的結(jié)果，持久化，并通過合適的手段把持久化后的數(shù)據(jù)，在合適的時(shí)間合適的地點(diǎn)加載出來。這部分和基礎(chǔ)設(shè)施有關(guān)，變化可能也會(huì)比較頻繁。 二、代碼如何運(yùn)營(yíng)，需要完成這些事情： 需要多少硬件設(shè)備來滿足訪問的需求？ 代碼要分成多少個(gè)組件部署到哪些硬件設(shè)備上？ 這些代碼如何通過硬件設(shè)備互相連接在一起？ 當(dāng)業(yè)務(wù)流量增大到超過一臺(tái)機(jī)器的容量時(shí)，軟件能否支持通過部署到新增機(jī)器上的方式，擴(kuò)大對(duì)業(yè)務(wù)的支撐？ 當(dāng)某臺(tái)或某些硬件設(shè)備失效時(shí)，軟件是否仍然能夠不影響用戶的訪問。 軟件運(yùn)行產(chǎn)生的數(shù)據(jù)，能否支持提取出來并加以分析，為下一輪的業(yè)務(wù)決策提供依據(jù)。 三、如果分成不同的角色來完成這些事情，就需要一個(gè)組織架構(gòu)來組織代碼的編寫和運(yùn)營(yíng)，需要做哪些事情： 完成一和二所列的這些事情，需要哪些角色參與？ 這些事情基本都需要順序的發(fā)生，如何保證信息在不同角色的傳遞過程中不會(huì)有損失？ 或者說即使有損失，也能快速糾正？ 這些角色之間是如何協(xié)調(diào)，才能共同完成虛擬化業(yè)務(wù)的需求？ 會(huì)生成哪些架構(gòu) 如果業(yè)務(wù)足夠簡(jiǎn)單，用戶流量夠小，時(shí)間要求也不急迫，那么一個(gè)人，一臺(tái)機(jī)器就夠了，這個(gè)時(shí)候一般不會(huì)去討論架構(gòu)的問題。當(dāng)訪問的流量越來越大，機(jī)器就會(huì)越來越多，代碼的部署單元就會(huì)拆分的越來越多。 同樣就會(huì)需要越來越多的人來完成拆分出來的越來越多的部署單元，甚至同一個(gè)部署單元也需要分拆為多人合作完成。但是我們需要注意到一點(diǎn)，整個(gè)的概念體系，或者說業(yè)務(wù)的建模不會(huì)有任何的變化，還是完成同樣的這些事情。唯一的區(qū)別就是量越來越大，超過了單個(gè)人和單個(gè)機(jī)器的容量，不斷地增長(zhǎng)。這樣就會(huì)導(dǎo)致以下的架構(gòu)： 當(dāng)流量越來越大，我們就會(huì)發(fā)現(xiàn)，軟件所部屬的機(jī)器就會(huì)開始按照樹狀的結(jié)構(gòu)開始分拆，就會(huì)形成硬件的部屬架構(gòu)。這就是為什么會(huì)形成部署的分層。 為了把業(yè)務(wù)在軟件中實(shí)現(xiàn)并落地，需要前端人員、業(yè)務(wù)代碼人員、存儲(chǔ)層等不同技巧的人同時(shí)工作，需要切分成代碼的架構(gòu)。這就是為什么會(huì)形成代碼的分層，形成代碼的架構(gòu)。當(dāng)然，當(dāng)這些角色由一個(gè)人來完成的時(shí)候，不一定會(huì)有代碼架構(gòu)，往往會(huì)比較亂。 當(dāng)參與的人員越來越多，就會(huì)形成開發(fā)體系的組織架構(gòu)。因?yàn)榇a開發(fā)的過程是一個(gè)連續(xù)的過程，會(huì)用流程來吧不同的角色串聯(lián)起來，這就是軟件工程。 為了完成業(yè)務(wù)的工作，需要識(shí)別出來業(yè)務(wù)架構(gòu)和支撐業(yè)務(wù)的組織架構(gòu)，以及業(yè)務(wù)運(yùn)作的流程。這是被虛擬化的業(yè)務(wù)架構(gòu)和組織架構(gòu)，也需要體現(xiàn)在代碼中，保持和現(xiàn)實(shí)生活中一致。 什么是軟件架構(gòu)這就是軟件比較復(fù)雜的地方，涉及到軟件本身的業(yè)務(wù)體系，和所虛擬的業(yè)務(wù)體系。根據(jù)以上的分析，所生成的架構(gòu)，究竟那些算是軟件架構(gòu)呢？ 軟件因?yàn)榱髁吭龃蠖植鸪刹煌倪\(yùn)行單元，在不同的機(jī)器上部署所形成的架構(gòu)，屬于軟件架構(gòu)。 每個(gè)運(yùn)行單元為了讓不同角色的人，比如前端，業(yè)務(wù)，數(shù)據(jù)存儲(chǔ)等能夠并行工作，所分成的代碼架構(gòu)，也屬于軟件架構(gòu)。 所以當(dāng)我們說軟件架構(gòu)的時(shí)候，我們一定要講清楚，究竟說的是部署的架構(gòu)，還是代碼的架構(gòu)。軟件架構(gòu)的落地，需要軟件的組織架構(gòu)和流程來保障，離開了這個(gè)，軟件架構(gòu)是一句空話。 另外很多人講，架構(gòu)是進(jìn)化出來的。架構(gòu)實(shí)際上是在量不斷的增大，超過了單臺(tái)服務(wù)器的容量，逐漸的分拆，同時(shí)導(dǎo)致超過單個(gè)人員的能力，工作人員不斷的增多，工作內(nèi)容不斷的分拆形成的。這本身就是架構(gòu)的意義所在。不管怎么分拆，所達(dá)到的目標(biāo)沒有任何變化，就是完成業(yè)務(wù)在計(jì)算機(jī)中的虛擬化。

架構(gòu)漫談（七）：架構(gòu)師沒有話語(yǔ)權(quán)，還架什么構(gòu)！

本文是漫談架構(gòu)專欄的第七篇，作者Kevin探討了什么是架構(gòu)師、成為架構(gòu)師的前提條件、如何發(fā)現(xiàn)“是誰(shuí)的問題”、架構(gòu)師的權(quán)利和義務(wù)等話題。正如作者所說，架構(gòu)師必須是一個(gè)組織的領(lǐng)導(dǎo)人，有權(quán)利調(diào)動(dòng)這個(gè)組織的架構(gòu)，才能夠更好的發(fā)揮架構(gòu)師的作用，更好的把利益的調(diào)整落到實(shí)處。 什么是架構(gòu)師在之前的幾篇文章中，經(jīng)常會(huì)提到架構(gòu)師這個(gè)詞。我們已經(jīng)定義了什么叫架構(gòu)，那怎么定義架構(gòu)師呢，是不是做架構(gòu)的就叫架構(gòu)師了？ 沒有這么簡(jiǎn)單，本篇嘗試討論一下這個(gè)問題。 架構(gòu)師的前提條件如果一個(gè)人在工作中，只是致力于完成自己的工作，以做好自己的工作為主要目標(biāo)，那么最多只能成為一個(gè)工匠，無法成為一個(gè)架構(gòu)師。因?yàn)檫@個(gè)過程解決的還是自己的問題，并沒有時(shí)間的壓力，可以隨意什么時(shí)候做完都可以。 當(dāng)我們所做的工作是處于社會(huì)的分工的一環(huán)，需要幫助別人解決問題，并且按時(shí)解決別人的問題成為我們自己的問題的時(shí)候，我們就有了時(shí)間壓力，潛意識(shí)里會(huì)自然而然的有一種對(duì)時(shí)間的恐懼。這個(gè)恐懼在潛意識(shí)里面會(huì)想方設(shè)法推動(dòng)我們采用各種手段，以便及時(shí)的完成工作，換取報(bào)酬。甚至?xí)影嗉狱c(diǎn)，不擇手段。 如果我們還生活在這個(gè)恐懼下面，是不可能成為架構(gòu)師的。要成為架構(gòu)師，必須要超越這個(gè)恐懼才能夠看清楚，我們要解決的是別人的問題，不是自己完成工作的問題。因?yàn)閮H僅是完成了自己的工作，也并不一定就解決了別人的問題。如果別人的問題沒有解決–即使我們認(rèn)為自己的工作完成了–我們的工作實(shí)際也沒完成，因?yàn)槲覀児ぷ魇欠裢瓿?#xff0c;是別人說的算的，不是我們自己。 為什么會(huì)有這個(gè)對(duì)時(shí)間的恐懼和壓力呢？這是因?yàn)槲覀儼淹瓿勺约旱墓ぷ鳟?dāng)成了我們的最大利益。如果別人的問題沒有真正的解決，必然會(huì)覺得付出的報(bào)酬不值得，我們的利益實(shí)際上是受損失了。這和我們所以為的恰恰相反，因?yàn)槲覀兯艿玫降墓ぷ髦粫?huì)越來越少，別人會(huì)越來越不愿意依賴于我們。 另一方面也說明，我們對(duì)自己所從事的工作，還沒有足夠的自信，我們解決自己的問題還有困難，才會(huì)這么在意，并恐懼。如果我們把完成別人工作當(dāng)成自己的最大利益，這個(gè)對(duì)時(shí)間的恐懼自然就會(huì)消失，這個(gè)時(shí)候就自然而然的開竅了，就知道怎么去發(fā)現(xiàn)問題了。只有做到這一點(diǎn)，才能在自己所服務(wù)的領(lǐng)域建立起自信，成為一個(gè)合格的架構(gòu)師。 其實(shí)剛開始一般是硬著頭皮去克服對(duì)時(shí)間的恐懼和壓力的，一點(diǎn)自信都沒有。但只要做成功了一次（只要真的舍得這么去做了，想不成功也很難！），自信就開始慢慢建立起來了，這個(gè)時(shí)候就是我們開始慢慢變成架構(gòu)師的時(shí)候。大家就當(dāng)著上當(dāng)一回，試試看。 如何發(fā)現(xiàn)“是誰(shuí)的問題”當(dāng)我們真正專注于別人的問題的時(shí)候，我們自己的理想，抱負(fù)，對(duì)技術(shù)的追求都不算什么了。這些理想，抱負(fù)，對(duì)技術(shù)的最求，不就是要達(dá)到自己的利益嗎？ 只有幫助別人解決了問題，這些理想，抱負(fù)，對(duì)技術(shù)的追求才可能實(shí)現(xiàn)，否則這些理想，抱負(fù)，對(duì)技術(shù)的追求有什么意義，能得到什么利益？ 這個(gè)時(shí)候就會(huì)真正的開始思考，別人究竟有什么問題。其實(shí)也很簡(jiǎn)單，和我們自己面臨的問題一樣，別人的問題也都是如何獲取更好更多的利益。我們自己想明白了這一點(diǎn)，自然也就能想明白別人的問題。這個(gè)時(shí)候就能夠問出正確的問題：如果問題不解決，究竟誰(shuí)會(huì)有利益的損失？ 如果問題解決了，究竟誰(shuí)會(huì)有收益，誰(shuí)的收益最大？回答了這兩個(gè)問題就找到了問題的主體。只回答一個(gè)是沒有用的，因?yàn)楹芏鄷r(shí)候這個(gè)世界的事情，權(quán)責(zé)是不對(duì)等的。明白了這兩個(gè)問題，我們只要讓事情權(quán)責(zé)對(duì)等起來，讓每個(gè)人為自己的權(quán)利產(chǎn)生的結(jié)果負(fù)有義務(wù)，大部分時(shí)候我們自己根本就不需要做什么，問題就都解決了。這就是最高明的架構(gòu)師。 架構(gòu)師的權(quán)利和義務(wù)架構(gòu)師是要去平衡別人的利益，甚至?xí){(diào)整別人的利益的。一旦架構(gòu)師是全心全意的為別人的利益服務(wù)，自然而然的架構(gòu)師就擁有了強(qiáng)有力的影響力，肯定會(huì)是一個(gè)leader。但是只是民意上的leader是沒有用的，不能完全發(fā)揮架構(gòu)師的能量。 架構(gòu)師必須是一個(gè)組織的領(lǐng)導(dǎo)人，有權(quán)利調(diào)動(dòng)這個(gè)組織的架構(gòu)，才能夠更好的發(fā)揮架構(gòu)師的作用，更好的把利益的調(diào)整落到實(shí)處。所以很多公司設(shè)了很多架構(gòu)師的職位，但是并不具備調(diào)動(dòng)組織架構(gòu)的權(quán)利，那么這個(gè)架構(gòu)師的職位一定是形同虛設(shè)。架構(gòu)師只能夠通過建立某些流程來行使架構(gòu)師的權(quán)利，比如強(qiáng)制架構(gòu)review，反而會(huì)造成很多內(nèi)部不必要的沖突，最終都會(huì)導(dǎo)致這些流程流于形式，得不償失。相信很多人都已經(jīng)經(jīng)歷過這些，但似乎很少有人回去探討這是為什么。 反過來，具備架構(gòu)師能力的組織領(lǐng)導(dǎo)人，一定是一個(gè)很好的領(lǐng)導(dǎo)，這個(gè)組織一定是很健康向上的，因?yàn)槊總€(gè)人的權(quán)利和義務(wù)就是比較均等的。并且這類領(lǐng)導(dǎo)對(duì)于組織成員權(quán)利和義務(wù)的對(duì)等狀況會(huì)非常的敏感，會(huì)及時(shí)的調(diào)整組織架構(gòu)，在問題發(fā)生之前就解決了。這樣這個(gè)組織就會(huì)具備更好的抗壓能力，能夠更好的為這個(gè)組織的客戶服務(wù)，這個(gè)組織的成員內(nèi)心一定都是比較平衡的，每個(gè)人的能力都能夠得到比較好的發(fā)展。當(dāng)然讀者可能又會(huì)說，這不是管理學(xué)的東西嗎？ 是的，但也是架構(gòu)的問題。所有架構(gòu)的核心就是組織架構(gòu)。或者也可以這樣說，一個(gè)合格的組織領(lǐng)導(dǎo)人，一定必須是一個(gè)合格的架構(gòu)師。 架構(gòu)師的義務(wù)似乎不用說了，大家提的要求可能比我提的都高 – 當(dāng)然是發(fā)現(xiàn)問題并且解決問題。架構(gòu)師必須能夠超越對(duì)時(shí)間的恐懼 –也就是說必須具備了一定程度的自信，哪怕是裝的，去真正的發(fā)現(xiàn)問題的主體，識(shí)別真正的問題，并把這個(gè)行為變成為自己面對(duì)問題的第一反應(yīng)。架構(gòu)師還必須要明白，所給出的解決方案 – 架構(gòu)的分拆、合并方案，只有讓問題的主體的權(quán)責(zé)對(duì)等，才能夠真正的解決別人的問題。一般明白了問題的主體，以及主體的利益所在，做到這一點(diǎn)也沒有問題。 架構(gòu)師和技術(shù)很多人會(huì)問，特別是做軟件行業(yè)的，架構(gòu)師是不是需要學(xué)習(xí)技術(shù)，甚至是學(xué)習(xí)語(yǔ)言？ 如果一個(gè)架構(gòu)師還有這個(gè)困擾—就如問這個(gè)問題的人，說明目前還不具備做架構(gòu)師的能力，或者說還不具備對(duì)自己領(lǐng)域–哪怕是技術(shù)領(lǐng)域–的自信，更別談業(yè)務(wù)領(lǐng)域了。 因?yàn)榧夹g(shù)和語(yǔ)言，都是用來識(shí)別和解決所服務(wù)的主體的權(quán)責(zé)，保護(hù)并提升所服務(wù)的主體的權(quán)利的。特別對(duì)于軟件領(lǐng)域來說，必須明白軟件本身是怎么回事，解決什么問題，還要解決軟件所服務(wù)的對(duì)象的領(lǐng)域本身是怎么回事，解決什么問題，這就要求更高了。語(yǔ)言和技術(shù)應(yīng)該是隨手拈來才對(duì)，對(duì)于架構(gòu)師這些都是工具。學(xué)習(xí)技術(shù)和語(yǔ)言，如果明白了這些技術(shù)和語(yǔ)言要解決的是誰(shuí)的問題，什么問題，學(xué)起來是非?？?#xff0c;非常容易的。 同樣，采用哪個(gè)技術(shù)或者語(yǔ)言，只要某個(gè)技術(shù)或語(yǔ)言所解決的問題的主體，以及所解決的問題，和自己所面對(duì)的問題的主體和這個(gè)主體要解決的問題，這兩者是匹配的，那么這個(gè)方案是成本是最低的，所采用的技術(shù)或者語(yǔ)言就是靠譜的。沒有趁手的工具或語(yǔ)言的情況下，自己設(shè)計(jì)一個(gè)也不難，因?yàn)楹芮宄约阂裁础Ｒ灰约鹤?#xff0c;無非是一個(gè)成本問題，也就是利益問題。并且從這個(gè)思路下去，選擇的工具和語(yǔ)言肯定都是最簡(jiǎn)單的，成本是最低的。因?yàn)榧軜?gòu)畢竟解決的還是人的利益問題，成本越低越好，這個(gè)成本當(dāng)然是長(zhǎng)期總體成本，不是眼前的短期成本。

架構(gòu)漫談（八）：從架構(gòu)的角度看如何寫好代碼

本文是漫談架構(gòu)專欄的第八篇，作者Kevin舉例介紹了如何寫好代碼。當(dāng)我們有了好的架構(gòu)，那就需要考慮如何將架構(gòu)落地，而這個(gè)時(shí)候，代碼就顯得無比重要了！千萬(wàn)不要讓代碼成為架構(gòu)擴(kuò)展的瓶頸。文中作者提到了代碼架構(gòu)，細(xì)細(xì)品味吧。 在第六篇文章中，我們得出一個(gè)結(jié)論，軟件架構(gòu)實(shí)際上包括了：代碼架構(gòu)，以及承載代碼運(yùn)行的硬件部署架構(gòu)。實(shí)際上，硬件部署架構(gòu)最終還是由代碼的架構(gòu)來決定。因?yàn)榇a架構(gòu)不合理，是無法把一個(gè)運(yùn)行單元分拆出多個(gè)來的，那么硬件架構(gòu)能分拆的就非常的有限，整個(gè)系統(tǒng)最終很難長(zhǎng)的更大。 所以我們經(jīng)常會(huì)聽說，重寫代碼，推翻原有架構(gòu)，重新設(shè)計(jì)等等說法，來說明架構(gòu)的進(jìn)化。這實(shí)際上就是當(dāng)初為了完成任務(wù)，沒有充分思考所帶來的后果。這也并不是架構(gòu)進(jìn)化的事情，而是個(gè)人對(duì)問題領(lǐng)域的逐漸深入理解的過程。所以有必要再討論一下，代碼的架構(gòu)應(yīng)該是怎樣的。 本文會(huì)在之前幾篇文章的基礎(chǔ)上，進(jìn)一步探討如何把架構(gòu)的思考進(jìn)行落地，細(xì)化到我們代碼的實(shí)踐當(dāng)中，盡量不要讓代碼成為系統(tǒng)長(zhǎng)大的瓶頸，降低架構(gòu)分拆的成本。 在前面我們提到，軟件實(shí)際上是對(duì)現(xiàn)實(shí)生活的模擬，虛擬化。這是一個(gè)非常重要的前提，直接決定了我們的代碼應(yīng)該分為幾部分。結(jié)合每個(gè)部署單元所承擔(dān)的責(zé)任，可以明確的拆分為兩個(gè)不同的責(zé)任： 表達(dá)業(yè)務(wù)邏輯的代碼。很多人把這部分叫做Domain Logic，或者叫Domain Model。這部分實(shí)際是來源于生活的，必須保持和現(xiàn)實(shí)生活中的切分一致，并非人為的抽象而成。 對(duì)用戶提供訪問并保存業(yè)務(wù)邏輯運(yùn)行結(jié)果的代碼。計(jì)算機(jī)的狀態(tài)保存有一個(gè)缺陷，本機(jī)保留業(yè)務(wù)運(yùn)行結(jié)果有很大的問題，一般都在外存儲(chǔ)設(shè)備上保存，也便于擴(kuò)展。 所以單個(gè)部署單元的代碼可以分為兩個(gè)部分，如下圖所示： 從這個(gè)圖中可以看出，軟件代碼的相關(guān)利益人為運(yùn)行時(shí)的訪問人員和存儲(chǔ)設(shè)備。而service的代碼是最復(fù)雜的，需要服務(wù)于三方，代碼人員的負(fù)擔(dān)是最重的。為了把這三方的變化對(duì)service的影響降到最低，對(duì)于service還必須進(jìn)一步的分拆為三個(gè)部分，讓每一個(gè)部分都能夠獨(dú)立的變化，這樣這三方的變化就不會(huì)產(chǎn)生連鎖響應(yīng)，降低成本。如下圖所示： 這樣，就劃分成了幾個(gè)責(zé)任： Service就專注于user的需求，并組合Glue Code提供的服務(wù)完成需求。 Glue Code專注于組合business的調(diào)用，管理Business里面對(duì)象的生命周期，并且通過Repository保存或加載Business的狀態(tài) Business專注于實(shí)現(xiàn)業(yè)務(wù)的核心模型。 Repository專注于數(shù)據(jù)的保存，并和存儲(chǔ)設(shè)備一一對(duì)應(yīng)。 大家注意看，還是樹形架構(gòu)。并且左側(cè)的主要需要計(jì)算機(jī)的相關(guān)理論知識(shí)，并且要直接面對(duì)用戶的需求。右側(cè)的更多的需要面對(duì)業(yè)務(wù)的核心。只要這幾塊的開發(fā)人員互相商量好了接口定義，這幾個(gè)部分的開發(fā)就可以并行的進(jìn)行，極大的提升開發(fā)的效率，縮短開發(fā)的時(shí)間。要做好這幾部分，還需要注意，邏輯只允許存在于Business中，Service、Glue Code、Repository都不允許存在業(yè)務(wù)邏輯。為什么呢？首先我們來看看什么叫業(yè)務(wù)邏輯。 什么叫業(yè)務(wù)邏輯？首先這個(gè)定義的前提是指軟件代碼中的邏輯，不是現(xiàn)實(shí)生活中的邏輯。在軟件代碼中，不需縮進(jìn)和計(jì)算的順序調(diào)用，包括縮進(jìn)的代碼目的是cache exception的，都不算邏輯，除此以外都是邏輯。以下用嚴(yán)格的順序調(diào)用來指代這種代碼。因?yàn)轫樞蛘{(diào)用是計(jì)算機(jī)的特性，由編譯器來決定的，當(dāng)然最本質(zhì)的是因?yàn)槲覀冇?jì)算的基礎(chǔ)都是圖靈機(jī)。在現(xiàn)實(shí)生活中，順序調(diào)用也是邏輯，大家不要和我們這里說的業(yè)務(wù)邏輯相混淆。 為什么說除了Business代碼中有邏輯以外，其他地方不能有邏輯呢？ 我們每個(gè)部分分別分析： 如果service里面不是嚴(yán)格的順序調(diào)用，有很多分支，那么說明這個(gè)service做了兩件或者兩件以上的事情。必須把這個(gè)service分拆，確保每個(gè)service只做一件事情。因?yàn)槿绻贿@么分拆的話，一旦這個(gè)service中的某各部分發(fā)生變動(dòng)，其他的部分的執(zhí)行必定會(huì)受影響。而確定到底有哪些影響的溝通成本非常高，其他相關(guān)利益方?jīng)]有動(dòng)力去配合，我們往往不會(huì)投入精力仔細(xì)評(píng)估。最后上線會(huì)出很多不可預(yù)料的問題，最終會(huì)導(dǎo)致?lián)p失用戶的利益，并且肯定會(huì)導(dǎo)致返工，損壞自己的利益。如果是有計(jì)算的邏輯的話，比如受益計(jì)算，訂單金額計(jì)算等，那么這部分應(yīng)該是Business代碼需要完成的，不能交給service代碼來實(shí)現(xiàn)。 Glue Code里面如果不是嚴(yán)格的順序調(diào)用，同理會(huì)和service一樣遇到同樣的問題。 Repository里面如果不是嚴(yán)格的順序調(diào)用，包括存儲(chǔ)訪問的代碼里面（比如SQL），會(huì)導(dǎo)致邏輯進(jìn)入到存儲(chǔ)設(shè)備中。存儲(chǔ)設(shè)備的主要目的是拿來存儲(chǔ)的，一旦變成了邏輯計(jì)算的主體，就會(huì)導(dǎo)致存儲(chǔ)設(shè)備無法通過增加機(jī)器的方式橫向擴(kuò)展長(zhǎng)大。這個(gè)時(shí)候就沒有架構(gòu)了，只能換性能更好的機(jī)器，這個(gè)叫scale up。只有scale out才能算架構(gòu)。 以上都會(huì)導(dǎo)致架構(gòu)無法快速的橫向擴(kuò)展和分拆，并且增加了修改的成本，這些是不符合開發(fā)人員以及業(yè)務(wù)的利益的。 這么做的好處有哪些呢？ Service、Glue Code、Repository里面的代碼是嚴(yán)格的順序調(diào)用，那么這些代碼只要做連通性測(cè)試即可，不需要單元測(cè)試。因?yàn)檫@些代碼都需要和很多上下文打交道，很難做單元測(cè)試。這樣才算是真正的組合。 Business不訪問任何上下文，不訪問任何具體的設(shè)備，所以這部分代碼是非常容易些單元測(cè)試的，并且單元測(cè)試必須100%覆蓋。因?yàn)槠渌胤經(jīng)]有業(yè)務(wù)邏輯，所以一旦有問題，就可以斷定是Model的問題，單元測(cè)試肯定可以發(fā)現(xiàn)。如果單元測(cè)試沒有發(fā)現(xiàn)問題，那么單元測(cè)試一定有問題。線上問題的模擬也就變得非常的簡(jiǎn)單，單元測(cè)試也能夠得到進(jìn)一步的補(bǔ)充。 Repository很容易按照存儲(chǔ)設(shè)備本身的最小訪問粒度來完成工作，比如DB，完全可以做到單表訪問。因?yàn)檫@個(gè)時(shí)候存儲(chǔ)設(shè)備只關(guān)心存取數(shù)據(jù)，完全和業(yè)務(wù)沒有關(guān)系。做表的分拆也是非常容易的事情，存儲(chǔ)設(shè)備通過增加機(jī)器就可以橫向擴(kuò)展長(zhǎng)大。很多人會(huì)擔(dān)心說，沒有了join，訪問DB的次數(shù)是不是更多了，會(huì)導(dǎo)致性能下降？ 按照現(xiàn)在網(wǎng)絡(luò)的條件，網(wǎng)絡(luò)訪問和Disk IO訪問的差距已經(jīng)不大了，合理的設(shè)計(jì)下，多訪問幾次DB并不會(huì)導(dǎo)致這個(gè)問題。另外如果多臺(tái)DB的話，還能通過并行加速訪問。 由于Service、Glue Code、Repository代碼簡(jiǎn)單了，才可以讓我們的開發(fā)人員投入更多的時(shí)間研究業(yè)務(wù)，畢竟這部分才是軟件所真正服務(wù)的對(duì)象。 我們?cè)賮砜匆粋€(gè)實(shí)際的例子，如下圖所示： Manager類實(shí)際就是Glue Code。有幾個(gè)注意點(diǎn)需要說明一下： 不能把Business Model當(dāng)做數(shù)據(jù)對(duì)象來處理，Model關(guān)心的實(shí)際上是業(yè)務(wù)行為，數(shù)據(jù)只是是這些行為的結(jié)果。所以Glue Code需要把Model轉(zhuǎn)換為Entity，Entity和存儲(chǔ)設(shè)備里面的存儲(chǔ)粒度一一對(duì)應(yīng)。比如在DB中，每個(gè)Entity對(duì)應(yīng)一張表，并且跟著表的變化而變化，這樣就保證存儲(chǔ)的變更不會(huì)影響Model。同樣Service和用戶之間的數(shù)據(jù)交互，也是不會(huì)和Model之間相關(guān)的，確保用戶的需求變化，不會(huì)影響到Model。因?yàn)橛脩舻男枨笞兓亲铑l繁的，沒有邏輯，可以讓我快速的滿足業(yè)務(wù)的需求。 在Service這里，最好不要考慮代碼重用。因?yàn)楫?dāng)多個(gè)不同的角色訪問同一個(gè)接口，一旦某個(gè)角色的需求發(fā)生了變化，就會(huì)要求開發(fā)人員去修改。而這個(gè)修改往往會(huì)影響到其他的角色，需要這些角色一起配合來確定是否受影響，但是這些角色因?yàn)闆]有需求，往往不會(huì)配合。這樣就給開發(fā)人員造成了很多不必要的溝通，成本是非常高的。最終都會(huì)導(dǎo)致線上Bug，影響最終的用戶。所以盡量給不同的角色不同的Service，避免重用，降低溝通成本。很多人會(huì)說這樣Service不就太多了嗎？ 這樣Service注冊(cè)，查找等管理需求就出現(xiàn)了，Service治理中心就是來解決這個(gè)問題的。因?yàn)镾ervice里面沒有邏輯，所以開發(fā)和管理非常的簡(jiǎn)單，可以快速應(yīng)對(duì)業(yè)務(wù)的變化。我們只有更快地變，更容易的變，才能更好地應(yīng)對(duì)變。 Business Model是必須要重用的，一旦發(fā)現(xiàn)重用出現(xiàn)問題，那么說明Business Model的識(shí)別出現(xiàn)了問題，這是一個(gè)我們要重新思考Model的信號(hào)。Business Model必須是一個(gè)完美的樹狀，如果不是，也說明Model的識(shí)別出了問題。 在實(shí)際操作中，Service、Glue Code、Repository不能有邏輯，實(shí)際上和很多人的觀念是沖突的，認(rèn)為這個(gè)根本做不到。做到這一點(diǎn)需要很多的學(xué)習(xí)成本，但是一定可以做得到。當(dāng)發(fā)現(xiàn)做不到的時(shí)候，可以斷定是業(yè)務(wù)的分析出了問題。比如不該合并的合并了，不該計(jì)算的計(jì)算了。這個(gè)問題一定有辦法解決的，做不到都是理由，無非是想早點(diǎn)把自己的工作結(jié)束罷了。雖然剛開始會(huì)比較困難，一旦把這個(gè)觀念變成自覺，開發(fā)的質(zhì)量和效率馬上就能高好幾個(gè)級(jí)別。 我的游泳教練曾和我說過這些話，我至今記憶猶新：“業(yè)余選手，越想從水里浮起來，就越想把頭抬起來，身體反而沉下去。只有克服恐懼，把頭往水里壓下去，身體才能夠從水里浮起來。真正專業(yè)的習(xí)慣往往是和我們?nèi)粘５男袨橄喾吹摹薄?我們真正想快速的完成代碼工作，就要克服自己對(duì)時(shí)間的恐懼，真正的去研究業(yè)務(wù)的問題，相關(guān)stakeholder的利益，把這個(gè)變成我們的習(xí)慣。寫代碼的時(shí)候讓該出現(xiàn)邏輯的地方出現(xiàn)邏輯，讓不該出現(xiàn)的地方不能出現(xiàn)。一旦不該出現(xiàn)的地方出現(xiàn)了邏輯，那么要馬上意識(shí)到，這個(gè)地方是一個(gè)坑，這個(gè)問題一定和業(yè)務(wù)的分析不透徹有關(guān)系。 很多人可能會(huì)把這個(gè)做法和Martin Fowler曾經(jīng)提出過充血模型和貧血模型來比較，和Domain Driven Design來比較，其實(shí)沒有必要。這個(gè)分拆完全是從軟件所解決的問題，根據(jù)軟件架構(gòu)推導(dǎo)出來的，很多地方和兩位前輩的觀點(diǎn)是一致的，但是并不完全等同。 以上只是針對(duì)單一的Service部署單元的分析，擴(kuò)展開去，對(duì)于其他的部署單元也是類似的。每個(gè)單元的下一級(jí)都可以認(rèn)為是Repository，每個(gè)單元的上一級(jí)都可以認(rèn)為是User。這些實(shí)踐在我自己的項(xiàng)目中都有用到，非常的有效，迭代的速度非常的快。很多人擔(dān)心Business Model建不好，其實(shí)沒關(guān)系，剛開始可以粗糙一點(diǎn)，后續(xù)可以慢慢的完善。這個(gè)架構(gòu)已經(jīng)隔離好了每個(gè)部分的變化對(duì)其他部分的影響，變化成本都在可控的范圍之內(nèi)。

架構(gòu)漫談（九）：你理清技術(shù)、業(yè)務(wù)和架構(gòu)之間的關(guān)系了嗎？

本文是漫談架構(gòu)專欄的第九篇，作者Kevin以鉆木取火為切入點(diǎn)，深入介紹了技術(shù)、業(yè)務(wù)和架構(gòu)之間的關(guān)系。正如作者所說，技術(shù)總是在人類解決對(duì)業(yè)務(wù)的要求不斷提高的情況下產(chǎn)生，目的也是為了獲取更大更好的利益。 某天和朋友吃飯正好聊到這個(gè)話題。作為架構(gòu)師或者做技術(shù)的人，在開發(fā)軟件時(shí)，我們基本上就是在扮演上帝的角色：我們不但要?jiǎng)?chuàng)建出一個(gè)個(gè)的程序，還要讓這些程序能夠脫離我們?cè)谟布溪?dú)立運(yùn)行，以便為這個(gè)程序所服務(wù)的群體提供服務(wù)。當(dāng)這個(gè)程序出現(xiàn)問題甚至bug的時(shí)候，我們還得扮演牧師的角色去修復(fù)這些問題。這不正是一個(gè)程序的社會(huì)嗎？ 和人類社會(huì)的演變何其相似！那么我們自然也能夠拿人類演變的歷史來指導(dǎo)軟件開發(fā)工作，以避免再經(jīng)歷一次像人類演變發(fā)展那么痛苦的過程了。由此我們也可以看出，架構(gòu)師和程序員們都在扮演著多么重要的角色，如果還在解決自己的問題，怎么扮演好上帝這個(gè)角色？ 在軟件設(shè)計(jì)開發(fā)的過程中經(jīng)常會(huì)看到，很多所謂的架構(gòu)討論實(shí)際上只是在討論某種技術(shù)。在很多人的概念里面，架構(gòu)和技術(shù)實(shí)際上是等同的。學(xué)會(huì)了幾種技術(shù)，就認(rèn)為自己是架構(gòu)師了，甚至是學(xué)習(xí)的技術(shù)越多，就覺得自己的水平越高。這樣實(shí)際上是對(duì)自己很不負(fù)責(zé)任的。要知道任何技術(shù)都是為了解決某種問題而存在的，學(xué)會(huì)了技術(shù)，并不代表自己能夠解決問題，這一點(diǎn)非常的重要。學(xué)會(huì)的技術(shù)的多少，所帶來的差別只是自己解決問題的手段多了罷了。但是手段多了就一定是好事嗎？ 很多時(shí)候，學(xué)習(xí)的技術(shù)越多，越不知道采用哪種技術(shù)好，所謂“亂花漸欲迷人眼”。 還有另一種很普遍的觀點(diǎn)：技術(shù)人普遍看不起業(yè)務(wù)，認(rèn)為技術(shù)更高端，而業(yè)務(wù)太低端，并且業(yè)務(wù)往往喜歡給技術(shù)挖坑。業(yè)務(wù)則覺得技術(shù)眼光高，但是實(shí)際解決不了問題，總是理解有偏差，但是又無可奈何，因?yàn)樽约翰粫?huì)。 本篇文章嘗試從這里入手，分析一下這三個(gè)概念到底有什么關(guān)系，我們應(yīng)該怎么處理業(yè)務(wù)、技術(shù)還有架構(gòu)的關(guān)系。 什么是技術(shù)當(dāng)我們一無所有，或者什么都不會(huì)的時(shí)候，這個(gè)時(shí)候?qū)嶋H上是沒有技術(shù)的。就好比人類在最早期，什么都得用自己的雙手來干活。一旦我們?cè)谌粘Ｉ钪袩o意間發(fā)現(xiàn)某些規(guī)律的時(shí)候，我們就可以通過創(chuàng)造條件，讓這個(gè)規(guī)律重復(fù)的發(fā)生。通過人為創(chuàng)造條件，讓指定的規(guī)律按照人類的意愿發(fā)生，這就是技術(shù)。比如取火，最早人類只能靠打雷等自然現(xiàn)象產(chǎn)生火。 取火其實(shí)就是一個(gè)業(yè)務(wù)目標(biāo)，要解決的是人類自己的問題，這就是業(yè)務(wù)，實(shí)際就是人類的利益。這個(gè)時(shí)候人類沒有生火的技術(shù)，只能靠不斷的加木材，保持火不熄滅。后來人們發(fā)現(xiàn)了鉆木取火：只要用一個(gè)干的木棍，在另一個(gè)干木表面快速的轉(zhuǎn)動(dòng)，就可以生火。這個(gè)辦法讓人類可以自行創(chuàng)造火源，就產(chǎn)生了鉆木取火的技術(shù)。 但是雙手快速轉(zhuǎn)動(dòng)木棍鉆木取火，并不是所有人都能夠做得到的，需要很多力量和速度，對(duì)人的要求太高。為了解決快速轉(zhuǎn)動(dòng)的問題，就有人采用弓弦來提升木棍轉(zhuǎn)動(dòng)的速度。 也就是說： 業(yè)務(wù)目標(biāo)是為了取火，鉆木取火這個(gè)技術(shù)的出現(xiàn)解決了這個(gè)問題。 鉆木取火的效率不高，影響了業(yè)務(wù)（取火）的效率，就有了進(jìn)一步改進(jìn)的動(dòng)機(jī)，改進(jìn)轉(zhuǎn)動(dòng)木棍的方式，產(chǎn)生了弓弦轉(zhuǎn)動(dòng)木棍的技術(shù)。 技術(shù)與架構(gòu)，以及與業(yè)務(wù)之間的關(guān)系技術(shù)總是在人類解決對(duì)業(yè)務(wù)的要求不斷提高的情況下產(chǎn)生，目的也是為了獲取更大更好的利益。所以： 技術(shù)是為了解決業(yè)務(wù)的問題而產(chǎn)生的，沒有了業(yè)務(wù)，技術(shù)就沒有了存在的前提。 有了更好的技術(shù)，效率更差的技術(shù)，就會(huì)慢慢的被淘汰，消失，一切都遵從人類的利益訴求–也就是業(yè)務(wù)。有人會(huì)問，不用鉆木取火了，但是弓弦加速轉(zhuǎn)動(dòng)木棍還可以用啊？ 沒錯(cuò)，因?yàn)楣肄D(zhuǎn)動(dòng)木棍這個(gè)技術(shù)，不是來生火的，是用來加速木棍轉(zhuǎn)動(dòng)的，所解決的問題不一樣。但是兩種不同的技術(shù)，合理結(jié)合起來，會(huì)更好更有效率的解決業(yè)務(wù)問題。 所以技術(shù)與技術(shù)之間，有兩種關(guān)系： 在解決同一個(gè)業(yè)務(wù)問題的前提下，更高效，更低成本的技術(shù)，會(huì)淘汰低效，高成本的技術(shù)。這是人類利益訴求所決定的。 一般剛開始解決根本問題的技術(shù)（鉆木取火）的效率是比較低的，只是把不可能變成了可能（從這一點(diǎn)上來說，技術(shù)才是業(yè)務(wù)的enabler）。然后就會(huì)有提高效率的需求出現(xiàn)，要求改進(jìn)這個(gè)技術(shù)。這個(gè)技術(shù)的低效率部分就會(huì)被其他人（或者技術(shù)發(fā)明人自己）加以改進(jìn)，這部分就會(huì)形成新的技術(shù)。 當(dāng)關(guān)系2發(fā)生的時(shí)候，這個(gè)地方必定會(huì)形成一個(gè)切分，新技術(shù)會(huì)通過某種方式和原有的技術(shù)連接在一起形成一個(gè)整體，讓這個(gè)新的技術(shù)可以和原有技術(shù)共同工作，使得原有的技術(shù)可以用更高的效率解決問題。因?yàn)橐鉀Q的主要問題（生火）并沒有發(fā)生改變，分拆所形成的是一個(gè)樹狀的結(jié)構(gòu)。 按照前面的架構(gòu)定義，這個(gè)時(shí)候其實(shí)已經(jīng)產(chǎn)生了架構(gòu)。也就是說，一般是先有技術(shù)，才會(huì)有架構(gòu)。這些其他技術(shù)（弓弦拉動(dòng)木棍），是從直接解決問題的初始主要技術(shù)中分拆出來形成的，并通過樹狀結(jié)構(gòu)和主要技術(shù)（鉆木取火）組合在一起。在解決主要問題（生火）之后，再開始逐漸的分拆為更為細(xì)粒度的技術(shù)（弓弦轉(zhuǎn)木棍）。 而這個(gè)細(xì)粒度的技術(shù)（弓弦轉(zhuǎn)動(dòng)木棍）往往不會(huì)和業(yè)務(wù)的主要目標(biāo)（生火）發(fā)生直接的關(guān)系。不同的技術(shù)，通過樹狀結(jié)構(gòu)，組合在一起，形成了一個(gè)完整的架構(gòu)解決方案，共同完成業(yè)務(wù)的目標(biāo)。這就是技術(shù)，業(yè)務(wù)和架構(gòu)之間的關(guān)系。很多人把這個(gè)過程稱為架構(gòu)的進(jìn)化，我更愿意把這個(gè)過程稱為技術(shù)的進(jìn)步所導(dǎo)致的新的架構(gòu)分拆，因?yàn)檫@個(gè)過程內(nèi)在的動(dòng)力，更多的是來自技術(shù)對(duì)解決業(yè)務(wù)問題的解決。 技術(shù)人員和業(yè)務(wù)人員的關(guān)系為什么技術(shù)人員總是和業(yè)務(wù)人員發(fā)生沖突呢？ 這是因?yàn)榧夹g(shù)人員很多時(shí)候關(guān)心的技術(shù)，和業(yè)務(wù)的主要目標(biāo)往往不是直接對(duì)應(yīng)的，業(yè)務(wù)也是負(fù)責(zé)某一部分的業(yè)務(wù)，也不是和業(yè)務(wù)的主要目標(biāo)直接對(duì)應(yīng)的，都是樹的分支節(jié)點(diǎn)（上文已經(jīng)解釋了為何會(huì)發(fā)生這種情況）。只有直接解決業(yè)務(wù)問題的那個(gè)技術(shù)（或業(yè)務(wù)）–樹的根節(jié)點(diǎn)–會(huì)和業(yè)務(wù)直接相關(guān)。所以一旦產(chǎn)生沖突，一般必須兩個(gè)根節(jié)點(diǎn)（一般都是領(lǐng)導(dǎo)）碰面才能解決問題，就是這個(gè)原因–他們都知道業(yè)務(wù)主要目標(biāo)。這也是為什么下層無法理解上層，而上層都喜歡下軍令狀，要求下層執(zhí)行。人只有盡量去理解上層的問題才能做下層的分拆。 在軟件行業(yè)，這個(gè)根節(jié)點(diǎn)技術(shù)就是軟件。這也是為什么架構(gòu)師要認(rèn)識(shí)什么叫軟件，軟件解決誰(shuí)的問題，什么問題，軟件本身又是怎么分拆的，才能夠更好的組合不同的技術(shù)，完成業(yè)務(wù)的目標(biāo)。而軟件里面和業(yè)務(wù)直接相關(guān)的，只有Business Domain這一部分。 用人來打比方，Business Domain相當(dāng)于人的大腦，而Service，Repository，Glue Code等部分所采用的技術(shù)，全部都是計(jì)算機(jī)自己領(lǐng)域的技術(shù)，都是為了能夠讓程序跑起來，相當(dāng)于人的四肢。我們大部分開發(fā)人員的工作主要專注于四肢部分。我們真正應(yīng)該投入的是大腦部分。因?yàn)榇竽X能夠決定四肢長(zhǎng)什么樣，而不是反過來。很多架構(gòu)師、技術(shù)人員主要專注于計(jì)算機(jī)相關(guān)的技術(shù)，忽略了業(yè)務(wù)本身，甚至看不起業(yè)務(wù)，這也是為什么技術(shù)總是和業(yè)務(wù)沖突的原因。 架構(gòu)師應(yīng)該承擔(dān)起解決業(yè)務(wù)問題的這個(gè)角色來，專注于Business Domain和軟件本身的架構(gòu)，讓技術(shù)人員致力于為業(yè)務(wù)在計(jì)算機(jī)中跑起來而努力。只有把這兩者很好的結(jié)合起來，才能更好地完成業(yè)務(wù)的目標(biāo)，才會(huì)讓軟件更好地服務(wù)于大家。最終一定會(huì)得到一個(gè)很好的軟件架構(gòu)，令軟件開發(fā)團(tuán)隊(duì)和業(yè)務(wù)部門都能夠很好地開展工作并降低成本。 重新發(fā)明輪子當(dāng)現(xiàn)有已經(jīng)存在很多技術(shù)，而這些技術(shù)卻和我們所要解決的問題并不是那么直接對(duì)應(yīng)的時(shí)候，我們就需要有意識(shí)的組織和識(shí)別不同的技術(shù)，來實(shí)現(xiàn)業(yè)務(wù)的目標(biāo)。這個(gè)時(shí)候組織的方式有很多種，其中成本最低的方法就是按照要達(dá)成的目的和當(dāng)前的問題，從上到下進(jìn)行架構(gòu)分拆。分拆出來的更細(xì)粒度的問題，分解到不同的人來進(jìn)行解決，就形成了業(yè)務(wù)架構(gòu)和組織架構(gòu)。解決這些問題就需要組合很多不同的技術(shù)，那么應(yīng)該采用哪些技術(shù)？還是自己重頭實(shí)現(xiàn)一個(gè)？ 自己實(shí)現(xiàn)一個(gè)—這就是很多人所謂的重新發(fā)明輪子。以下試著分析一下： 當(dāng)技術(shù)所提供的能力遠(yuǎn)遠(yuǎn)超過需要解決的問題時(shí)，往往掌握技術(shù)和維護(hù)技術(shù)會(huì)成為瓶頸。因?yàn)樵綇?fù)雜的技術(shù)，成本越高。如果自己實(shí)現(xiàn)一個(gè)僅僅是解決當(dāng)前問題的方案，可能成本反而更低。這也是為什么很多大型的互聯(lián)網(wǎng)公司不斷地開源出來自己的技術(shù)的原因。而這些技術(shù)對(duì)于我們來說是否適用？他們?cè)臼怯脕斫鉀Q誰(shuí)的問題的？什么問題？如果不清楚這些，就冒然采用，可能會(huì)導(dǎo)致更高的成本。 當(dāng)技術(shù)所提供的能力和我們所要解決的問題部分匹配時(shí)，還是要看成本。比如當(dāng)我們需要一個(gè)錘子的時(shí)候，手邊正好沒有，但是卻有一只高跟鞋，勉強(qiáng)也可以替代錘子。但是長(zhǎng)期來看，這么用不劃算，因?yàn)楦吒膬r(jià)格比錘子高很多，耐用性差很多，維護(hù)成本也高很多。 所以，準(zhǔn)確識(shí)別采用什么技術(shù)的能力，也是架構(gòu)師所要具備的能力之一?？紤]的主要因素也是長(zhǎng)期的成本和收益。

總結(jié)

以上是生活随笔為你收集整理的架构漫谈专栏系列文章的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。