英文原文：Are you coding for change or for stability? 

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

我們的 Davidson 教授

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

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

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

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

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

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

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

　　我們開發時處處設防。

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

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

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

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

　　第二個故事

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

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

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

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

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

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

　　他們為穩定而優化系統。

　　我想強調一點，第二個故事里的這種想法的人在生活中不占少數。他們是很優秀的人，但他們卻被安排去開發以穩定為第一位的系統。這才是真正的風險。

　　結論

　　這兩個故事讓我思考很多：

• 如今我在寫代碼時是以何目的而優化？
• 變化隨時都會到來。我從開始就知道。“在這個系統運行的 25 年里我將會不斷的修改它的規格說明書”。我該如何去應對這種事情？
• 我是如何看待變化，把它當成風險？還是當成一種驅動？能夠快速的應對改變是一種商業優勢，是一種管控風險的良方。我如何讓我的代碼更容易改變？
• 在一個將要進行大量修改的系統里，什么樣的文檔才能滿足我？

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

it知識庫：你優化系統的目標是什么？，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。