軟件行業(yè)，苦樂自知

今年是我從事軟件開發(fā)的第17個年頭。從非科班出生的業(yè)余計算機(jī)愛好者，到成為走過無數(shù)彎路的老碼農(nóng)，或者偶爾也被人稱為架構(gòu)師?；仡櫸页蔀榧軜?gòu)師的道路，可能要追溯到最初的工作階段，干過碼農(nóng)、做過美工、當(dāng)過項目經(jīng)理，這些經(jīng)歷讓我幸運地在實踐中體會了從醞釀?wù)Q生到后期維護(hù)的整個階段，然而當(dāng)時苦于沒有經(jīng)過系統(tǒng)的訓(xùn)練和學(xué)習(xí)，對整個軟件工程和架構(gòu)的認(rèn)知是懵懂的。十余年前，我參加并通過了系統(tǒng)分析員的考試（當(dāng)年軟件架構(gòu)師認(rèn)證還沒有從系統(tǒng)分析師中分離出來），然后又陸續(xù)作為“架構(gòu)師”被某些大公司聘用（然而自認(rèn)其實還不夠格），逐漸地，在一些大型項目的歷練和個人業(yè)余作品的開發(fā)種，才彌補(bǔ)了我技術(shù)上的短板。

回首十余年軟件從業(yè)的道路，從開發(fā)到項目經(jīng)理再到部門管理，然后回歸開發(fā)，到最后成為架構(gòu)師，期間的坎坷真實苦樂自知。而讓我能在這個行業(yè)一直堅持下來，并且不斷適應(yīng)這個行業(yè)變化的，我認(rèn)為最大的收獲來自于同事和前輩的指導(dǎo)，其次就是不斷的自我反省和教訓(xùn)總結(jié)。因為走彎路好比交學(xué)費，工作就是不斷地在錯誤中前行，必須時刻警惕不要讓自己犯下相同的錯誤—如果一次次掉到同樣的坑里，是很難在這個行業(yè)的研發(fā)崗位上堅持下來的。

為此，我愿意分享我的經(jīng)驗和教訓(xùn)，或許有緣者能從中體會一二。

如何做好一個架構(gòu)師

1. 關(guān)注用戶行為動機(jī)和利益

軟件工程的源頭，在于用戶需求，而用戶需求恰恰是軟件項目中最難的，也是很容易被大家忽視的點。架構(gòu)師必需從源頭來引導(dǎo)軟件開發(fā)這條河流，不要讓它流到溝里去。

讓我首次明白業(yè)務(wù)分析的重要性，是在我工作不久的時候。當(dāng)時，我負(fù)責(zé)某省廳檔案系統(tǒng)的項目開發(fā)，第一次作為主力程序員，在走訪了幾個業(yè)務(wù)員后，很快便開發(fā)出了第一個版本，當(dāng)時內(nèi)心還是挺得意的。

開發(fā)完成后我便去給用戶報告，剛見到用戶，還沒來得及把軟件打開給對方看，用戶表示上次談的需求只是一點點，復(fù)雜的問題還沒和我說呢，然后張嘴說出一大堆業(yè)務(wù)名詞和術(shù)語，把我說得云里霧里，感覺好像完成的軟件功能不到實際業(yè)務(wù)需求的三分之一。如此往復(fù)、修改下來，才粗略了解到用戶業(yè)務(wù)的概況。這才發(fā)現(xiàn)實際要開發(fā)一款被用戶接受的軟件，并不如預(yù)期得那么容易。

然后真正的磨煉還在后面。當(dāng)我終于第一次將自認(rèn)為完整的功能上線拿給用戶試用，得到的是“幾乎沒辦法使用”的評價。用戶一改過去積極配合的態(tài)度，產(chǎn)生了諸多抱怨。比如，多余的輸入框，要求輸入框有記憶功能（就是后來的“自動完成”功能，也就是希望將Excel表格的操作方式搬到軟件上來，當(dāng)時的Web開發(fā)技術(shù)幾乎不能支持）等等，很多需求以當(dāng)時的技術(shù)能力很難實現(xiàn)。

這簡直沒法干了，我?guī)缀跻艞壛?，這個問題最終被上級領(lǐng)導(dǎo)反映給了負(fù)責(zé)建設(shè)這套系統(tǒng)的廳辦公室主任（多年以后，我終于知道，他是“客戶”而不是“用戶”）。在主任安排下，次日我坐在用戶辦公室觀察他的日常工作。原來用戶上午要處理的文書案卷有一百多件，我們的檔案系統(tǒng)不但需要用戶逐個瀏覽所有待填寫字段，還要求用戶將檔案掃描后錄入系統(tǒng)（主任要求的），用戶的工作量不但沒有降低，反而大為增加！

