: 這個問題，程式scale小的時候當然差異很大，可是程式scale大的時候呢? : 我想LoC不見得會差到五六倍，而且單看LoC當然不準，可是混合其他指標一起看呢? : 每多少行會出現一個bug難道真的沒有意義嗎? : 我知道很多人會舉那種從幾千行code裡面找出幾十行來改的例子，可是就一個軟體產品 : 來說總不能全部的人都做這種事吧? 不然那幾千行程式誰來寫? PSP本來就是用來評估 : 一般程式員的基礎表現，它沒辦法評估超人一秒鐘可以繞地球幾圈。 這個部份我覺得leicheong大的文章內已經提了很多..我就不贅言了... : 軟體工程之所以會稱為工程，背後追求的就是可預測和穩定的產出，一個軟體降到 : 單兵的層級可以發揮的地方並不多，就算寫ACM這種比賽用的程式到最後也是套pattern， : 我個人認為要量化並非做不到。 : 關於這點嘛，其實大部分的人並沒有真的想過如何去增加自己的產量， : 我指的不是把C/C++念得更熟之類的方法，而是在開發程式的流程上作改進。 : 做Record可以讓你找出自己的瓶頸在哪裡，這個部份人人不同， : 至少有個依據知道自己寫程式最花時間的點在哪裡，總比抓瞎改強的多。 我想軟體工程的目標是將軟體開發流程工程化.. 將所有因素都列為可以預估的..這一點大家應該都沒意見可以接受... 但我所質疑的是PSP這一套方法..所估計出來的是否是真正合用的數據... 因為就我所知道裡面所提及的一些量測的方法..像LOC那些... "我個人覺得"並沒有辦法真正表現出每一個程序員真正的生產力... ok..如果PSP本身估算的方式就有問題了..那所提供的出來的數據.. 又怎麼會符合軟工本身的目標呢?? 以上是就我念過的記憶所言..詳細的PSP內容我可能還要再去看一下... 畢竟是兩年多前的東西了...(遠目~) : 我們一直在說人家的方法不好，可是人家用這套方法已經上太空去了， : 台灣還在原地殺豬公，可能真的要等三太子上身才有超英趕美的一天了。 嗯..就我個人來說..我本身也是學軟工出身的.. 當然不會排斥這些..而留戀於殺豬公的現狀... 不過我是認為那些所謂的大師理論..我們不見得要照單全收.. 像TSP裡面很多guideline我就覺得很不錯..但是PSP有些內容我就覺得沒道理了... 理論就是用來被推翻的..盡信書有時不如無書..共勉之吧~~ -- PM: 這個案子,多久能好? 我: 五日之內,一成功力,沒能寫完,不留人頭.. -----------------------五日後---------------------- PM: 客戶在要了,東西勒? 我: 罪人恭請主公獻頭~ (抖~) PM: 媽的!! --

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