W26 一名家教班裡的小三學生

不久之前造訪一位朋友所開的國小家教班。在裡面遇到一位小三女學生，她的基礎非常不好，面對簡單的加減應用問題時，是用猜的來決定要用加號或是減號。我試著用數線的方向性來對應加減，也試過讓她固定用大的減去小的來得到答案，但是沒有真實理解數的概念時，一切的說法都沒法讓她解出任何一個類似的應用問題。

周遭遇到的小朋友都還算聰明，很訝異還是有小朋友的理解力如此不佳，這時不禁連想到李家同先生的文章與他所堅持的教育理念。會去留意其他人的的退休計劃，有不少人認為勞碌了大半輩子後，剩下的時光想要過輕鬆的生活或是享受異地的旅遊。

對妻說過，退休後想每年都住在一個不同的偏遠地方，一方面體驗不同環境中生活差異，另一方面就是主動地為附近的小孩進行課業輔導並傳授做人做事的方法。教育的平均有兩個方向可以努力，一個是提升偏遠地區的教育資源，另一個是提升資質較差的小孩到平均的水準，每年旅居到一個不同的區域協助當時所能遇到的所有人，這應該是能力範圍內所能做到的。

資質不好的人因為聽不懂而無法改變自己到能理解的程度，但是聰明的人反倒因為聽懂而更無法改變到更進一層（為他人服務）的程度。缺乏＂吸收資訊，判斷對錯，調整自己，成就他人＂的成長彈性，到底只能讓自己的聰明才智僅讓自己獲得利益，同時還認為其他人的改變也只是為了他自己而已。（奇怪的是，反倒是心裡有不好的想法時大半會說是因為別的某某事件被連帶影響的）

今天的我對於系統開發與人生想法是如此。明天呢？後天呢？想法還會有再度改變的那一天嗎？

W25 My Object = Data + Behavior

在與兩位同事討論時，其中一位同事說，每個行為包裝為一個方法的想法很像Behavior Driven Design（後來查過資料，發現應更像先不看架構的責任導向設計－－Responsibility Driven Design）。Object一直都是包含資料與行為，既然具有這兩類元素，Data Driven Design與Behavior Driven Design就應該同時注重。

角色、物件、大小事都對應到各自的Object（或是元件）並依其特性抽取共用是我的設計基礎，資料結構與處理步驟全採用一對一的對應設計是我的堅持，符合原始特性的定義才能夠將改變局部化到最小區塊，進而得到最少化的測試範圍。這些好處的相對代價是開發人員要額外作設計，必須花費較多的時間為自己與別人安排程式碼。

對於OOAD的題目，我一個人思考了兩年，提出的經驗與作法盡可能涵蓋到工作中所經歷到的各個角落。有一位喜歡看書的理論型同事是我經常討論的伙伴，從他那裡聽說到許多不用功就不會知道的名詞與作法；共事的同事們是我主要的經驗來源，由於他們現有的產出我才能明白各個角落的好處與缺失；專案上的同事則是我琢磨想法的對象，常問他們現在的作法與優缺點是什麼，同時提出我的作法詢問是否能留下好處並改善弱點。

每個地方的說法我都推論與驗證過，雖然能有可以解決的方案，但是我相信並不會是最佳的作法。許多同好都投注許多心力鑽研軟體工程的各個方面，沒有道理我只用兩個人年就有最後的結論。目前差不多是我的極限了，未來除了製作對應的工具之外，更需要的是有其他相信這一條路的人一同討論每個角落的最佳化。

這十年來在工作上所遇到能夠抱持相近努力方向的人，實在是屈一手之指可數呀。（當然不包含發現專案有問題時才喊著要好好設計口號、作下一個專案時又開始計較時程與產出的那些人）

W24 成敗的關鍵(2)──看待的角度不同

收集一些在專案開發期間常聽到的話語，用類似的語意表達如下：

●專案經理：專案的目標在於系統的準時驗收，任何可能影響時程的額外活動最好避免。
●前來支援的架構師：我已建立好可以執行的基礎架構，只要這樣這樣使用就可以。至於元件要怎麼安排、程式怎麼規定，那是專案團隊的事。
●系統分析人員：每個交易或功能的需求訪談都已經完成，並彙整到各自的需求文件裡。
●系統設計人員：根據每個交易的需求文件，已經設計並開發好對應的程式。同時單元測試過的內容都正常。