這里有兩個問題。第一、由于數(shù)量原因，錄入效率要求非常高，但在設(shè)計開發(fā)中沒有得到重視。第二、系統(tǒng)上線后反而加重工作負(fù)擔(dān)，用戶有了抗拒心理。但業(yè)務(wù)的框架是主任定的，這是用戶“不愿意”說出口的原因。

很多時候用戶訴求猶如冰山，訪談和書面的需求說明上能獲得的只有冰山浮在水面上的部分，大量的潛在訴求隱藏在水面之下，不深入學(xué)習(xí)用戶業(yè)務(wù)細(xì)節(jié)是無法真正掌握用戶訴求。在分析用戶需求時，需要關(guān)注用戶的動機(jī)和出發(fā)點，而這往往是用戶利益息息相關(guān)的，我們需要分析清楚這種動機(jī)和利益關(guān)系。

在知道了原因后問題就好辦了，主任很快就根據(jù)系統(tǒng)上線后的工作負(fù)載情況，從另一個工作量大幅減少的崗位上安排人員來負(fù)責(zé)文檔錄入，同時我們也對軟件交互進(jìn)行了大幅改進(jìn)。最后系統(tǒng)再次上線后，整個軟件的實施就變得非常順利了。

多年后，我終于知道分析業(yè)務(wù)全貌的工作叫“業(yè)務(wù)建模”，如果說反映冰山浮在水面上的部分是需求，那么“業(yè)務(wù)建?！本凸蠢粘稣麄€冰山的全貌。構(gòu)造業(yè)務(wù)模型是架構(gòu)師的基本功之一，一個好的架構(gòu)師一定會做“涉眾利益分析”，將產(chǎn)品設(shè)計得符合用戶真正的需要。

很多朋友可能認(rèn)為，用戶需求主要來自用戶（代表）的口述或者訪談意見，其實這是個誤解。在另一個省廳做無紙化辦公的項目時，為了得到這些“隱含”的業(yè)務(wù)信息，在征得同意后，采取了以下方法：

觀察關(guān)鍵崗位，記錄操作人員的日常行為。

查閱了兩年內(nèi)所有文書檔案材料（絕密除外）。在文書材料的手跡當(dāng)中，我們看到了很多不在“明面上”的東西。比如過程中的周期性工作（例如一年才發(fā)生一次），這種用戶在反饋中遺漏的事項。進(jìn)一步地，我們還看到了矛盾、爭論、政治因素等這些用戶不會說出口的部分。

分析這些業(yè)務(wù)數(shù)據(jù)，并勾勒出了業(yè)務(wù)的全貌后，我發(fā)現(xiàn)來自于直接收集的“明面”需求-包括用戶訪談和需求描述材料中的業(yè)務(wù)信息不到20%，大約80%以上的業(yè)務(wù)需求來自于各種觀察和材料檢索分析。這是一個稍稍令人吃驚的比例，但足以說明業(yè)務(wù)建模工作的重要。

2. 讓軟件真正地“靈活可塑”

上一節(jié)我們講了業(yè)務(wù)建模，將業(yè)務(wù)模型化，不僅可以把需求做深入，更重要的是業(yè)務(wù)模型可以引導(dǎo)我們做出好的軟件設(shè)計。

做產(chǎn)品也好，做項目也好，研發(fā)人員厭惡的事情會有很多—比如趕進(jìn)度、調(diào)錯、維護(hù)別人的代碼等等。但是，最為深惡痛絕的事情，無疑就是變更需求。只有符合用戶業(yè)務(wù)模型的設(shè)計，才能在頻繁的需求變更下保持穩(wěn)定。

就如上面提到的無紙化辦公項目中，一樣碰到了需求的復(fù)雜變化，以及用戶的業(yè)務(wù)多變。

最終，我們丟掉了數(shù)百頁的需求和流程描述；放棄了之前開發(fā)好的所有功能（這些功能曾被反復(fù)詬病不夠靈活）；放棄了過去那種按局長、處長、科長等分別設(shè)置角色進(jìn)行授權(quán)的權(quán)限模型—這些頭銜僅僅只是人員的屬性。人員的權(quán)限實際上是受任務(wù)決定的，這才是真實的業(yè)務(wù)模型（若干年后，才知道那叫TBAC權(quán)限模型，也就是基于任務(wù)的權(quán)限模型，早已作為理論被國外軟件科學(xué)家提出）。

