※ 引述《chihyi1980 (喵球)》之铭言： : ※ 引述《iincho (..)》之铭言： : : PSP并不能代替资深工程师review，他只是提供一个量话指标让你去评估自己程式的品质， : : 两者并不冲突，很多时候必须要两边都一起做才能真正达到评估/提升程式开发人员的素质。 : : 最主要的不同点是，code review是为了提升软体品质，不是拿来衡量程式员能力的活动。 : : 依我再某个专案运用PSP的结论，至少我可以大约估计我的LOC/bug是多少，比较容易分部在 : : 何种情境，单位时间的生产量是多少，准不准不知道，但是做为估计schedule的材料 : : 倒是蛮好用的。大部分的程式设计师都蛮抗拒自己的工作表现被量化，理由其实不外乎， : : 1.不了解 2.出来的数字很难看，尤其是很多时候所谓的资深程式设计师出来的数字..嗯嗯.. : 我想我这样说吧...就像您所说的LOC/bug指标.. : LOC是什麽? Lines of Code.. 程式码的行数..PSP里面很常提到这个东东.. : 问题是LOC真的能够代表生产力吗? : 有人可以用一两行解决问题..有人要用十几行来写... 这个问题，程式scale小的时候当然差异很大，可是程式scale大的时候呢? 我想LoC不见得会差到五六倍，而且单看LoC当然不准，可是混合其他指标一起看呢? 每多少行会出现一个bug难道真的没有意义吗? 我知道很多人会举那种从几千行code里面找出几十行来改的例子，可是就一个软体产品 来说总不能全部的人都做这种事吧? 不然那几千行程式谁来写? PSP本来就是用来评估 一般程式员的基础表现，它没办法评估超人一秒钟可以绕地球几圈。 软体工程之所以会称为工程，背後追求的就是可预测和稳定的产出，一个软体降到 单兵的层级可以发挥的地方并不多，就算写ACM这种比赛用的程式到最後也是套pattern， 我个人认为要量化并非做不到。 : 光是以前程序导向的语言要用LOC来估计单位时间的生产力..我就觉得有点难了... : 现在常见的物件导向语言又要怎麽能用LOC来估生产力呢? : 这是我觉得PSP的问题之一... : 另外就是.. : PSP希望程序员要自己作纪录..程序员本身"每一分钟在做什麽".. : 用此纪录配合LOC来估计生产效率.. : 这是我认为更不合理的地方..每个人的能力与习惯都不同.. : 有人会一边写一边改边想.有人会通通想好了再开始coding... : 这两种人可能实际产能相同..但估出来的单位时间生产力会相差甚远... 关於这点嘛，其实大部分的人并没有真的想过如何去增加自己的产量， 我指的不是把C/C++念得更熟之类的方法，而是在开发程式的流程上作改进。 做Record可以让你找出自己的瓶颈在哪里，这个部份人人不同， 至少有个依据知道自己写程式最花时间的点在哪里，总比抓瞎改强的多。 我们一直在说人家的方法不好，可是人家用这套方法已经上太空去了， 台湾还在原地杀猪公，可能真的要等三太子上身才有超英赶美的一天了。 : 我个人不反对一个程序员的生产力被量化.. : 但是评估的方式要正确才有用啊..不然只是浪费时间在做这些杂事罢了... : 举个例子: 我之前的公司要求大家要配合CMMI, 要"详细记录"你每个时段所做的事. : 但是填写这份报表的时间, 却又不可以写在每周工时内..搞到最後大家只能东拉西扯的 : 硬塞完这份表格... 这是执行面的问题，和方法不可混为一谈。 : : 绝~~~对~~~不~~~要~~~拿这些数字来当绩效评比的依据!!!! : : 所谓的程式设计师是地球上还算有点脑袋的一小部分生物，只要知道这些数字会被拿来 : : 当绩效评比，保证最後看到的不是真正的数字，因为他们会作帐，比如说你会发现有些 : : bug永远不会在帐面上出现..。 : : 拿来当自己程式设计能力的一个指标到是不错的方式。 : 不要拿来当绩效这一点我倒是相当赞同.. : --- : 抱歉,不是要战你,只是针对PSP的作法有点意见... --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 211.76.240.242 ※ 编辑: iincho 来自: 211.76.240.242 (06/20 02:40) ※ 编辑: iincho 来自: 220.130.53.4 (06/20 09:46)