6 个解决方案
#1
一般在设计完成后,做项目开发计划制订时候需要对编码规模进行估计,这样根据模块划分和功能的复杂程度,对代码规模进行估计,然后根据历史的编码效率,比如每人天的代码行数,能够大概估计出开发周期,从而指定开发计划。
这些都是基于良好的历史积累和一定的规模估计经验才能够进行,最初看来是比较麻烦的事情,但是做过几个项目后,制订的计划会越来越准确,对于项目管理者和开发人员都是一个好事情。
这些都是基于良好的历史积累和一定的规模估计经验才能够进行,最初看来是比较麻烦的事情,但是做过几个项目后,制订的计划会越来越准确,对于项目管理者和开发人员都是一个好事情。
#2
按代码行收钱,不太合理吧,那你多写点费代码,比如多定义些变量,钱不就多了,哈哈
#3
tomcat_jb说的有道理,应该在设计完成,编码开始之前对功能模块的难道和复杂度进行评估,进而确定工作量,现在谁还按代码量还评估工作啊,大家都知道,高手写的代码简捷高效,复用性高,只有不会编程的人会为了实现一个功能写一大堆代码的,楼主,你的问题是想出来的,还是实际中确实存在的问题?
#4
按代码算很不合理,许多优秀的程序员往往代码简洁,而烂的程序员代码臃肿
#5
按照代码行数计算工作量的最有效的是在汇编时代,现在的软件系统的工作量估算已经很少有人完全按照代码行数来进行计算了。
#6
微软的程序员每年才写几百行,那不得饿死?
#1
一般在设计完成后,做项目开发计划制订时候需要对编码规模进行估计,这样根据模块划分和功能的复杂程度,对代码规模进行估计,然后根据历史的编码效率,比如每人天的代码行数,能够大概估计出开发周期,从而指定开发计划。
这些都是基于良好的历史积累和一定的规模估计经验才能够进行,最初看来是比较麻烦的事情,但是做过几个项目后,制订的计划会越来越准确,对于项目管理者和开发人员都是一个好事情。
这些都是基于良好的历史积累和一定的规模估计经验才能够进行,最初看来是比较麻烦的事情,但是做过几个项目后,制订的计划会越来越准确,对于项目管理者和开发人员都是一个好事情。
#2
按代码行收钱,不太合理吧,那你多写点费代码,比如多定义些变量,钱不就多了,哈哈
#3
tomcat_jb说的有道理,应该在设计完成,编码开始之前对功能模块的难道和复杂度进行评估,进而确定工作量,现在谁还按代码量还评估工作啊,大家都知道,高手写的代码简捷高效,复用性高,只有不会编程的人会为了实现一个功能写一大堆代码的,楼主,你的问题是想出来的,还是实际中确实存在的问题?
#4
按代码算很不合理,许多优秀的程序员往往代码简洁,而烂的程序员代码臃肿
#5
按照代码行数计算工作量的最有效的是在汇编时代,现在的软件系统的工作量估算已经很少有人完全按照代码行数来进行计算了。
#6
微软的程序员每年才写几百行,那不得饿死?