美國夢之十: 羅德島的一周
文章來源: 獅子羔羊2016-04-19 09:30:30

羅德島的工作是我在Kansas City 時經同事朋友S推薦,那個項目的CTO找我。鑒於以前在軟件工廠的事情上與項目架構師理念相左有些不愉快,所以我在接受項目之前與CTO明確表示我不看好軟件工廠的嚐試。他們找到我的原因是原架構師以三個小時時差,不願意長期出差為由要求換項目。後來發現情況並不是那樣簡單的。

 

周一到了羅德島DMV總部,進了辦公室就發現有些什不對勁的地方。從人事結構上在項目CTO與我之間多了個總架構師,此公是EDS的老員工,大概有六十出頭了。Visual Studio長什麽樣子都沒見過也不想見,更不用講如何設計如何提高了。為了突顯他的作用,他禁止架構組(其實就是我和我的朋友S再加一個新手)與開發人員溝通,開發組不允許我們進入開發環境改程序。另外一條規就是不允許我們直接向開發組或項目CTO發電郵,一切都要通過這位老人。

 

開始我以為他說說玩的,仗著我的技術水平和與開發人員的私交,我還是一如既往地與開發人員摸爬滾打,與他們討論,與他們一道看程序。交談中我了解到不允許架構組碰開發組的代碼是因為那個新手在老人的指導下弄壞了係統影響了項目進程,不得以而為之。架構組和開發組的溝通合作近乎於零。

 

而禁止我們向CTO發電郵則是老人怕我和我的朋友架空他。可是要想向這位老人解釋一個技術問題那可是難於上青天啊!

 

項目到了這個時期,任何從架構組來的改動建議都是不被開發組歡迎的。這一點我的朋友沒有認識清楚,他從技術的角度上指出許多問題,有架構方麵的,有執行性能方麵的。這造成了他和開發組的關係緊張。而我與他之間一直由於互相欣賞對方的技術水平,一直是好朋友。在為他寫的年終評定上我這樣寫道:S是我一道工作過的最有才華的程序開發人員。我會毫不猶豫地歡迎他來參加我的項目,也會毫不猶豫地推薦S到任何困難的項目中去。S對我也是尊敬有加。這也是他向CTO推薦我的原因。我們兩個的緊密合作讓一事無成的老人倍感不安。以前由於級別的差別他還能壓住S,再加上S與開發組的關係不好,沒有人挺他,S做得有些憋屈。我來以後,一來我的技術級別隻比老人低半級,另外我與開發人員的關係良好。技術上又更高一層。在他看來我可能是潛在的威脅。

 

麵對這樣巨大的係統如果有人告訴你幾十個小時甚至幾百小時他就能大規模地改進係統設計和性能,你千萬不要相信。因為那絕對不是真實的斷言。說這個話的人要不是無知而無畏,要不就是無信而信口開河。可是HP(EDS)的上層就特別喜歡這樣的建言,不停地找捷徑,最後浪費的時間就是好好做都已經差不多了。當時由於係統執行性能不夠需求指標,在不改進數據庫設計和大麵積地改進設計是不可能有顯著的改觀的。

 

這位老人是真的不懂還是裝著不懂就不得而知了,反正他就是一味地逼迫我們拿出“可行”的方案來。在他來說“可行”在短期內解決,用另外一種說法就是變魔術。當我們告訴他他所想像的方案不存在時,他表示了極大的不滿,在他看來,我們是有意與他過不去。當我們給他微軟的文章以證明我們的規點時,他也不讀,還說“你們不要給我事做,我不要讀這些文章,你們是專家,給我我要的答案就好”

 

由於大樓裏的空調係統出了問題,比深秋的外麵還冷,第二天我就病了。為了不使病情繼續嚴重和不影響他人我在酒店工作。那正好是老人喜歡的,我正好不能與開發人員溝通了。

 

