走出軟體作坊之十七－走鋼索的人

     架構師是個很神聖的詞。蓋茨，世界首富。微軟，世界最大最富有的軟體公司。蓋茨是微軟的首席架構師。

      好多程式設計師流口水，一聽某人是架構師，就兩眼發亮，比技術總監的頭銜還要厲害。

      一想起架構師，大家就想起那些UML設計工具、類圖、時序圖，想起那些水泥大樓的框架和地基，想起了那些

      如百變金剛的開發平臺，想起了那些讓人眩目的反射、後設資料、FrameWork、設計模式、物件導向、重構。

     很多人想當架構師，感覺架構師是技術職業發展的最高境界，在往上走就有管理職能了，如技術總監和CTO或研發總裁之類的頭銜。

     李維先生曾經有過一次演講，講到了一個架構師應該具備的特性：

      1核心軟體技術。要攻克資料庫設計問題，必須深入瞭解資料庫的工作原理，而不是會寫複雜的SQL會管理個

     備份會設計個表結構就算精通資料庫。有人甚至把會用hibernate\structs\spring當作自己會核心軟體技術。

      2產品特性。你學了那麼多核心技術，到底要幹嗎？我一直在商業軟體公司工作，沒有在研究所工作過。我各種技術要做到的就是幫助企業軟體生產，如何更快更省力氣質量更好市場競爭力更強。我總是以這個原則來驗證一項技術是否對於我的工作來說而實用。現在技術多如牛毛，在各個層次各個領域解決著各個環節的問題。如果不以解決自己工作中的問題為圓心，很容易陷於到大量學習卻越來越茫然找不到出路的境地。

      3軟體趨勢。在企業管理軟體開發領域，往往會見到這樣的現象：不少開發人員精通客戶業務需求，深入第一線做客戶實施。他們學習技術也是為了解決現有手頭的問題。尤其企業管理軟體開發領域，技術要求並不高，而如果不瞭解客戶需求，開發的軟體實用性就不強，即使你的功能開發的又效能好又安全性好也沒實用意義。所以，不少在企業管理軟體開發領域工作多年的開發人員，形成了技術輕視觀，甚至有種核心技術學習無用論的思想。但企業管理軟體開發領域，經過十多年的發展，已經面臨了不少挑戰。但是很多人覺得那是大環境的事情，大環境不是一個人一個公司能改變能影響的。大環境變，我們們就跟著變。大環境不變，我們也照舊。但是，我已經經歷過了很多時代，見證了很多遺憾，大環境發生改變了，自己卻跟不上了。

     DOS\WINDOWS時代、單機\區域網時代、網際網路時代、移動增值時代。每一個時代都出了黑馬，賺取的金錢突然高出傳統模式數倍，而傳統模式者還是在繼續走傳統模式，辛苦的賺錢，而且隨著價格戰的加劇，越來越辛苦，但還不思改變者並且還認為不可改變者大有人在。

     4創新技巧。我們往往會遇到這樣的情況：要解決手頭的問題，擺在面前的有N種技術方案。選擇哪個都有缺點，綜合來用又感覺牛刀殺雞了。有時候，我們還會遇到另一種技術選擇，未來的軟體趨勢一定是那樣那樣的，但現在還沒有達到，現在的技術方案都是過渡期的，所以我們還要等。否則利用現在的過渡期技術，開發出來就被淘汰了。如果是這種以現狀看技術的思路，不管技術發展到什麼階段，都有遺憾，都在向未來的未來過渡。所以，作為一個架構師，比別人厲害就厲害在，總是能把手裡這些技術巧妙的利用，以解決自己的問題。當然，你想把你手中的技術能用活，你必然是理解這項技術的來龍去脈和這項技術的適用領域，還要深入理解這項技術的工作原理，還要清楚的認識到你要解決的問題領域，否則，你無法把你的技術和你要解決的問題結合在一起。

      我對李維先生的這四點講述頗為讚許。架構師總是遊走在技術和業務之間，既要相容軟體歷史不能割裂又要面向未來發展，所以我老把架構師稱為走鋼索的人。

      很多人也想成為具有這樣特性的架構師，但就是不知道該怎麼走這條路。我就講講我的經歷。

     我剛出道的時候，很快成為公司技術出眾的程式設計師。有人跟蹤除錯了一下午也找不到錯誤的，找我；有人不知道這個錯誤是怎麼引起的，找我；有人不知道某個需求怎麼實現程式碼方便，找我；有人要優化資料庫效能，但怎麼都速度提不上去，找我；有人要修改一段超複雜的程式碼，怎麼也理不出來，N多判斷和函式巢狀，腦袋思考不過來了，對程式碼的複雜度掌控不了了，找我；我就跟一個活雷鋒一樣，大家也好像覺得我就是個活字典，有技術問題找我總沒有錯。就這樣，我在研發部有了很好的技術信任，也有了很好的人緣。

     而架構師要做的工作，是許多人工作的基礎。如果沒有很好的技術信任，大家怎麼敢把他們的工作搭建在你的基礎之上。如果沒有很好的人緣，大家怎麼願意把他們的工作搭建在你的基礎之上。就是由於我解決了很多業務開發的問題，我瞭解了很多業務開發的現實狀況，並且還能提出簡潔有效的解決方法，而且解決方法不死板不鐵板一塊能保持獨立靈活通用性，給其他人的工作帶來了很好的工作效率，所以領導才信任我能做好這一塊，並且適合做這一職位。不是隨隨便便一個人深刻學習了核心技術，然後申請領導要當架構師。

      其實，我開始做的也僅僅是公共程式碼員。但是，很快面臨了一個尷尬。

      簡單的，雖然可能每個開發組都重複寫同樣類似的程式碼，但是由於簡單，所以每個業務開發組都自己寫了。

     複雜的，往往業務開發組組長都認為這個功能是自己這個組的個性功能，所以還是自己寫。

     所以，只有人們解決不了來找我時，我才能上場。

     這乾坐著不是回事。我得自己想轍。

      於是，我在忙“公益事務”做活雷鋒之餘，看到他們在扎堆開會我就主動去旁聽。每次我都能提出很獨到的見解。並且能幫助他們寫公共抽象程式碼，能幫助他們提高不少工作效率。所以他們非常願意讓我旁聽，並且聽取我的意見。我也能很快寫完讓他們用。他們一用，發現果然好用，而且不用他們自己寫程式碼了，功能實現的還非常巧妙公用，效能也好穩定性也好擴充套件性也好。到後來，每次開會都主動叫我。這樣，我的工作就越來越多了。

     隨著各個業務組不同差異的需求都希望我來幫他們抽象出公共的，我就在思考我手裡的這部分程式碼。我不能今天他們提一個我寫一個。他們倒是輕鬆了，但我手裡就好似一盤散沙一樣。於是，我不斷重構我的公共程式碼，架構體系框架就這樣慢慢成型了。各種各樣公共工具，除錯工具、優化工具、動態設計工具，凡是能幫助業務開發組人員加快效率的，我都做了工具或寫了公共函式DLL。儘量簡單易用，不讓他們覺得麻煩或不順手。

      過去，各個業務開發組過去是開發人員素質不齊，有人責任心強，有人隨意；有人細心，有人粗心；有人理解客戶業務深刻，有人理解不深刻。所以開發出來的質量良莠不齊。自從這樣做了以後，各個組寫的程式碼少，很多都是我寫的公共程式碼。我的技術好，寫的程式碼質量高，而且是公共的，有錯誤，一改，大家都沒有問題了。所以我們整體的軟體產品的產品質量、生產速度都提高了不少。

      我發現，大家越找我，各種需求交織在一起，越複雜，我就越需要更深入的學習技術，深刻理解各種技術的差異性和適用領域，去思考各項技術的發展歷史、未來趨勢，並且自己做DEMO，看能不能更好的解決大家的問題。因此，我的技術能力也越來越高。如果我不去解決這些不去第一線想也想不到的客戶需求，我根本就想像不出我某項技術還能這樣用。

     這就是我的螺旋上升之路。

     我那天重翻上個月的《程式設計師》雜誌，看到了我朋友周愛民寫的一篇《做人、做事、做架構師-架構師能力模型解析》，他也提到四點，技術能力、業務能力、人際關係、個人內在素質。和我的情況很類似。

      有一部分所謂的架構師，技術超深厚，框架堪比Spring之類，但自己一個人悶頭寫框架不斷優化，力竭使用最先進的技術思想，希望把最豪華的設計模式融進去，希望把OSGi融進去，希望把AOP融進去，全無視那些想利用框架減輕自己工作量提高自己工作效率的應用功能開發同事。這是在用公司工資玩技術呢，還是在滿足個人技術幻想呢，還是在實驗呢？到底在幹嗎？價值在哪裡？

      還有的人不會推廣自己的框架。不善言辭，就幻想著技術總監能夠通過行政命令讓大家必須用框架，能不自己寫程式碼就不自己寫程式碼，能交給框架做的就交給框架做。但技術總監號召完了，大家仍然我行我素，各自開發為政，讓框架開發者很孤單。

     還有的人也不會推廣自己的框架，沉迷在自己的理想世界。好不容易技術總監召集大家讓大家來聽聽框架如何應用，但自說自話，滿口自己最得意的詞彙，聽得業務功能開發人云山霧罩。大家問些問題，如這樣的業務開發難題，框架怎麼解決？於是，框架開發員就和業務開發員爭論了起來。框架開發員覺得這根本就不能答應客戶這種變態的需求，而業務開發員說這就是現狀。框架開發員說你可以這樣這樣，業務開發員說這樣太麻煩，框架開發員立刻還口這還麻煩？於是雙方各執一詞，框架也沒推廣成功。

      我手底下有個框架開發員。他的技術渴望很強烈，為了技術難題攻克，可以不吃不睡。並且技術敏感度很強，學習也快。所以當時我感覺他是個程式設計師的料，就把他拉到我的手下。

      但是有個問題，他寫出的框架程式碼，在平時開發業務功能的時候挺麻煩。大家可能需要的是一把鐵鍬，但是他卻給大家N根不同長度不同粗細不同材質的木棍，N個不同形狀不同用途的鐵鍬頭。大家會有N種組合。不僅導致他寫程式碼老超任務期，而且也讓使用人感覺沒多大幫助。使用起來複雜，而且還得配置這個配置哪個，需要注意的地方太多。業務開發組的同事就不願意用，還不如把程式碼自己直接寫死了得了。超期還會影響業務功能開發組的使用。本來人家是為了想加快自己的工作效率。你答應好這個星期給業務開發組提供一個功能，但你沒有拿出來。就耽誤人家進度。你多次拿不出來，人家業務開發組還不如自己開發一個呢，求人不如求己。

      我最後警告他：如果你認為自己技術夠牛，那麼你必須證明你能很快做出來。如果你認為自己技術夠牛，最好能牛到，只提供一個函式就解決了他們的問題。別這個代理類，那個聚合類，這個唯一例項類。最好連引數也沒有，大家呼叫一下寫一句程式碼就OK。甚至你做的好，大家都不用呼叫你的程式碼，你可以包含在基礎框架中，你自己去判斷什麼時候什麼應用需要執行這個動作。如果你認為自己技術夠牛，那麼在業務功能需求發生變化的時候，你能夠保證介面不變的情況下還能適合變化，這才你夠牛。別讓業務開發組的人跟著你也得改他們自己的程式碼，那樣的設計就很爛了。

      小夥聽了我的話。進度保證，程式碼介面簡潔。

      他說，你真高。我感覺現在我的技術比過去進展飛快。看來人不逼，是不會自己創新更好更快的方法的，老認為自己現有的方法已經不能優化了。我現在發現，很多我過去寫的東西還可以做的更好，我準備在開發任務之餘優化程式碼，但肯定保證不影響大家，介面還跟過去一樣，我要重構一下。

      我對小夥的成長感到欣慰。

      但是，小夥還有一個沒有逾越的鴻溝。這個問題不解決，我知道，他不會成為一個真正的獨立的架構師。

      我複查過他的程式碼，由於他對業務沒有深刻理解，所以考慮了N多種情況，給自己以後的修改留下了後路。但也因此程式碼量大，開發週期長無法適應越來越短的客戶需求響應時間，可閱讀性不強，功能複雜，穩定性困難。但我從客戶行業出發，很多情況他其實都是自己假想的，而且想錯了。

      我指出了他的問題。他問我該怎麼學習業務，他又沒有機會到客戶一線去實施，也不接聽客戶電話，客戶需求都是業務開發組的人跟他說的。

      最瞭解客戶業務的，是在一線做客戶諮詢、做客戶實施的人員。其次是做客戶定製化、客戶服務支援的人員。最不瞭解客戶的，就是架構組的人員。但恰恰要命的是，架構組的人員做的功能是大家的工作基礎，如果基礎設計錯誤，那傳遞的“牛鞭效應”破壞力就很大。所以，架構必須瞭解業務。

      我瞭解業務的思路，和我瞭解技術是一個思路，都是來龍去脈法，研究一項事情的過去、現在、未來，以及和這件事情關聯的其他事情，研究方法也如法炮製。

      你要製造的是卡車還是轎車，你得明確好。你是要造100萬的轎車，還是5萬塊錢的轎車，也得定好。你是要製造一輛可以自由改裝的轎車呢，還是一輛只可以大致改裝一些的轎車的，也得定好。這些疑問，都是和我們們面臨的客戶有關。而我們能面臨什麼層次的客戶，和我們們公司的實力、品牌、組織規模、盈利要求有關。

      你如果是一個小公司，想做百萬大單隻能做的一蹋糊塗。你如果是個大公司，你老去競爭那些5萬塊的小單，做一個賠一個。所以一個公司的出身就決定了它的競爭地位和它的目標群。我們要為這個目標群服務，所以我們就不要做一個百變金剛的架構。公司有公司的目標，公司招了你給你付工資，就是為了讓你為目標客戶群服務。如何更快更好更有質量的服務，就是公司的目標。我們就是為了幫助公司實現這個目標。

      我一般都是把我們這個產業的競爭格局現狀瞭解清楚，我們的過去現在，競爭對手的過去現在都瞭解清楚。然後我去研究我們的客戶行業的競爭格局、層次現狀。看看這個客戶行業盤子，三教九流到底多大多複雜，

      我們現在是佔了多大，我們還能佔領哪些客戶群。

      然後我就研究客戶行業目前的挑戰、機遇、困境。能解決其中一兩個問題，就是我們們的競爭亮點。如果作為軟體一點都解決不了這些業務困境，我就思考如何讓產品做的更易用。微軟不就靠著易用發家的麼？

     最後我會去研究我們公司現有的研發優勢和弱勢、實施服務銷售的優勢和弱勢，找到適合我們突破的地方，具體歸研發能承擔能起作用的事情，我就會去動員做。脫離現實資源現實矛盾現實包袱的改良，是無法做到改良的。

      我還關心各種新的技術應用。可能這項技術很久了，但大家都沒有想過還能這樣用。所以，我常常在媒體上關注這些、思考這些、在論壇上和業界交流這些。對於新的技術，要研究原理，要嘗試，但不要衝動引入到商品生產中。我們不是自己在創業在玩在實現自己的夢想。我們承擔的是公司所有人都要吃飯的產品。如果有閃失，這麼多人以及他們的家庭都要受到影響。這不是鬧著玩。

      當我研究完業務領域的這些大的框框以後，每逢有業務同事跟我交流客戶需求，我總能把這個需求和我的業務框架聯絡在一起，把這個需求歸好類。並且能判斷出這個需求是個反趨勢的需求，還是個短期眼光的需求，還是個長遠發展的需求。

      很多人都在抱怨說需求老變化。其實，不是客戶需求在變，而是你對客戶的需求老是不同思路去理解。我心中有業務框架，有過去，現在，未來，所以能識別出一個需求是穩定的還是臨時拍腦門想出來的。有時候，有人向我提一個需求，我會眼睛一亮，對，這個需求符合未來發展，我就會很快加入。所以，我曾經在做實施經理的時候，老是能很容易說服客戶，讓客戶聽從我的意見，就是由於我想的比他們還要遠還要周全。好多程式設計師說客戶非要某個功能不做不行，就說明這個程式設計師並沒有理解客戶。客戶並不是那個非要和你作對的人，他只想解決他的問題。可能你不理解他的真正根源問題而且你又提不出更好的方案，所以他要跟你急，要讓你必須實現某個功能。

      只有你不斷遊走在業務過去現狀未來與技術過去現狀未來，你做的架構才是真正的實用、彈性、易用，而且最小成本，不走彎路，不多花開發精力。

     我們需要架構，不就是為了達到這個目的麼。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780914/viewspace-445620/，如需轉載，請註明出處，否則將追究法律責任。