2010年6月25日 星期五

X30 程式寫作員的未來(8)──重用的資產

運用交易開發工具可以加快開發速度並做到一致化的產出,如果再進一步分析出交易開發地圖讓開發人員按圖逐一填寫,完成後就等於完成一支交易的訪談。交易開發地圖與業務流程地圖雖然對象不同,但是在基本概念上是很接近的:都是定義其流程、各個步驟與步驟內應完成的事,而這些最終都對應到交易的各個組成單位。

關於“物”所能做的“事”,可以將物定義為一個Interface再將可做之事定義為Method,但是以Strategy方式設定會更有彈性。例如前面提到的身份證欄位,與其使用Interface包含validate、getLocation、getSex等三個方法,倒不如將之獨立為數個Class由工具列出來讓使用者自行勾選要執行哪些來得方便且有彈性。這幾個身份證欄位可做之事(Class)是每個系統都會再重覆用到的,因此需要Reuse Repository來管所有重用項目。



藍色的虛線框裡表示的是使用交易開發工具產出AP執行環境內容的開發模式,Reuse Repository的角色是提供重用的資產給這兩者,不管是加快開發時的設定或是減少測試的時間都會有相當的成效。

Reuse Repository會有一套進管的機制來管理所有的重用項目,同時也要有一套建立版本的機制──該機制會將儲存庫的內容產生兩種版本:一種是給執行環境使用的執行函式庫與預設參數,另一種則是給交易開發工具使用的畫面與欄位資訊以及搜尋用的關聯檔。



上圖是Reuse Repository裡應該管理的項目,以及各個管理項目之間的關聯;關聯的用途是在交易開發工具裡編輯該項目時會列出符合篩選條件的其他項目。例如要新增某個交易畫面時,會列出儲存庫裡該畫面內所有的欄位,開發人員只要勾選這次畫面要用的就能帶入原有的欄位設定;當然逆向的關聯也可以查詢,像是選擇某個欄位得知在哪些畫面裡存在、甚至哪些業務裡有用到。

Reuse Repository在交易開發工具裡是很重要的一環。若可以再堅持所有該管理的項目都被儲存庫管理,還能夠達成所有管理項目都有各自目的而完全沒有重覆的“絕對重用”目標。

8 則留言:

  1. 看你寫那麼多篇但是每個環節都有問題,只是我懶得寫來回應,用別人的文章回應你,
    http://teddy-chen-tw.blogspot.com/2010/06/blog-post_23.html
    跟你寫的是另外一條路。
    不過我的看法兩篇都有問題,上面那篇少點,有空你遇到我,跟你說每個問題點在哪吧!
    就這句『2010年第一季試做了交易開發工具部分概念的POC,試用過的四位SA一致認為運用這樣的工具可以節省現行開發方式25%-33%的時間。』跟你保證他是騙你的,因為那些SA沒寫程式了,怎麼節省開發?而談需求那工具又不夠好用。
    記得,公司是要賺錢的,你的方法如果永遠賠錢代表是壞方法。
    真的業界這十年跌跌撞撞弄出的好的可用的方法,唯有好的工具加上測試導向的開發模式,其實什麼MVC架構都是為了測試導向的開發模式做前導。
    打太多字了。Jwo

    回覆刪除
  2. 每個人的經歷與視野多少會影響對某件特定事物的看法. 其他的不多說, 對以下兩點提出些補充說明:

    1."運用這樣的工具可以節省現行開發方式25%-33%的時間", 計算來自[原本PG看著交易規格書製作的產出改變為SA填寫後自動產生節省的時間, 加上避免人工製作產生的錯誤以及沒有控制設定或程式造成多個重覆狀況等後續問題所浪費的時間, 除以目前開發交易的總時間]. 當然都是依經驗值略估而沒法精確地計算.
    (要將那個POC程式做為最簡單的實用版本不超過6人月)

    2.以前工作所用過的那套開發語音系統的軟體讓我認為程式可以組裝. 當初法國的設計公司詳細分析過語音系統的行為而定義出十多種包含多個參數的指令, 在開發時語音系統的操作根本只要照流程圖組裝就能完成, 需要寫程式的幾乎都是較複雜的資料處理與運算.

    我自己也曾用寫程式的方式來控制語音卡, 因而深深明白兩種作法的差異; 那時遇到過的幾位其他公司的語音系統高手全都是直接寫程式控制的. 如果沒有認真分析歸納過系統內大大小小的行為模式, 絕對不會同意軟體可以用很大的比例來組裝的.

    回覆刪除
  3. 如果要問我, 我推Jwo一票, "軟體是長出來"
    不過青菜蘿剝更有所好

    自己跳下來, 帶大家做一個客戶的專案.
    你就知道什麼是可行的, 什麼是天真.

    眾人皆醉我獨醒, 不一定是好事

    Tony

    回覆刪除
  4. 明明每一行程式都是人為堆砌出來的, 最後卻要說那些程式是長出來的, 我實在沒法認同這樣的觀點. 對人為的事物找出規律性並將之一致化是我的興趣, 所以在這裡做這樣的思考與記錄.

    如同開發應在需求談完之後再開始, 系統行為也應在開發結束後再去分析歸納. 長期在與時間賽跑的專案裡, 很可能被要趕的繁雜事物弄昏頭.

    若願意詳細提供在專案裡視為天真的情況與其原因, 會是很好的經驗分享喔.

    回覆刪除
  5. 你覺得1,000塊才做的出來的東西(品質, 文件, 可維護...所有你想要的都有)

    門口有其它一狗票人說, 他100塊就可以做, 還可以打8折.
    (品質普普, 文件交差了事, 只有原廠商看的懂的程式....)

    一樣驗收

    沒接到專案的人 回家回西北風

    這就是台灣 SI 生態, 會不會覺得天真呢?

    回覆刪除
  6. 要用開發一個系統的錢做好專案還有工具, 當然是很天真; 因為開發工具並不是從單一專案收益來看的.

    我沒法回答系統行為有多少比例可以是通用的, 但是可以理解做專案的人會盡量找現成的好用工具來節省開發成本. 現成的好用工具總不會是憑空出現的吧?

    以現有的經驗思考可行的好用工具, 是我在工作之餘做開心的. 若能有小成算賺到, 沒有進展也沒人損失什麼, 不是嗎?

    回覆刪除
  7. 軟體到底是有制度的規劃生產與組裝好,還是像種菜種花用"長"的好.個人愚見,這答案跟軟體的Scale多少有點關係吧?

    如果要寫一套像是IBM system/360 或SQL Server類的產品,或是登月火箭的控制系統...不知道用長的要長到什麼時候,而且個人的細心照料是否更具風險性?

    而如果要寫一套小型的PIM..用長的應該比較有前途.

    回覆刪除
  8. 所以千萬不要一視同仁, 想清楚成本跟時間.
    花成本做好每一個工具, 當然是正確的.
    可是沒有人能確定會不會一定有下一單.

    快速反應部隊, 跟長期正規作戰應該一定有差距吧, 我想.

    回覆刪除