你優化系統的目標是什么？

作者：佚名 2013-05-23 09:29:45

開發架構

讓我來給你們講一個故事：當我在大學的時候，我選了一門“高級”面向對象編程課程。以前從來沒有接觸過這種知識，這個課程使用SmallTalk這種語言教學，而且教學方式非常特別；第一天，教授給我們布置了一個將會貫穿整個4周課程的作業。

[[73330]]

我們的Davidson教授

我們非常興奮，因為這是要編寫一個游戲。一個老式的文字輸入式的冒險游戲，類似于Zork風格。我們分成3人一組，來到教授擁擠的小屋里。在那里，教授給了我們一頁紙，上面寫著一些說明。從那里返回時我們幾乎是一路小跑。

而就在我們剛要出門時，教授把我們叫了回去(我相信他是特意選了這個最佳時機)：

“哦，我差點忘了。兩個星期后，我會對這個游戲內容做一些大的修改。你們要繼續按修改后說明開發。”

我跟很多的軟件開發團隊(包括一些軟件產品創始人)說過這個故事，他們的反應幾乎都一樣：

你能在屋里聽到笑聲。至少是咯咯的笑。經常你還能一些“不會吧”等話
“哦，老兄，這也太沒譜了吧！”
“這教授這么難為人嗎——怎么可能有這樣的任務”

問題就在于，教授并沒有告訴他將會做什么樣的修改。只是說會修改一些東西——兩周后。

你認為我們該如何去完成這個任務？

我們開發時處處設防。

“哦，不行——如果教授打算改動這個怎么辦？”
“也許應該把這里做成接口——萬一教授要求用不同的方式實現它呢？”
“不行——我們應該把這部分提取出來，這樣，當我們修改這部分時就不需要改動模塊X了”

這就是我們的做法。我最想說的是，這是一個非常好的作業任務，它讓我在面向對象編程和Smalltalk方面學到了很多。感謝你，我們的Davidson教授！

最終，我們做成了一個非常模塊化的系統，這使對它們的修改變得很容易。當那一天終于到來，當游戲設計被修改后，我們通過努力在一天內就按照要求修改了程序，使我們能順利的接著開發界面和怪獸等很酷的部分。

我們為以后的改變而優化系統。因為Davidson教授告訴我們變化很快就會來到。

第二個故事

讓我來給你們講一個故事：這是關于大概25年前開發的一個系統的故事。它是一個瑞典大公司的重要業務系統。我說這是一個重要業務系統，是因為它處理的業務是公司80%的收入來源。

自打一開始，他們就思考的面面俱到，保留的極詳細的文檔。他們還制定了一套嚴格的需求變更規范。他們要求盡量避免這樣的系統里的變更，因為風險很大，一旦出錯會造成巨大的影響。

公司如此為這種事情擔心，以至于他們編寫了一系列的措施來預防系統出現問題；所有的代碼要經非代碼原作者的第二人用偽代碼注釋一遍。而且測試工作不能由代碼的作者來執行。

同樣，也制定了各種風險管理措施，來管控軟件規格說明書的制定。寫規格書的人被分成了幾個等級，以此確保在遞交給相關IT業務部門前經過層層檢查。

很快25年過去，如今這些編寫文檔和管控風險的部門仍然在忙碌。這套措施很少出問題，但卻效率很低。一個修改從列入計劃到提交到產品中大概要30周的時間。一個想法到正式被寫入規格說明書要經過20多個不同級別人的審批。拿著這種說明書的程序員都稱自己為“施工人員”，因為他們實際的工作是把偽代碼翻譯成 COBOL語言。

所有圍繞這個系統做的事情都是為了掌控風險和需求變更，把穩定放在第一位。他們認為只要修改就會產生意外。但不幸的是，對于一個業務來說，唯一可能發生的事情就是：改變。而且改變的頻率會越來越高。

他們為穩定而優化系統。