表面上看起來沒什麼問題，對不？每個人都做好每個人自己應做的工作。可惜的是，即使每個人都努力地讓產出滿足驗收清單上的每個檢核項目，卻還是有些莫名其妙的問題跑出來、客戶也會莫名其妙地抱怨系統品質不大好、每個人也莫外其妙地幾乎不懂別人負責的部分。

專案裡的產出，不管是文件還是程式都有許多共用的部分，每個人都用自己的角度處理共用的部分當然很容易令其他人難以使用。共用的地方最好是可以符合全部人都方便使用，那是需要投入時間去整理與調整（設計）的；但是＂為了公眾的利益去作設計，會影響到投入自己的工作的時間＂卻是一種衝突，在管理上不去注重共用的部分而強調個人產出，終究會使大家只留意被要求的地方。

我在Ｎ年前也還是可以用極快的速度達成個人產出目標的，不過每次完成工作後再回頭為新需求修改程式時，總是發現內部已經錯綜複雜到難以變動；這樣的經驗累積幾次後終於覺悟自己還缺少了些什麼。現在的我在進行某個步驟時，都會額外花一些時間去整理共用的部分，但是在與其他較年輕的人討論類似話題時，總是發現他們雖已知道現況有些窒礙而還看不到我所注重的地方。

我並不清楚每個人看待的方向是訓練出來或者是依檢查標準而定，但是消極地不想去碰灰色地帶的心情卻感受得到。每戶人家都自掃門前雪時，共用的通路肯定是不會有人去清理的！

W23 做人的方法(16)──態度與高度決定一切

態度：接收到外來資訊後能與自己想法比對並朝最大的最佳化加以調整。越自我的人越不容易改變。
高度：從不同人的角度來看待一件事物並朝對最多人有利的方向改變。越自我的人越無法從別人的角度看待事物。

這些當然是我自己的解釋，不過卻是從一些事件裡得到的結論。

團隊裡有位超強的工程師，能夠快速地選擇對的技術作出功能，也能夠快速地判斷問題提供作法；聽起來一切都很好，但是唯一的問題是方法沒有適當切割且沒有註解，就造成沒有人的理解跟得上他的思緒。有位專案經理跟他說，寫出讓其他團隊成員可以快速理解的註解與寫法，讓多一點人瞭解他的產出未來可以讓自己輕鬆一點，他回答道：我不會UML，也不會寫敍述性的文件。

2009/05與大主管面談時提到對現有設計的改善作法，他說能夠瞭解我想法帶來的好處，稍晚他安排我與兩位資深工程師討論我的想法。在聽過我的敍述之後，他們說：我們可以聽懂你所想要做的事，但是看不到好處在哪裡？我的作法對做事的人來說是浪費一些時間來換取更多的人快速知道自己做了什麼，看不到好處的意思很可能是因為他們並未從旁人的角度來看待。

前面的工程師留下了很多作品，包括我之前維護的那個產品；這個產品應用在專案時的使用門檻很高，目前被重用的其他工程師都花了很多時間去摸索程式碼。他們異口同聲地說，想要深入瞭解這個產品沒有捷徑，一定要自己下苦功。不過在面對同樣沒有註解且風格與自己不同的程式碼時，那位工程師終於說：看不懂他寫的程式！

有些懷疑現在的大師們是否都在開發上具有強大的能力，以至於他們從未完整維護過全由別人所寫的程式碼？賦予自己的責任是開發系統時自然會專注在這個課題；至於怎樣讓別人容易維護程式碼？管他的，反正我自己維護完全沒有問題而且不會找我去做。

W22 成敗的關鍵(1)──開發速度的考量

專案裡需要一個分析資料結構的功能，該結構裡的ParentDataModel與ChileDataModel是從屬關係，但是都具有相同的屬性存取方法，需要寫的功能是處理多個屬性的集合，從兩種Data Model取得屬性的設定值來檢查是否Class字串。

