H17 Blog終於告一段落

從直接把想法寫成程式的作法，到接受OOAD的方法論是一個很大的轉變，其間也花了很多時間在思考如何將理論變通到可以實作的方式。後來發現與其他不接受OOAD想法的人討論時，時常淪落到在一個單點上的爭執；而那時最常聽到的一句話是：我這樣做不是又快又正確嗎？為什麼要浪費時間做那些？

在實作過一次並把OOAD融會貫通後，我發現得先把所有產出要生成的來龍去脈交待清楚後才有辦法清楚表達我的想法，所以開始記錄有關專案開發的過程、思維與作法。其間工作上經歷公司產品維護、幾個小元件的製作、還有對同仁作一天OOAD設計的講解（2007年8月初），我的想法陸續地調整與修正，從原先預計的一百篇左右變為現今的超過兩百篇。

提到軟體測試時，大多都會引用Grenford J. Myers在《The Art of Software Testing》一書中的觀點：軟體測試是為了發現錯誤而執行程式的過程；測試是為了證明程式有錯，而不是證明程式無錯誤。一個好的測試用例是在於它能發現至今未發現的錯誤；一個成功的測試是發現了至今未發現的錯誤的測試。

得先有系統存在才能想辦法去測試它，我也得先把自己所想的從頭到尾先完整表達出來，其他人才能看得出我在哪些地方是錯誤的；這就是我當初開始寫Blog的動力。最後，我用一句話來勉勵自己：現在的版本是為了下一個版本而存在的。（能明白它的意義嗎？）

H16 做人的方法(7)──時時確認影響

整個世界是一個類似系統的複雜結構，在許許多多不同的結構與層次裡到處都存在著人事物；人，充其量也只不過是世界裡一個渺小的組成，但是卻與身邊影響範圍所及的一切共同立足在這個世界的角落。

我們必須知道，我們在任何時間裡所作的任何行為，都或多或少地影響到所在的範圍。如果所做的事情影響較小時，周圍附近的一切會逐步吸收掉改變而不致擴大；相對地如果做出了一件影響範圍較大的事情，則必定會牽動世界的平衡。例如路上丟空罐只會影響了少數人的視野與負責撿垃圾的人；命令工廠對河流排放有毒的廢水就會破壞河流與其下游的生態；人類大量地產出二氧化碳而使得地球面臨溫室效應的浩劫。

切記自己所有的行為都會對這個世界有影響。少消耗一些物品，多回收一些資源有助於延長地球的壽命；待人多點和氣，避免針鋒相對有助於避免蓄意的殘害減少家人的傷心；日常生活裡養成趨吉避凶的生活習慣有助於多維持自己在地球上的責任等等。

生物群聚在地球之上，所有生物的作為累積起來將匯集足以改變世界的力量，尤其以人類為甚……。

H15 修改的歷程(3)──版本與資源

版本與資源的關係類似於班級與學生的關係，代表的是每一個不同的系統版本與上一個版本所涵蓋的變動清單。

在上一篇文章裡，我們可以得到系統的變動清單（Release Notes，也知道任兩個版本間的變動清單總和是升級版本時所需要做的動作。還有一個需要追溯的是系統裡的任何一個物件，曾經在哪些版本裡因為哪些問題而作過修改；這也就是程式或文件的修改歷程。

有的時候程式出現的問題是因為前面的版本沒有改好，而修改時大多都會幾個地方一起修改。當我們動手前，應當先確認是在哪一個版本出現的問題（修改垂直追溯），再確認那個版本的修改同時改了哪些地方（修改水平追溯），同時再參考系統水平與垂直的追溯關係，這樣才能作全面性的思考。

維護並不像開發那樣可以直接把程式湊一湊就能運作；寫功能即使是疊床架屋的作法都可以弄出一個可以驗收的系統，但是維護卻是牽一髮而動全身的高風險動作，如果不能確定自己動的那一根木頭會不會讓整個疊疊樂倒下來，維護這個系統就會變得非常辛苦。

H14 修改的歷程(2)──問題與變動

當系統出現必須修改程式的問題，為了解決問題就一定會動到程式，問題與修改程式之間同樣需要追溯。

程式被修改之後，要進入到系統的追溯層面，找出所有直接或間接使用到修改部分的Class，看是否有需要跟著修改的地方，有的話也要列入被修改的程式清單。確認問題變動到的Class清單後，要找出他們對應的測試程式視需要變動後加以測試，還要找出與修改部分相關的文件章節並且修訂；以上一連串需要修改的地方，都是與這個問題有關的追溯記錄。

單一問題逐漸被修正而且通過，在即將出版本前應把所有的問題與其影響物件整合起來看待，程式、測試程式與文件全部被修改過哪些，如果某個物件在多個問題內都有被變動到，則要把問題單代號列示在該物件的名稱後。接著找出所有變動程式影響的Test Case加以修改並作整合測試。

