# 十四、不要被太空架構師所嚇倒
偉大的思想家想問題時會開始看出模式。他們看到人們要傳送字處理檔案給別人,又看到人 們要傳送電子表格給別人,然后就會發現里面有一個通用的模式:傳送檔案。這己經是一層 的抽象。然后他們會再上一層:人們傳送檔案,不過網頁瀏覽器也會「傳送」網頁要求啊。 另外如果你有想到,其實呼叫某個對象的方法也像是傳送訊息給該對象!這又是一樣的東西! 這些全都是傳送的動作,所以我們聰明的思想家就發明了一種更新更廣義的新抽象概念:「訊 息傳送(messaging)」,不過現在這件事變得愈來愈神秘,再也沒人真的懂他們在說些什么。 廢話。
當你一直往上把事情弄得太抽象,就會像上太空一樣沒有氧氣。有時候這些聰明的思想家就 是停不下來,然后就創造出這些荒唐又無所不包的高層次宇宙景像,這些東西什么都好,就 是完全沒有實際的意義。
這種人我稱之為架構航天員。要他們寫程序或設計程序是難上更難,因為他們沒法子不想架 構。叫航天員是因為他們活在氧氣層之上,我不知道這些人是怎么呼吸的。他們通常在真正 的大公司上班,只要這種公司才養得起大批不事生產,完全沒有貢獻的高學歷份子。
最近有個例子可以拿來說明。典型的架構航天員會針對「Napste「是個用于音樂下載的點對 點服務」這件事,把架構以外的東西全部忽略掉,然后說因為是點對點所以很有趣,完全沒 搞清楚重點在于可以輸入歌名后可以馬上聽到。
他們就只會說點對點如此這般如何如何。忽然間就出現了點對點會議、點對點創投基金。甚 至還出現對點對點的激烈反擊,看到一群白癡商業記者快樂地互相抄襲報導:「點對點己死!」
架構航天員會說會說出類似這樣的話:「你能想象一個像Napste「這樣的程序,你可以用它 下載任何東西而不只是歌曲嗎?」然后他們會建立像Groove這種自認比Napste「更一般性的 應用程序,不過似乎卻忘了那個微不足道,讓你輸入歌名然后聽歌的小功能,那個我們從一 開始就要的功能。說到搞不清楚重點。如果Napster不是做成點對點形式,卻的確能讓你輸 入歌名就能聽歌,恐怕還是會一樣流行。
另一個架構航天員都喜歡做的事,就是發明某種新架構然后聲稱它可以解決某件事。Java、 XML、Soap、XmlRpc、Hailstorm、.NET、Jini…天啊,我都要睡著了。而這些還只是過去 12個月的而己!
我絕對不是說這些架構有什么問題。它們都是相當好的架構。讓我受不了的是圍繞在架構周 圍那些驚人的超級宣傳。還記得微軟.NET的白皮書嗎?
新一代的Windows桌面平臺Windows.NET支持生產力、創造力、管理、娛樂以及更多更多,是 為了讓用戶掌控其數字生活而設計的。
這東西大概是九個月前的事。上個月我拿到微軟的Hailstorm。那份白皮書寫著:
人們并沒有掌控周邊所圍繞的科技…HailStorm讓生活中的科技相互結合,在你的掌控之下 為你服務。
噢,了不起,所以現在你房間里的高科技鹵素燈不會再隨便亂閃了。
微軟并不孤單。下面這一段是摘錄自Sun Jini白皮書:
這三個事實(你是個新世代的系統管理員,嵌入式微電腦隱身于周遭,單機計算機無所不在) 應該結合起來,以改善使用單機計算機的世界-借著消除各種計算機間的界限,借著讓計 算機無所不在,借著把用計算機工作的細節變得像把DVD放進家庭劇院系統一樣簡單。(譯注: 請原諒我,因為這一段我原文也看不懂)
還有那段讓我根本不想想起來,由業界推手George Gilde「(譯注:美國科技趨勢專家)宣揚 Java的話:
科技史上的一個十分重要的突破…
這是一個明確的情報,顯示架構航天員正在攻擊你:數不盡的夸大言辭;史詩般理想化的豪 言壯語;夸大;完全缺乏真實感。可是大家就是吃這套!這些商業報導真是瘋了。
大家究竟為什么會受無聊的架構所影響呢?這些架構常常只不過是一種用于RPC的新格式或 是新的虛擬機罷了。這些東西可能是不錯的架構,也的確能幫助開發者,不過它們并不(我 得強調不)能代替彌賽亞騎白驢進耶路撒冷或是世界和平。不,微軟,計算機不會突然開始 會讀心術然后自動做我們想做的事,只因為世界上每個人都有一個Passport賬號。不,升陽, 我們并不想讓公司業務資料的分析像「把DVD放進家庭劇院系統一樣簡單」。
要知道搞架構的人會去解決那些他們能解的問題,而不是那些解了會有用處的問題。Soap + WSDL或許是很熱門的新玩意,不過它并不會真的讓你做到那些以前用其他技術做不到的事 (如果你真要做的話)。架構航天員鬼扯的這些分布式服務天堂過去都曾有人答應過,如果 用過DCOM或JavaBeans或OSF DCE或CORBA的話就知道了。
我們現在可以用XML作為電話上用的格式,這的確是很不錯。值得歡呼一聲。不過那對我來 說,就像知道超市用卡車由倉庫運貨來差不多有趣。打個哈欠,是芒果哦,很有趣。講些我 以前做不到而現在可以的新鮮事吧,老航天員。否則就乖乖呆在太空,不要再浪費我的時間 了。
- 第一部分 位與字節:編程實踐點滴
- 一、語言的選擇
- 二、深入底層
- 三、joel測試:改進代碼的12個步驟
- 四、每一位軟件開發人員必須、絕對要至少具備UNICODE 與字符集知識(沒有任何例外!)
- 五、輕松寫就功能規格說明書 - 第1節:為什么煩心?
- 六、輕松寫就功能規格說明書 - 第2節:什么是規格說明書?
- 七、輕松寫就功能規格說明書 - 第3節:但是……如何?
- 八、輕松寫就功能規格說明書 - 第4節:技巧
- 九、輕松制訂軟件進度表
- 十、每日連編是朋友
- 十一、難伺候的故障修復
- 十二、軟件開發中的5個世界
- 十三、稿紙原型開發
- 十四、不要被太空架構師所嚇倒
- 十五、開火與運動
- 十六、人員技能
- 十七、源于計算機學科的三個錯誤思想
- 十八、二元文化
- 十九、自動獲取用戶故障報表
- 第二部分 開發人員的管理
- 二十、面試游擊指南
- 二十一、重金激勵害多利少
- 二十、二不配備測試人員的五個首要(錯誤)原因
- 二十三、任務換人有害無益
- 二十四、絕不去做的事情,第一部
- 二十五、冰川下的秘密
- 二十六、漏洞抽象定律
- 二十七、程序設計界的LordPalmerston
- 二十八、評測
- 第三部分 Joel對常態問題的遐想
- 二十九、RickChapman解讀愚昧
- 三十、在這個國家狗是干什么的? 我們有多么天真?
- 三十一、作為哼哈二將,只管去做事
- 三十二、兩個故事
- 三十三、巨無霸麥當勞與天才廚師JamieOliver
- 三十四、沒有什么像IT看起來那么簡單
- 三十五、提防非自主開發綜合癥
- 三十六、策略I:BEN&JERRY公司與AMAZON
- 三十七、策略II:雞與蛋問題
- 三十八、策略III:讓我回去!
- 三十九、策略IV:大件與80/20神話
- 四十、策略V:公開源代碼的經濟因素
- 四十一、墨菲法則肆掠的禮拜
- 四十二、微軟公司是如何敗北API之戰的
- 第四部分 對.NET稍多的評說
- 四十三、微軟精神失常了
- 四十四、我們的.NET對策
- 四十五、請問,我可以使用連接程序嗎