: 这个问题，程式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