每個問題單要知道為它所改變的全部物件，每個被改變的物件也要知道它影響了哪些問題單。系統的任何改變，都必須要能找出範圍以便“封裝”改變後的影響，如此才能以最經濟的方式加以測試且能確保品質。

H13 系統設計結構是四維空間

在架構設計階段時提到，系統層面的設計要以功能為經、用層次為緯定出所有放置程式的方格，這是水平層面的設計。在系統裡與邏輯控制有關的程式，會去呼叫各個不同深度的元件，這是垂直層面的使用。另外用以上三度空間的概念所設計出來的所有Class，在特性上有著與其他Class的繼承關係，又組成了第四層的使用。

每一個Class所存在的位置有著這麼多的資訊，一個系統裡擁有的Class數量又是那麼地多，直接將想法寫成程式的作法很明顯地可以發現，在一小段時間後設計的人就會忘記一個Class如何與其他的Class互動的方式，以及該Class所具有的影響。正因為需要將所有Class定位的資訊是如此之多，再加上與需求、測試等等物件的關係又加深了複雜度，所以我一直堅持必須將想法記錄下來，以便隨時查詢到任何一個物件的影響。

系統裡任何一個物件都是牽一髮而動全身，更改一個Class後如果沒法把變動他後連帶影響的細線全部找出來的話，只要漏掉任何一條就有可能造成系統變得很不穩定。倘使沒有記錄，所有關係的追溯都必須靠回想或是再解讀程式碼，這不僅花掉更多的時間而且也無法保證能找到全部。記錄，真的是很關鍵的行為。

H12 修改的歷程(1)──時間與個人

小學中高年級時都有編班的動作，重新編排各班級的成員。現在想像自己是一位小學生，入學時低年級的編班是一個版本，中年級時是另一個版本，高年級也有一個版本；如此一來，班級、學生與版本就出現了關係。

班級裡原本就有多個學生的關係，現今再加上版本的歷程，需要追溯的關係就變得更多，因為原先只需要一層的班級學生追溯表，現在就必須因應版本成為三層，另外再加上垂直的追溯關係。比如說，我們應該會記錄各年級時所有班級的學生，還有學生在各年級中所處的班級。

班級的成員對學校來說是管理上需要的資訊，而學生所處的班級則是個人擁有的歷史。有的時候不同版本的班級需要知道前一個版本的成員有幾個人還在同一個班級；有的時候數個同年級學生聚在一起，會經過資訊的交流來知道他們有沒有共同的歷史（曾經同班）？有的話持續了幾個版本？

班級、學生與版本就已經讓追溯變得複雜，如果追溯的關係再加上各個版本的每個班級所有科目的課任老師，甚至再加上每個科目使用的教材出版社的記錄呢？現實生活裡的關係追溯就是這麼複雜，與開發系統相關物件的追溯關係只會更多而已。

H11 客戶想升級新版本時，怎麼辦？

每一個版本的異動都要建構管理，因為在同一類系統為不同客戶開發的狀況下，我們極可能會遇到前面任何一個客戶“需要”升級到最新版本的事件。不管是舊客戶升級新系統，或是新系統所出的更新版本，面對“升級”的詢問時該怎麼做呢？

升級最重要的部分是差異的比較，但這也是最難的部分。如果客戶的版本到最新的版本之間都有詳細的Release Notes，只需要總和所有變更即可；再次之的話，只要有舊版本的功能清單與新系統的功能清單，也可以多花時間比對出差異；但是我們遇到的總是最麻煩的狀況，兩個系統都沒有功能清單之類的文件。所以目前只要提到升級，都沒有人能夠保證要怎麼做才能100%無痛升級。

大家都說經手過的所有系統都留有最後的程式碼，可是在無法分析比較的情形下，程式碼只有在系統毀損後快速回復的作用。所有版本留下的意義，在於可以立即查詢到任何版本的所有文件，同時快速地求證到“任兩者之間的差異”。找得到所有的差異，就能夠安排工作項目來填補它們，使用舊客戶完整地升級到最近的版本。

H10 每一個版本都有它的意義

系統每出一次版本，可以算是完成一個里程碑。這個時候要把全部的新程式碼、新文件加上與變更有關的Impact Analysis、Release Notes放在一起一同建立一個保存的版本。通常來說系統執行一段時間沒有問題後，這些系統的內容幾乎都會沉睡在公司的伺服器裡頭。

版本保存的最基本用意，在於當客戶遇到系統任何一部分有缺漏時，可以快速地回復客戶的系統；另一方面在客戶發現問題或要變更需求時，有一個作為開始修改的基準。回復與修改使用到的是程式碼與文件的部分。