由於這個功能時間上比較趕，撰寫ParentDataModel的時候就直接只思考它的特性，將完成該方法的功能填在一個Method裡。等到撰寫ChildDataModel的時候發現與前一個方法似乎只有傳入的物件不同而已，但是再抽取前一個方法似乎要浪費一些時間，於是copy-paste後再修改了幾個地方。用極快的速度寫好這個取得屬性的功能。


認真地分析一下，這兩個方法只是傳入的物件與紅色框內的程式碼不同，其他的內容幾乎一樣，裡面包含了兩個分解動作與一個迴圈。開發最快的方式是像前面一樣直接複製後修改物件名程，但是就有一堆重覆的程式碼。理想的作法應該再切分為兩個小方法並串連呼叫才對。下面是把分解動作另外抽出方法的結果，同樣是沒有註解的程式碼卻具有很高的可讀性。


之前提過曾把一個元件的View與Controller寫在一起，寫的時候連測試用了三小時，改寫時連測試又多花五個小時，但是一開始就分開撰寫的話估計應要五個小時；概略計算的話，如果沒有修改可以省兩個小時，修改時要多花五個小時。觀點拉到有100個元件的系統來看，假設未來因需要而有20個需要重構。直接作的時候省下100 X 2 = 200小時，另外花費20 X 5 = 100小時重構，整個開發與測試的投入反而省下100個小時。

這是專案開發裡的數字迷思，缺乏彈性的快速設計反而會比設計充滿彈性的作法快200小時，即使面對需求改變還是快了100小時。以前我估計的設計時間常被說為留有buffer，因為別人估兩天可完成的東西我需要五天；如果你是專案經理的話，會用什麼角度思考而出抉擇呢？

W21 記錄的設計(2)──交易記錄Data Model的集合與應用

經過適當的設計，我們可以從server的Log檔案裡用工具取得所有使用者的交易記錄。雖然從電子日誌的資料庫也可以拿到類似的項目，但是在一個嚴格控管的環境裡並不是隨時都可以接觸到資料庫且隨心所欲地下達想要作的指令。

分析出來的交易記錄可以用人、事、時、地、物各種不同的角度去篩選範圍內的資料，如果篩選的條件有適當的分群可以有更方便的應用，像可選擇從個人角度與單位角度去篩選資料。對於一個時間範圍內（通常是給定的Log記錄範圍），較常見的需求是交易的執行種類、執行次數與執行時間，這可以反應系統的使用效益與效能，也可能被要求作成統計圖表以方便查看。

就曾因交易執行時間過長的問題被要求分析Log，當時拿了五個工作天之間的四台server與十台client的Log記錄後，利用之前寫的分析工具來處理上千萬行的Log記錄，最後得到了客戶反應時間慢的區間內的各種數據用以佐證對於問題所在的推測。另外，查看個人在某個時間點所作的事情序列，也是除錯時重要的資訊。

概略說之，全部Log記錄檔還是以Data Model的方式來看待，裡面包含的每行Log記錄組合為一個個的交易記錄Data Model後，就能夠像是搜尋資料庫一般篩選出任何需要的資訊──當然，前提是Log記錄的內容要能確切反應出該時間點的系統執行資訊。

W20 現在的執行位置──getClass()與getMethod()

在Log裡的記錄需要註明程式的出處時，一定會用到getClass()，經由這個方法可以取得Class名稱；但是再細部定位到程式的發生點時就只能拿到行號，然後再找程式碼看看那一行是在做什麼事。

為什麼拿到的資訊不是Method Name而是與程式碼內容無關的行號呢？在執行時有getClass()與this可以取得現在執行的物件資訊、卻沒有getRunningMethod()與thisMethos（二者均為虛構）等取得現在執行方法的功能呢？推測應該與程式設計者較注重結果卻不注重過程有關係──因為只要知道確實在哪裡出錯就好，不需要知道原來想要做的目的。

若去詢問什麼樣的程式碼需要被抽取到Method存放？一個很尋常的答案是＂發現某一段程式碼在其他地方存在且完全相同時＂，這就是我感到奇怪的地方。檢查兩段程式碼是否相同的觀點僅是查看其外表，但是我一直認為程式碼被群聚為Method是它們屬於分解動作之一才會被提出的。重構的觀點提到＂有一行註解之下的一段程式碼可以抽出為一個方法＂，這比較接近事實，不過要如何保證一行註解之下的是＂一段程式＂而不是＂三段程式＂？