而基于不變的用戶責(zé)任模型，我們抽象出了基本的職責(zé)行為模型，然后將可變的業(yè)務(wù)歸納到了一個配置層中。也就是說，不是直接去實現(xiàn)業(yè)務(wù)功能，也不假定用戶具有什么職務(wù)就能干什么，而是將復(fù)雜的業(yè)務(wù)功能拆解成幾個基本行為。然后用配置層將這些行為組合起來供用戶使用，就像搭積木一樣。

這樣開發(fā)出來的軟件，做到了原先根本不敢想象的事情—用戶上午找我談心的業(yè)務(wù)流程和想法，下午兩點上班后，立刻就在系統(tǒng)中能夠使用這個功能。這種敏捷和響應(yīng)能力，堪比“飛機(jī)在飛行中更換發(fā)動機(jī)”，這讓用戶非常滿意。

更為難得的是，數(shù)年后，包括我在內(nèi)的幾名開發(fā)骨干陸續(xù)離開了那家軟件公司，這家軟件公司也不復(fù)存在了。然而，這套沒有人維護(hù)的系統(tǒng)一直被用戶保留了下來，至今已連續(xù)工作了近15年，期間沒有經(jīng)過大的升級和開發(fā)?，F(xiàn)在依然每天有數(shù)百人在操作和使用，累計運行數(shù)據(jù)也有了幾十TB。

軟件沒有針對用戶的“具體需求”來設(shè)計，而是通過抽象的模型來設(shè)計開發(fā)。能夠十幾年無需升級而滿足各種業(yè)務(wù)變化，無疑是那套抽象了所有業(yè)務(wù)模型的配置層帶來的。

然而并不是所有的項目和產(chǎn)品都能像這個項目一樣完美收官。在項目過程中，我們還認(rèn)識到要實現(xiàn)業(yè)務(wù)靈活性的重大代價。因此，不要讓完美主義耽誤了時機(jī)，畢竟天下武功，唯快不破，很多時候客戶需要的是及時響應(yīng)而不是完美無缺。

3. 非功能性的問題也對架構(gòu)有著高要求

隨著系統(tǒng)規(guī)模越來越大，單純做好業(yè)務(wù)模型和業(yè)務(wù)設(shè)計，并不足以保證軟件的成功。隨著架構(gòu)工作的深入，架構(gòu)師需要一一或者說不得不更多考慮非功能性的設(shè)計要點。

2011年，我參加了某省移動通信公司BOSS系統(tǒng)升級和重構(gòu)項目。所謂BOSS系統(tǒng)，是行內(nèi)的一個叫法，正式名稱是Business&Operation Support System，在通信行業(yè)，一般分為四個部分：計費及結(jié)算系統(tǒng)、營業(yè)與賬務(wù)系統(tǒng)、客戶服務(wù)系統(tǒng)和決策支持系統(tǒng)。

這樣的一個系統(tǒng)，是由我當(dāng)時所在的公司杭州、南京兩個研發(fā)中心加上北京研發(fā)中心的部分專家，有數(shù)十個團(tuán)隊參與開發(fā)和測試，近百人在現(xiàn)場進(jìn)行系統(tǒng)集成。我當(dāng)時負(fù)責(zé)的是營業(yè)與賬務(wù)系統(tǒng)和部分計費系統(tǒng)的核心框架設(shè)計。

我們對營帳系統(tǒng)的交易鏈路進(jìn)行壓力測試。測試的結(jié)果不容樂觀，服務(wù)整體并發(fā)性能未達(dá)到客戶要求的數(shù)據(jù)，接下來要推動整個系統(tǒng)的性能優(yōu)化。這個任務(wù)的困難在于大型分布式系統(tǒng)關(guān)系錯綜復(fù)雜，整個營帳系統(tǒng)的鏈路是一條很長的集群，涉及到另外兩個系統(tǒng)的調(diào)用，同時每個系統(tǒng)內(nèi)部都有好多組件，彼此形成了復(fù)雜的調(diào)用關(guān)系。而大多數(shù)組件來自不同團(tuán)隊，我們團(tuán)隊提供的RPC框架和基礎(chǔ)框架只覆蓋了65%的組件，剩余來自其他省市研發(fā)團(tuán)隊的組件架構(gòu)不明，設(shè)計也完全不了解。在這種情況下，我認(rèn)為需要解決以下問題：

1. 搞清楚每個測試案例的調(diào)用鏈順序。在核心調(diào)用鏈上，應(yīng)該將非核心的系統(tǒng)剔除。

2. 造成整體鏈路性能不佳的短板在哪里？

3. 找到存在性能短板的組件后，如何發(fā)現(xiàn)性能瓶頸。