在某些狀況下，需要比對兩個不同版本間的差異，這時就需要與變更有關的文件加以分析比對。出現的時機大多在於詢問新功能在某個客戶用版本有沒有，或者是有升級系統版本的打算時。在台灣的軟體環境裡，做出系統功能都快來不及了，誰還會有時間管文件、記錄與變更的分析呢？也因此只要有人提出這個問題，就一定沒有人能正確回答。

H09 下一個版本的Release Notes

所有問題單與需求變更的內容幾乎都會成為Release Notes的一部分。在完整的Release Notes裡除了註明版本、出版日期等等的基本資料之外，還會記錄的至少會有每個問題單的編號、敍述、修改的程式名、更改的文件名。

Release Notes的用意大致上來說在於記錄與上一個版本的差異，讓使用者知道更換成現在的版本會有哪些改變，而且那些改變與哪些系統物件有影響；根據這些記錄，使用者能夠明確地界定更換版本的變更範圍，並快速地查詢到會有什麼影響且知道應該要怎麼做。

對於升級多個版本的客戶來說，只要把所有的差距版本的Release Notes整合起來一起看，就能得到其間差距的總和範圍與影響。我們可以將Release Notes視為告知系統所有改變的一份清單，不需要一一去核對新的版本與前一個版本就能得到差異的資訊。

H08 系統出版計畫

當問題單收集到一定程度，必須要出一個新的版本時，一般來說會訂一個停止處理問題單的日期與系統出版的日期，同時發布下一個版本即將要修改哪些問題的通知。

在停止處理問題單的日期之後，還會留幾天繼續修改現在已經確定要修改的問題，同時在確定全部修改過的程式都通過基本的測試後，接下來會進行出版本前必須要做的迴歸測試。迴歸測試原則上要把系統的功能從頭到尾重新測試一遍，目的在於確保新的版本不會有任何已知的問題。

在進行測試時若發現任何問題，必須儘快判斷該問題能否被快速解決，以便公布這次版本會解決這個問題或是延到下次再處理。對於使用者來說，明確地知道在什麼日期出版的系統會修改掉哪些問題是很重要的訊息。

H07 修改系統程式(4)──頭痛的問題

這個題目其實可以反過來問：修改系統程式時需要哪些資訊會感到輕鬆自在？以前面三個標題來看，大致上需要知道的資訊也有三種：原來的程式這樣寫的原因？新的功能要怎麼寫才能達成？還有程式修改下去會有什麼影響？

第一點需要的是程式碼裡包含足夠資訊的註解，有時會需要功能規格書甚至是原始需求資料；第二點需要的是API參考文件與系統開發教學文件；第三點需要的是程式對Use Case與Test Case的對應表，如此方能保證修改後的系統通過了所有相關的測試。

可以想像以上所有資料都殘缺不全時的景象，不是詢問原先的設計人員就是要自己從程式碼反推出那些文件裡應有的內容。問原設計者是最快的，但我的經驗在細節的部分以趨近100%的比例得到”已經太久以致忘記”的答案；也就是說，幾乎每個問題都得靠自己去反解譯程式才行。

由於自己走過才知道痛在哪裡，也因此自己在從事設計時都會特別注意要留下足夠讓別人明瞭或是換醒自己記憶的資訊；然而最理想的作法還是要留下足夠的完整資料才對。

H06 修改系統程式(3)──動手修改後

修改後並不是保持系統正常就沒事了，接下來還有很多收尾的動作，就是去修改與更動過程式碼有關聯的物件。

同樣透過系統各式各樣的追溯表找出程式有關聯的所有物件，像是需求文件、功能規格、使用手冊、開發參考手冊……等等所有應該隨之修改內容的文件，修改後註記在Analysis裡，並另外記錄下問題單與修改程式、修改文件的影響關聯。

修改之後，我們應該得到修改過的程式碼、修改後的相關文件、在上面註記所有修改發生處的Impact Analysis以及一份收集所有Impace Analysis影響資訊的清單；這份清單的內容會在出下一個版本時記錄在下一版本的Release Notes上。

這個時候的重點在於追溯並修改程式的部分影響到的所有系統物件，同時加以記錄作為日後追蹤問題修改後的影響。

H05 修改系統程式(2)──動手修改時

在確認出問題的程式碼後，應該先在Impact Analysis上註明出錯的原因，並推斷應該如何修改來解決現在的問題。文件經過原先設計者或其他同仁的審查並同意後，再依照文件上的作法去修正。

修改的時候要注意儘量把原來的程式碼用註解的型態保留下來，同時在後面註明是誰因為哪一張問題單才這樣改的；另外加上去的程式先要以明顯的註解標記上同樣的資訊。這麼做的原因是萬一修改後還是有問題，甚至演變為更重大的Side Effect時，還能很快地恢復為原來的樣子。

