2010年6月11日 星期五

X26 程式寫作員的未來(4)──編輯的範圍

對工具的用途沒有深思的時候,通常認為工具僅止於提供較多便利的功能與加快使用者編輯的檔案編輯器而已;以這樣的想法定義系統開發工具,就會將工具的功能侷限於設定檔與流程定義檔的編輯。這些檔案只是整個系統設計所外露的一小部分,對於開發人員來說還是有很多難以瞭解的地方。

Maven很成功地將持續整合建立產出的目標,定義為多個抽象的步驟,開發人員根據專案的需要決定從程式碼到產出之間要經過哪些步驟、每個步驟要執行哪些活動、再為每個活動指定實作的plugin來進行。它的作法並不是把設定檔攤開,而是以開發者的角度制訂建立版本時想要做的事,那件事要怎麼完成就由plugin來進行。

思維從編輯檔案內容拉高到要做的事情後,可以用不同的視野來看。像是server url與port,原來看xml設定檔時只會想著:要改哪個檔案、節點的xpath在哪裡、值要怎麼放,換一種連線功能時得換哪裡;將實際的設定包裝在plugin裡之後,實作的細節由製作plugin的人關心,開發人員只需要在編輯頁面的對應欄位定義server url與port並選擇實作的plugin而不需要知道設定到哪裡去。

這個想法同樣可以應用在畫面上的欄位。例如與顧客身份有關的畫面都會有身份證(ID)欄位,針對欄位存取值是基本用法,但是欄位有哪些事可以做、怎麼設定要做的事卻是工具可以做的功能。在身份證欄位這個“物”確定之後,像是validate(檢查碼驗證)、getLocation(所在地)、getSex(性別)這些“事”都是它特有的操作,因此工具在選定身份證欄位後就能列出所有可做之事並勾選要做的。

若要將整個系統的開發範圍定義為開發工具的話,每一個集合範圍都應該要對應到一個專有的編輯器而不要混用。例如需求分析後定義系統層次為系統─業務─交易─欄位四種的話,就要設計四個對應的編輯器再依照擁有關聯定義串接的關係,這樣才會比較貼近開發人員的使用習慣。

沒有留言:

張貼留言