針對問題1，我們基于RPC框架輸出結(jié)果的分析，初步完成了一個調(diào)用關(guān)系圖，然后配合軟件設(shè)計文檔，編寫流量轉(zhuǎn)發(fā)代理工具補(bǔ)充完整了調(diào)用鏈路圖。

問題2，我們在RPC框架基礎(chǔ)上增加了分析模塊，自動對每次吞吐的數(shù)據(jù)量進(jìn)行記錄，還用于分析響應(yīng)時長排名、報文長度等Top10等，根據(jù)排名情況列出一大堆所謂“慢接口”，但是我們不能因為一個接口慢，就認(rèn)為它有問題。我們針對數(shù)據(jù)庫的訪問研發(fā)了自己的ORM框架，解決了一部分慢性能問題。

問題3，我們發(fā)現(xiàn)慢的接口往往集中在幾個組件上，這和這些組件的設(shè)計質(zhì)量有一定關(guān)系。

這個故事告訴我們，大部分研發(fā)團(tuán)隊在項目之初對非功能性的特性考慮往往不多，架構(gòu)師在設(shè)計技術(shù)架構(gòu)時，需要成為軟件質(zhì)量底線的保障者，讓軟件具備足夠的自我糾錯能力，以及一致的可集成、可維護(hù)的能力。

走出成為架構(gòu)師的關(guān)鍵道路

1. 追根，抽象，把握事物本質(zhì)

在過去的經(jīng)歷中，促使我從普通的編程者向架構(gòu)師轉(zhuǎn)變的根本因素，我認(rèn)為是一種試圖追尋事物本質(zhì)的好奇心。這種好奇心是促使人思考和訓(xùn)練思維的源泉。人類的大腦在記憶力和理解力上是有其局限的，因此人不得不通過抽象，屏蔽事務(wù)的無關(guān)要素和細(xì)節(jié)，才能把握事物的本質(zhì)。

中國古代哲學(xué)中，有很多這一類思辨，比如—“時有風(fēng)吹幡動。一僧曰風(fēng)動，一僧曰幡動。議論不已?；菽苓M(jìn)曰：非風(fēng)動，非幡動，仁者心動?！睂τ谶M(jìn)修禪心者來說，直指人心的思辨，毫無疑問抓住了問題的本質(zhì)。因為在參照系為“人心和佛性”的禪學(xué)中，世界的本質(zhì)已經(jīng)“不在你的心外”（王陽明語）。參照系的不同，帶來的結(jié)論也就不同。哲學(xué)中相對與絕對、運動與靜止、唯心與唯物、存在與虛無都有很多對思維的訓(xùn)練，通過思辨，能提升個人的思維抽象能力，因為抽象是哲學(xué)思維的基本特征。

2. 不停的學(xué)習(xí)和傳播知識

在技術(shù)架構(gòu)中，各種架構(gòu)方法可能是大家容易關(guān)注到的—面向?qū)ο?、面向模式、自頂向下分解、自底向上分層等等，從馮諾依曼體系到通信協(xié)議、UML等有很多設(shè)計方法和架構(gòu)理念可以學(xué)習(xí)。

但是在做業(yè)務(wù)分析和設(shè)計時，如何考慮業(yè)務(wù)模型，如何兼顧涉眾利益？大家都知道人性是復(fù)雜的，但是在組織內(nèi)部，人的行為和動機(jī)是有軌跡的，人類所表現(xiàn)出來的無外乎正常成年人的社會人格和動機(jī)，而這正是普通心理學(xué)和組織行為學(xué)的研究范圍。所以做業(yè)務(wù)架構(gòu)的伙伴要去學(xué)一些這方面的知識。其實老祖宗早就告訴過我們，“世事洞明皆學(xué)問，人情練達(dá)即文章”就是這個道理。

架構(gòu)師無法“獨善其身”，缺少了實現(xiàn)架構(gòu)的研發(fā)和項目團(tuán)隊，架構(gòu)就會成為空中樓閣。因此，成功的架構(gòu)師只有讓組織成功才能真正的成功。架構(gòu)師要樂于將自己的知識、想法和同事、朋友分享。如果孤芳自賞，那就沒有了用武之地。

3. 追求簡約與平衡的架構(gòu)之美

大多稱為架構(gòu)師的人，都有追求完美的偏好，但實際在項目和產(chǎn)品開發(fā)中，既沒有機(jī)會，也沒有必要實現(xiàn)完美的架構(gòu)與軟件。因為完美就意味著脫俗，脫俗就意味著無先例、無參照，這往往會帶來巨大的風(fēng)險和不可控因素。