修改後當然應該立即作Unit Test以保證程式本身還能夠通過原來的測試，出錯的部分如果原先沒有被測試到則要加入Unit Test的範圍。通過Unit Test後要參考系統的追溯表找出這些Class所影響到的全部Test Case重新測試一遍；通過所有的測試後，把修改程式碼的Class名稱與變更的內容全部記錄在Impace Analysis裡。

如有任何錯誤則一直重覆修正到通過全部相關的測試為止。此時的重點在於解決問題並通過測試，還有就是記錄下所有修改的地方。

H04 修改系統程式(1)──動手修改前

當問題單無法直接回覆而傳送到負責修改程式的人這邊時，幾乎表示這個意見是非修改程式不可了。

首先不管是修改問題或是新增功能都要新增一份稱為Impact Analysis的文件，先在上面記錄問題單的編號內容與負責人員的姓名。這份文件的目的除了記錄這次的修改是基於哪一份問題單的提出之外，另外會記錄修改的原因與修改後影響的部分。

在動手修改程式之前，如果提出的是錯誤的話，那麼第一步必須先重現使用者的問題；如果依使用者提供的資料仍無法重現問題，那麼會先請使用者提供更詳細的資料。當問題可以重現時則反覆測試直到能明確判定是在什麼地方造成這個錯誤的發生。

定位出需要修改的程式碼位置後，再來就是要決定如何修改，與要花費多少時間去修改。在此時著重的是先去明白動作為什麼是這樣做，現在的動作在哪裡出現了錯誤導致眼前的問題發生。

H03 發現錯誤與需求變更的處理流程

在維護階段時，不管是發現問題或是想新增功能都適合這個流程，Defect System可以沿用測試階段的設定；但是出版本後的Defect System內容從空白的開始較好，因為測試階段所開的問題單的內容大多屬於系統內部的描述，使用者大多看不懂描述，而且問題理應完全依照需求與設計修正過，可以預設為正式系統裡不會出現。

使用者在發現問題或者想新增功能時，要先到Defect System上搜尋想提出的意見是否曾經被提出過，如果已經提出則應看該意見的回覆而不該重覆提出。提出的意見會由負責維護的人員決定是否處理該意見，不接受則直接回覆使用者並視需要提供更進一步的使用說明，接受的話會更改意見的狀態並將問題單轉傳給負責的人，由該人員決定如何處理。

H02 CMMI的精神在於規定Process內容

CMMI（Capability Maturity Model Integration）的精神在於規範軟體開發的各個階段，包含專案管理之類的管理層面，應該要做哪些動作，帶有哪些產出。一個公司導入CMMI的目的，是希望藉由它的精神依公司的特質，來制訂出公司開發系統時各個相關流程領域的標準作業流程（SOP）。

CMMI制訂出來的流程，意義與系統裡的Controller極為類似，都在於要求負責人員在特定情況下該去做什麼事（作出什麼文件）；系統開發在某些時候是數個階段同時在進行的，在流程相互有影響的時候，依做事的順序與方法訂出適當的流程是很重要的。不過對於什麼都求快的專案來說，習慣從起點就飛到終點的我們，要去適應一步一步照規定來做通常都感覺到痛苦。

CMMI只要求在特定情況下要產出哪些文件，但是對於文件的內容並沒有要求。也就是說，習慣把系統設計成一個大黑箱的團隊，即使套用了CMMI LV5的作法，最後的產出一樣是一個大黑箱──只是多了一堆言不及義的文件。所以在導入CMMI的同時，理應再選擇適用的軟體開發方法才能有最大的效果。

以Engineer Processing的幾個流程領域來看，每個流程領域都是在以達到特定的目的的前提下，搭配使用的方法論來規定什麼時候應該要有什麼樣的產出。因而公司一定要先決定開發系統所使用的方法論，再導入CMMI加以規範開發的Process，方能進而提升品質。

H01 Controller控制系統物件，Process控制專案產出

還記得Data Model與View吧？它們都接受Controller的支配，何時該提供值與該設定值，都要看Controller裡如何定義。同樣的道理再往上一層，我們把全部的需求與程式都視為系統必需物件的話，那麼這些物件該在何時出現，何時提供給其他文件參考則都視Process如何定義。

CMMI是一個定義Process的標準。參考著許多開發系統的專案，專案們得到許多經驗值去明訂從什麼文件經過什麼動作之後可以導出下一份文件，專案依此一步一步地往前演進，也獲得許多按照步驟應該出現的產出，不管是程式還是文件，直到完成驗收出了版本總算把專案結束掉。而Process則是在專案完全停止前，規定要用什麼樣的順序來做與專案有關的動作。

即使系統已通過驗收，但沒人敢保證不會再發現錯誤或者使用不會再添加原來沒有的功能；所以維護同樣也是接受Process所管理的動作，以確保在應該有所動作時做應該做的事情。