周二的早晨我參加了一個由老人招集的架構小組的電話會議,連我一共四人參加,由老人主持。由於我早晨去藥店買藥的原因,我打進那個電話遲了五分鍾。打進後聽見老人在和我的朋友討論係統性能問題,我覺得不便打岔,就靜靜地聽他們討論。聽了一會兒我覺得我在他們討論的問題上可以插上話了,說:“對不起噢,剛才打進來聽你們討論沒有打岔就靜靜地聽了一會兒,現在可不可以也讓我有機會與你們分享一下我在這個問題上的看法?”出我預料之外的是老人生氣地打斷我的說話,斥責我道:“你聽了多久了?聽到了什麽?你這樣打進電話會議不報名的做法是很不專業的做法。以後打電話一定要先報名!”

 

那一刻,我整個人坐在那裏,所有的思維都停止了,不知道如何應對。一是我從未有過偷聽之心,二是在這之前我在HP參加過無數次電話會議,有我遲到的,更多的是別人遲到的,從未聽過有這樣的說法,頭腦一片空白。停了近三十秒鍾,我誠懇地說:“對不起,我剛才主要是不想打攪你們的討論,絕無偷聽之意。不過我以後一定注意,一定先自報姓名。”我這樣低姿態了後,他仍然不依不饒地說:“這是一個人的品德的問題,我要求你認真對待。工作中一定要確保專業精神。”

 

我因為確實沒有此意,不願再就此糾纏,就連連稱是,總希望能有機會讓我講技術問題。就這樣一來一去致少有十分鍾。最後終於讓我講技術問題了。

 

我侃侃而談地說了我的見解。奇怪的是說完後老人就停止了討論並要求我把我講的內容成文發給他。我對這個係統了解之深,與開發人員的關係又好,我所了解到的事情是他們不知道的。什麽方案可行什麽方案不可行隻有我知道。出於專業精神我並不介意與老人和小組裏的其他人說。但是後來我發現老人根本什麽都不懂,我說了也白說。他要我成文是他無法理解我所說的自然也記不住,但是我若成文了他就可以剪貼一下轉賣他人,貪功己有了。我嘴上應著他,心裏並不準備去做。心想:都跟你說了,還搞不定,還想轉賣,過份了。

周二晚上我研究了整個原代碼,整理出了一個程序質量報告,發給了CTO並所有架構組成員。從我而言雇我的是那個CTO,我給他發報告理所當然,我也不瞞著別人,做得光明正大。

 

誰曾想這觸發了老人的神經。周三晨會上他大發其火,問我什麽動機,為什麽不先發給他看。周二讓我成文的東西為什麽還沒有寫出來。最後問我怎麽理解那個報告。

 

我解釋道:開始時CTO與我談話時要求我有什麽的發現隨時與他聯係,所以我剛剛整理出報告覺得有些問題就隨即發給他了。因我覺得一是可能大家也有興趣或者見解,二是我也沒有什麽可瞞著的,所以發給了大家。致於怎麽理解嗎,這是用微軟工具掃描源程序而得,裏麵說的每一問題都有一個問題號,用這個問題號在微軟的網站上查都能找到詳細介紹並且還有解決方案。說著我就把微軟在MSDN裏相關的網站地址發了給眾人。可是老人卻說“不要給我網站,不要給我事情做,我要的答案,直接給我答案。”我耐心地說,你問我如何理解如何解決,我給你的網站頁裏全部都有。如果這不是你要的,我真的不知道你要的是什麽了。可不可以你給我一個樣子,我一定努力提供給你。會議不歡而散。

周四下午啟程回家到達哥倫布家裏已經是深夜了,在機場時收到一個會議要求,是這位老人發出的。他要求我周五下午討論程序質量報告。

 

周五下午到了開會的時間,打進電話會議,發現其他兩個成員沒有在會議中,在我與老人的討論中,我的上司(就是那位說項目失敗不是他的責任的人)中途插話,與我在周二插話一樣,不同的是老人未就插話一事說一句話,好像他忘了他兩天前說的話。會議不歡而散。下麵是我在會議後寫的一篇博文,我將它翻譯成中文:

 

標題:誰是誰不是企業架構師

 

