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

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

我們的 Davidson 教授

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

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

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

　　我跟很多的軟件開發(fā)團隊(包括一些軟件產(chǎn)品創(chuàng)始人)說過這個故事，他們的反應(yīng)幾乎都一樣：

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

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

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

　　我們開發(fā)時處處設(shè)防。

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

　　這就是我們的做法。我最想說的是，這是一個非常好的作業(yè)任務(wù)，它讓我在面向?qū)ο缶幊毯?Smalltalk 方面學(xué)到了很多。感謝你，我們的 Davidson 教授！

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

　　我們?yōu)橐院蟮母淖兌鴥?yōu)化系統(tǒng)。因為 Davidson 教授告訴我們變化很快就會來到。

　　第二個故事

　　讓我來給你們講一個故事：這是關(guān)于大概 25 年前開發(fā)的一個系統(tǒng)的故事。它是一個瑞典大公司的重要業(yè)務(wù)系統(tǒng)。我說這是一個重要業(yè)務(wù)系統(tǒng)，是因為它處理的業(yè)務(wù)是公司 80% 的收入來源。

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

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

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

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

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

　　他們?yōu)榉€(wěn)定而優(yōu)化系統(tǒng)。

　　我想強調(diào)一點，第二個故事里的這種想法的人在生活中不占少數(shù)。他們是很優(yōu)秀的人，但他們卻被安排去開發(fā)以穩(wěn)定為第一位的系統(tǒng)。這才是真正的風(fēng)險。

　　結(jié)論

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

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

　　你優(yōu)化系統(tǒng)的目標是什么？

it知識庫：你優(yōu)化系統(tǒng)的目標是什么？，轉(zhuǎn)載需保留來源！

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