※ 引述《ggg12345 (ggg)》之銘言： : 外包式訂製型軟體用上館子套進去還是對不攏, 從現在台灣流行的需求規格到 : 驗收, 怎麼說都像古代木工匠蓋房子的做法, 是僱長工做工程的形式, 完全看 : 大戶人家給的銀子, 一段一段的接著做, 找不到好的木工師父就停擺. 魯班木 : 工師父是要學藝很久才能出師的. 那裡像台式洋學堂, PG 是靠自修自練. 學藝多久不是重點，重點是客戶完全是未開化的軟體蠻人，就算對方是派學有專精 的IT人員來負責初步接洽，但是他們的上級多半不是在這行很有sense的人，愈是 在主管職待久的、愈是有內部權威的、記性愈差的，愈傾向朝令夕改，今天不記得 昨天決定了什麼，明天又不記得今天決定了什麼，一個月反覆改變意見十次也不奇 怪。就不用說尊重專業了：什麼事情是Java或Windows上不能做到的，他們不會在 乎；什麼事情是某個平台上很難做到的，他們也不在乎。 高高在上久了的人，多半不會面對這種朝令夕改的窘境，反而比較像是讓他人面對 朝令夕改窘境的人。就像數學家證明「x^n+y^n=z^n，當n,x,y,z為正整數，在n>2 時無解」證明了三百年，一個小小的額外要求耗費的工程可能超乎外行人的想像。 在這種環境待久的人會明白，針對這種情況，應對之道不是要求客戶盡快定案所有 feature request，而是把自己的系統設計得靈活有彈性，不管怎麼改都很好改， 可以迅速改好、新增刪改任何功能。 怎樣以最小程式、資料變動去應付最大需求變化，agile programming, agile database management, 一堆agile相關技巧都是用來應付這種鳥事的。台灣的學校 不知道要到何年何月才會教這種東西。 Workflow的概念讓資訊系統處理工作流程的變更成了更容易的事情，我們能不能把 同樣概念應用到code flow, data flow？從流程圖可以生成BPEL，有些BPEL4J engine 可以從BPEL生出Java code來。.NET也有CodeDOM能將表示語意的expression tree 自動雙向轉換成C#/VB.NET/IL code，程式功能的修改可不可以簡化成只是重新畫 幾個圖，就盡可能重複使用舊code來實作出新功能來？ 不斷重複打造大同小異的輪子，你捉摸出萬流歸宗的道理了嗎？程式中會出現的 design pattern就只有那些，business process pattern就只有那些。可是道行 粗淺的程式員還是得為了這些大同小異的東西天天在那邊新增刪改一堆code，時 間就是金錢，我們雖然很難管理野蠻客戶的需求變更，但是我們還是可以想辦法 把程式員需要的勞動與生出的bug數降到最低。 從一個系統的各部分可以切割出變動性大小不一的部分。除了面對未開化客戶的 反覆變動需求，程式員也可能要面對豬頭SA/SD/主管的變更要求，像是案子做到 一半才要變database table schema，要求你變動一些function/method/class/ interface name，怎樣把變更時間降到最少，可能製造的bug降到最少？這種事情 ，往往不是在IDE或文字編輯器裏頭用個Replace in files的功能替換一下字句就 解決了的。各家IDE近來新增的refactoring功能雖然減輕了人們面對類似要求時 的負擔，但是更核心的問題還是少有人觸及：當你一定要面對這類變動時，你能 夠有什麼樣的方法，以不變應萬變的，以最少代價去應付這類問題？ 第三種需要變更程式的情形，就是既有的code出了bug。當我寫一個新功能，我 也有可能同時引入了一個以上的bug。我要怎樣方便測試者與客戶在出問題時， 更快找出問題出處，更快解決問題，不用等到我把新引入的bug修掉？人們寫程 式時，如果能時時回到這些問題上反覆思索，必然能有所得，讓自己把事情做得 更好、更快。在動手寫code之前先把這些事情想好，日後所要花費的額外變動功 夫就會減少。 改變他人，不如改變自己。你不肯接受變更，別人肯，你的生意可能就飛了。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 122.116.40.228