Method抽取時依這樣的概略原則拿到的可能是錯誤的對應：或許是應該在一起的程式碼被拆開，或者是不該在一起的被放在一起，這些都會在某些場合下造成系統的複雜調整。當每個Method都是依照負責某個行為的目的而被建立起來之後，才會有對getRunningMethod()的需要。

註：目前的getRunningMethod()可以利用Exception裡的printTraceStach()來達成。將這個內容輸出為字串，就可以解析出指定位置的完整method call stack，利用此方法可以省下在很多方法內插入Log的時間。

W19 記錄的設計(1)──記錄行與交易記錄Data Model

系統執行狀態與歷史的內容能夠提供許多分析的資訊，這些資訊我們習慣在執行中隨時記錄為Log。不過Log的特性是一次記錄一筆與上下文無關的文字，所以如何在一行文字間涵蓋到重要的資訊以及建立起前後Log的關聯，是定義記錄內容的重要關鍵。

對單行記錄而言，人、事、時、地、物五個基本資訊加上想要記錄的內容應是最基本的構成。記錄的內容原則上是由能識別系統行為的關鍵字，加上進行該動作時所需的相關資訊所組成；這部份最好是格式化為固定字串，能夠轉換為基本Data Model會較容易處理。

在一個交易期間會有多行的記錄存在，因此要定義交易開始與結束的記錄內容，夾在這兩行之間的表示為同一個交易期間。以範圍框住同一交易的想法雖然沒錯，但是遇到多執行緒執行交易時會發生兩個交易內容混雜產出的問題，因此記錄行必須再定義一個交易序號的資訊以供識別。此外多行交易記錄經過處理應該能夠取得一個交易記錄Data Model，具有從交易方面看待時應有的執行屬性。

記錄行的意義與達成目標的分解動作是很相似的，記錄的是單一動作的執行內容；交易記錄的意義則像是功能的定義，在裡面可取得執行時的相關資訊。記錄行主要提供的是有沒有進行該項動作、有沒有錯誤發生，交易記錄主要提供的是該交易的基本資訊、輸出輸入資訊與結果；前者是系統人員所檢視，後者則應用在使用交易的記錄分析。

W18 快速開發的工具(3)──進化為系統分析工具（SA Tool）

限制整個Workspace的UI編輯工具為只能編輯專案層級的元件時，編輯的對象就會只有Use Case下的流程，選用的範圍則是該tier提供的Activity。執行流程的定義只是SA的一部分，所有與交易相關的定義都應該被容納到系統分析工具裡才是完整的SA Tool。

這表示交易相關的輸入與輸出都要被考慮，像是畫面的設計、列印的格式、主機電文的切割定義、主流程的功能選擇、輸出入欄位與Context的對應……等等都應該呈現在工具裡。另外整個系統的設計也應該被定義，像是角色的定義、交易的定義、資料的定義、以及任二者之間的關聯……等等。SA Tool的好處在於進行需求訪談的同時，可以利用系統收集全部相關資訊並立即使用，在快速定義交易的同時盡量避免產生一些已知的問題。

上述每一個編輯項目都應該要能嵌裝與拆解，施行時視系統實際的架構關聯來設定SA Tool應該具有哪些模組。這是一個更龐大的工程，系統開發時所需要的一切概念組成的架構與關係需要精確地定義與設定，再根據這個架構去設計呈現的UI編輯工具；我們當然明白，只要那個架構有所變更就會影響到SA Tool需要再度改寫。換句話說，除非能夠研究出開發系統時會有的所有定義與關聯，要不然SA Tool應該是個會被改來改去的玩具，或者是寫死為只適用在自己專案裡某部分的特定工具而已。

＂可被遞迴處理的元件結構＂是對程式設計的目標，＂通用的系統分析工具＂則是對系統開發的理想。縱使這兩個想法的背後都需要艱難的分析設計與實作，不過若能確認能夠解決大部分的現有問題而沒有邏輯上的破綻，這個決心是不會變的。