KISS原則是架構(gòu)師要注意遵循的一個原則，因為越復(fù)雜的東西就越精密，越精密的東西在工程中就越不可靠。尤其在分布式系統(tǒng)設(shè)計中，異常和故障的可能性太多了。將系統(tǒng)設(shè)計得絲絲入扣而沒有任何預(yù)防措施，那么一旦出現(xiàn)任何意外，異常情況就會像滾雪球那樣蔓延開來，直到整個系統(tǒng)奔潰。在二戰(zhàn)中，德國的坦克大量使用交錯式負(fù)重輪。這是一種非常復(fù)雜的機(jī)械構(gòu)造，性能優(yōu)良，穩(wěn)定性好。然而就是生產(chǎn)復(fù)雜，維修繁瑣，產(chǎn)量輸給對手老大一截，而且容易出故障。據(jù)記載，虎式、豹式坦克的戰(zhàn)損率和機(jī)械故障發(fā)生率幾乎相等。種種因素下，性能強(qiáng)悍的虎式、豹式最終只能被淹沒在廉價坦克T-34的海洋之中。

架構(gòu)師最終需要站立在大地上，才能仰望天空。平衡好成熟技術(shù)和新技術(shù)之間的關(guān)系、平衡好硬編碼和業(yè)務(wù)引擎之間的取舍、平衡好性能與資源占用之間的矛盾等等，這些都是架構(gòu)師需要把握的。這種平衡往往來自于環(huán)境需求，而不應(yīng)當(dāng)是架構(gòu)師的個人喜好。比如在預(yù)研性的項目中，可以適當(dāng)采取更激進(jìn)的技術(shù)策略，但是對于有緊迫上線時間要求的產(chǎn)品，就需要更保守和穩(wěn)妥的解決方案。

所謂平衡，并不是平均，更不是平庸。而是在所處場景中，態(tài)度鮮明地取舍—在性能中取舍，在功能中取舍等等。這種存乎在心的取舍最終會形成架構(gòu)師獨特的審美，這種審美源自環(huán)境（或者場景）與架構(gòu)的和諧。這種和諧之美體現(xiàn)在業(yè)務(wù)整體，而不是來自于某頂高精尖的局部構(gòu)造—就像我們在山林中搭建的小木屋和在都市中搭建的混凝土大廈一樣，如果交換了場所，那就失去了和諧之美。

回顧與總結(jié)

在軟件行業(yè)工作，就是在多變的需求、緊湊的工期、古怪的bug中不斷掙扎的過程，回首過往，十余年來很多同事在這樣的顛簸中或轉(zhuǎn)型管理、或轉(zhuǎn)型售前、或離開了這個行業(yè)，這是非常遺憾的。對于我們很多人來說，在邁過所有這些坎坷后，就會發(fā)現(xiàn)軟件開發(fā)工作是“踏遍青山人未老，風(fēng)景這邊獨好”。

回首向來蕭瑟處，也無風(fēng)雨也無晴。當(dāng)你真正體會了這個行業(yè)的酸甜苦辣之后，還有什么能讓你放棄這個職業(yè)呢？

--是“枯燥的編碼生活”嗎？不，怎么會有人覺得編碼枯燥呢？多年來，我內(nèi)心一直以作為碼農(nóng)自豪，堅持每天寫代碼。最能體現(xiàn)軟件從業(yè)人員“像上帝一樣”編排一切的工作，無疑就是編碼了。你從哪里還能得到創(chuàng)造一個世界那樣的滿足感？

--是“用戶頻繁的變更需求”嗎？不，每個用戶都是理性的體驗者，他們追求的一直都是更好地完成業(yè)務(wù)，流水般變動的只是業(yè)務(wù)的形態(tài)，始終如一的是管理學(xué)、組織行為學(xué)和普通心理學(xué)作用下的業(yè)務(wù)本質(zhì)。領(lǐng)會到這一點，你會從用戶的微笑和感謝中找到前進(jìn)的動力。

--是“繁重到不加班就完成不了的任務(wù)”嗎？不，任何成就哪有不經(jīng)過汗水和痛苦就能達(dá)到的呢？辛苦和汗水帶來的不僅僅是疲勞，還有榮譽(yù)和滿足感。

堅持走技術(shù)發(fā)展的道路，用技術(shù)手段解決客觀世界的問題，然后在軟件設(shè)計和編碼的汪洋大海中尋找樂趣，這是所有軟件技術(shù)人的最好歸宿。最后，我希望有志于成為架構(gòu)師的年輕人能在技術(shù)軟件研發(fā)和架構(gòu)的道路上堅持下去，直到體會到真正樂趣的時刻。