上周五的時候我對某個項目做了一個更改，將里面的構建腳本由maven換成了gradle。原因之一是因為maven的配置太繁瑣，由于其引入了lifecycle的機制，導致其不夠靈活，而gradle作為用groovy寫的DSL，代碼清爽、簡單、靈活。原因之二是我們所有的項目構建都換成了gradle，為了保持技術棧單一，此項目做遷移也是大勢所趨。（其實最重要的原因是我想練練手，雖然對maven已經箱單熟悉了，但是gradle的練習不多。）
完成遷移以后，我在本地試了一下，編譯的war包可以成功運行。并且我也修改了構建管道，使其能夠支持新的gradle腳本將war包部署到服務器上。
然后我就給項目成員發了封郵件，告知了這件事情。
周一來上班的時候，收到了項目組的回信，大家都對我的勞動表示感謝。其中有一個組員建議我將這個項目的名稱更換一下。因為該項目之前叫做ais-stub，他的主要功能是模擬ais服務，但是后來我們也加入了對其他web service的模擬，應該改為service-stub更具有意義。
我覺的這個改動應該比較簡單，無非就是修改一下該項目的名稱，并且更改構建出來的war包名稱，修改構建管道的配置。然后我就動手改了。待我改了war包名稱后，想起來這樣會引起url中的contextPath也發生變化，而功能測試引用了這個url，那么我就修改了功能測試中的url。然后我又發現我需要修改其他項目中的配置，將使用了該url的地方替換為新的url。待我將我的修改提交后，發現部署失敗了。原來是由于war包名稱改變，部署腳本在獲取war包時找不到新war包，我不得不修改部署腳本。但是修改過程中我發現有一段部署腳本由于權限原因我無法修改，只能請求對該腳本有修改權限的人替我修改，這又浪費了不少時間。全部修改完后我想起項目wiki上的介紹也要跟著改，把所有使用到該項目名稱的地方都需要改成新名稱……
就這樣一步步的做下去，本來覺得2小時就能完成的任務我足足干了4個多小時。最后全部改完后，我試著跑一下看看能運行不。結果傻眼了，將該項目部署到服務器上后，其他項目請求該服務失敗，具體原因未知。由于我已經做了太多的改變，很難定位到問題所在。我剛開始懷疑部署有問題，想查看服務器上的構建版本，發現查詢不到。找了半天原因后發現原來星期五我做構建腳本遷移時遺漏了一個插件，導致沒有將構建版本記錄到war包中。我只能先放棄查看服務器上的war包構建版本，而在本地將該項目的服務器起起來，使用其他項目進行訪問，結果又一切正常。那證明可能還是服務器上的部署有問題。我查看了構建出來的war包，發現里面的properties文件不是期望的那個，這時我想起周五修改構建管道時，隨手刪除了一個自認為多余的task，可能正是這個原因導致最后導入war包的properties不對。我只好又修改構建腳本，確保其能包含正確的war包……
很快時間已經到了6點多了，該下班了，但是我仍然深陷這個泥潭，沒有找到問題原因，反而時不時要解決一些其他雜七雜八的東西。看來今天是完成不了了，因為修改的東西太多了，每個修改都沒有進行驗證，所以問題排查很難，并且還經常發現新的問題。
最后，我只好打住。決定明天早上一來把今天所有的修改都撤銷掉，等于說今天的活都白干了。今天下班了，感覺很不好。作為一個豐富的程序員，給羊剪羊毛（出自《卓有成效的程序員》，指剪不斷理還亂，本來要解決這個問題，但解決過程中面對的都是與根本問題不相干的其他問題）這件事情怎么會發生在我的身上那？
我覺得最大的問題有兩個：
沒有對改名這個任務列詳細的task。剛開始太輕敵，以為改名很簡單，沒有仔細想。結果自己把自己帶到了溝里，步子邁的太大了，把蛋給扯到了。列出詳細的task好處是你能預估出完成的時間，并且了解可能會出現哪些風險。每個task都循序漸進、可以驗證，并且保證隨時可以回退。由于沒有列task，直接導致我明天撤銷修改時還要努力回想到底今天做了哪些修改。
我沒有及時進行驗證。TDD的思想就是先測試-》測試失敗->再寫實現->測試成功。這樣周而復始來驅動出你的代碼。由于所有代碼都有測試覆蓋，你有充分的信心保證你的實現是正確的。而雖然我對項目的修改無法及時通過自動化測試進行驗證，但起碼也應當在做了一個小改動時及時的手工進行驗證。比如在將構建腳本替換成gradle之后，不僅要在本地測試一下是否正確，還應當測試部署到服務器上的war包是否正確。這樣至少能及時發現構建版本信息缺失及properties文件不對的問題。
以前老教導別人做事的時候要列task，要及時驗證和反饋，沒想自己今天在這上面宰了一跟頭，還是太輕敵啊。不過吃一塹長一智，希望以后少犯這種低級錯誤。
文章列表
留言列表
