由於這個功能時間上比較趕，撰寫ParentDataModel的時候就直接只思考它的特性，將完成該方法的功能填在一個Method裡。等到撰寫ChildDataModel的時候發現與前一個方法似乎只有傳入的物件不同而已，但是再抽取前一個方法似乎要浪費一些時間，於是copy-paste後再修改了幾個地方。用極快的速度寫好這個取得屬性的功能。
認真地分析一下，這兩個方法只是傳入的物件與紅色框內的程式碼不同，其他的內容幾乎一樣，裡面包含了兩個分解動作與一個迴圈。開發最快的方式是像前面一樣直接複製後修改物件名程，但是就有一堆重覆的程式碼。理想的作法應該再切分為兩個小方法並串連呼叫才對。下面是把分解動作另外抽出方法的結果，同樣是沒有註解的程式碼卻具有很高的可讀性。
之前提過曾把一個元件的View與Controller寫在一起，寫的時候連測試用了三小時，改寫時連測試又多花五個小時，但是一開始就分開撰寫的話估計應要五個小時；概略計算的話，如果沒有修改可以省兩個小時，修改時要多花五個小時。觀點拉到有100個元件的系統來看，假設未來因需要而有20個需要重構。直接作的時候省下100 X 2 = 200小時，另外花費20 X 5 = 100小時重構，整個開發與測試的投入反而省下100個小時。
這是專案開發裡的數字迷思，缺乏彈性的快速設計反而會比設計充滿彈性的作法快200小時，即使面對需求改變還是快了100小時。以前我估計的設計時間常被說為留有buffer，因為別人估兩天可完成的東西我需要五天；如果你是專案經理的話，會用什麼角度思考而出抉擇呢？
發表文章
還是看不大懂...
回覆刪除最終到底是充滿彈性的設計快, 還是缺乏彈性的設計快科科呢? 而老闆和客戶是出錢的人, 要如何能提出證明呢
對完成功能而言, 直接把作法堆在一個method, 再以copy-paste作好近似的功能實在是快到不行. 但有幾個明顯的缺點:
回覆刪除1)最大的缺點是有重覆目的的程式碼: 一旦設計有誤或是需求變更, 所有複製的程式碼都要找出來修改, 只要漏一個就會被客戶罵品質不好. 這是重構時檢查的一大重點.
2)不易重用:在其他功能發現需要檢查一個字串是否存在對應的Class時, 從第二種作法可以找到已經作過. 第一種作法則很難發現, 然後通常會直接寫一個新的方法作同樣的事, 又會發生第一點.
若用快速而缺乏彈性的作法, 在功能很多的大系統下還會發生使用關聯雜亂的問題, 光是解問題本身與side effect就投入遠超過用較有彈性作法的資源(自身經驗).
老闆與客戶一定要"快速開發", 但是經過幾次上述經驗之後, 他們發現反而更浪費資源且品質不好, 終於明白reuse與彈性的重要----只是要求變成了"快速開發出有彈性, 有品質的系統"!
:(
為了彈性勢必多做一些事, 多做一些事一定需要多投入一些資源. 由於少做會讓彈性與品質出問題, 所以事不應減少; 基於多投資源做事會提高成本, 所以老闆與客戶不希望如此.
回覆刪除所以最佳的平衡解法是: 想出一個可以快速做到那些多做的事的可行作法, 同時讓產出的東西兼具容易reuse與快速組裝的優點.
聽起來很高調, 對吧? 這兩年來我一直朝這方向的實作思考, 目前仍認為是可以達成的.