遞迴(recursion)，融合了數學簡潔力道，於電腦科學領域被廣泛的利用。雖簡潔有力，相較於非遞迴(Non-recursion)，遞迴式於執行時期會耗用系統的stack資源。這跟專案執行過程相似，各種決策都牽動著公司資源。設計遞迴首重找出收斂方程式，當然執行專案也請努力找出收斂式吧！在此暫且謂之『Convergent Project Equation(專案收斂方程式)』囉。
有寫過程式、讀過演算法或資料結構等相關領域的朋友們，應該對遞迴此一名詞不陌生。遞迴總是可以用極簡的遞迴方程式來表達出想要執行的運作。最經典的例子諸如：Fibonacci Number、Honai of Tower...等例子，不用太多的註解，不用太多的說明，言簡而意駭。
遞迴的設計首要注重的就是要找出收斂的遞迴方程式(recurrence equation)或稱為遞迴關係(recurrence relation)，若遞迴方程式形成發散現象，將造成系統於執行期間無限制的呼叫遞迴產生stack overflow之runtime exception。
上述的遞迴設計重點，我到覺得跟軟體專案的執行很像。當專案開始進行時，如同系統開始進入runtime，而專案過程總是跟user會有反覆的溝通、訪談、建置、意見回饋等循環的週期，這到很像遞迴式一樣會一直反覆執行自行呼叫。同前述遞迴設計首要需有一個收斂式出現，專案執行過程不也是如此嗎？請用心的不斷在進行過程中收斂需求、收斂意見、收斂範疇。請注意：若不適時的找出專案的收斂方程式，company resource overflow will be there！
可悲的專案發散方程式。奇怪的是，好多人把專案搞的如同發散式，永無止盡的執行下去，一下說為了服務、一下說是滿足需求、一下說是範疇變更，呼～還真輕鬆啊！一句沒辦法客戶就是要改…還真是ooxx。在進行中的專案於反覆循環的過程中持續發散，就如同遞迴式無法收斂於執行期間反覆呼叫，最終的stack overflow，代表著是悲劇的收場；同樣的進行中的專案會一直吃公司的資源，就如同遞迴會一直吃stack資源一樣，發散的專案將耗盡公司的資源直到公司員工耗盡為止，最終就是舉白旗投降(也就是stack overflow啦！)。搞軟體搞到EPS被製造業遙遙領先這也算是台灣奇蹟了吧…
Remember！遞迴找不到收斂式那就少用遞迴吧；專案無法掌握收斂方式就少接專案吧。就算空有再好的工程師，能設計出再有彈性的系統架構，當專案的收斂方程式無法獲得，就如同有一堆極佳的程式設計師，但找不出遞迴收斂式時也是白搭。感嘆的是很多軟體公司如果不接專案卻又沒辦法過生活，其實軟體的代工、專案的建置不可悲也並不廉價，廉價的是用錯的方法衍生出的連帶效應。想想法拉利的代工技師吧，他們可不廉價呢～而是超有格調的打造著使用者所委託的物件。
Find out the convergent project equation. SI company will be fine.
留言列表