以下是兩個企業級應用程序架構師的職位之間的對話。我們姑且稱之為A1和A2:

A1:是什麽CA警告(Code Analysis Warnings) ?什麽是消除他們的路線圖?

A2:讓我送你從MSDN的有關些警告鏈接。微軟在提供原因,說明,如何解決它,等等方麵做了很好的工作.

A1:不要給我事做,我不會做的。我是一個企業架構師,我隻關心在高層次的企業應用架構。

A2:讓我給你CA警告的一個例子,CA1704標識符應該正確拚寫。描述為“一個外部可見標識符的名稱包含未由Microsoft拚寫檢查庫識別的一個或多個詞語”

 

A1:這個類型的警告怎麽解決?

A2:你改正識別的拚寫,使他們確認為英語詞典拚寫。

 

A1:什麽?那一定要是在正確的英文拚寫嗎?這僅僅是一個變量名,我可以想怎麽命名就怎麽命名!

A2:在現代化編程中,標識(類,屬性,方法,局部變量)需要被命名為以帕斯卡爾或駱駝的命名標準並且符合英文的正確拚寫。未能這樣做將導致本準則分析警告。如果我們的程序員想你所想,我們將有更多的警告。

 

A1:如何解決這個問題呢?

A2:讓我告訴你如何解決這些問題(打開Visual Studio中的項目)的例子...

 

A1:我不希望看到Visual Studio,我隻是想知道如何解決這些問題的方法和過程

 

A2:這正是我打算告訴你作為一個程序員我是如何修改它的。

A1:我是一個企業架構師,不要告訴我這些細節的東西

A2:(不知道該說些什麽)

M:A2,你知道這次會議之後做什麽?你知道A1想要什麽?

A2:我很困惑,根據我所知,我提供的是他所需要的,這隻是他不明白我說的東西。如果你告訴我說內容給任何軟件開發人員,他們會理思並能夠按照我說的去做。 隻是A1不了解企業應用的開發過程,我們是...

 

M:A2,因為你沒有提供A1所要求的,而且也不會提供解決方案A1的要求。我會讓別人代替你。

A2:我不知道A1知道他要什麽或者他所要求的東西是否還存在...

 

然後,對話結束,我的臉上表現中萬般的無奈......

 

這讓我想起了一年前我讀的標題為“微軟.NET:為企業設計應用程序。”的書。在這本書的作者寫了誰是“架構師”。以下摘錄:

 

每一個架構師應該是一個天生的程序員。用一個比喻來說,我們可以說,架構師類繼承程序員的類,並增加了一些新的方法(技能),同時覆蓋(專業),和其他一些功能。成為一名架構師是在一些程序員的職業生涯的自然演變。架構師和程序員之間的基本區別是經驗和教育。你在工作中獲取好的經驗;你讀好的書籍,並采取正確的的教育。此外,架構師必須從比普通程序員在更高層次上關注係統的整體結構的能力......正如我們所看到的東西,除其他事項外,架構師是一個更有知識的,更有經驗的程序員。我們不相信隻會在UML和Visio發言然後把所有實現細節留給給程序員的架構師的價值。至少,我們從來沒有發現很容易與這些人合作,我們看見這樣的架構師繞著走。

根據ISO/ IEC,沒有不同類型的架構師。架構師就是一名架構師。

 

在同一個項目組的多個架構師是可以的。有專管基礎設施的,有專管應用編程的,即不同的架構師有略微不同的技能。但是,他們仍然隻是架構師,在同一個團隊工作在同一個係統的設計。架構師必須能寫代碼。他們製定出係統的設計,然後繼續與開發人員密切合作,以確保設計的正確執施。

讀到這裏,我不禁想問,A1真的是一個合格的架構師嗎?作為一個.NET項目的企業架構師,不知道如何操作的Visual Studio,不想要看Visual Studio,這樣的架構師可以給項目帶來什麽價值?

 

就這樣我結束了在HP這個項目的工作,星期一就去密西根我的夢想的工作去工作了。