锁定老帖子 主题:[原创]定论——软件开发的评价标准(1)
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2005-09-27
dohkoos 写道 软件开发最重要的是“效率”吗? 你是站在公司和程序员的夹角中看的吧? 软件开发涉及3个角度:程序员,公司,客户。 软件开发的目标:准时地开发出符合客户要求的软件产品 效率再快,开发出来的产品是不符合要求的话也是白搭。 什么是“效率”?“有效”的工作才叫效率,“无效”的工作那叫速度。 |
|
返回顶楼 | |
发表时间:2005-09-27
以一种合适的方法带动80%的团队成员快高效、开心地完成任务,剩下的20%回家种田去即可。
|
|
返回顶楼 | |
发表时间:2007-03-31
dlee 写道 无明 写道 有经验的开发人员是如何下这个判断的,就是我们最想知道的啊
这又回到了我说的“道可道,非常道”那句话上了。你心里会说,这家伙不好好回答问题,跟我玩起了玄学了!可是很多时候经验确实不是很轻易地就能从一个头脑传递到另一个头脑的。我和我的朋友 ly 合作了一年多,其间因对技术问题的不同看法发生过数次争论,现在才比较充分地理解了他的很多设计意图。发现以前由于经验上的差距,未能理解他的设计,他的很多想法其实都是非常正确的。 我可以举出很多虽然很流行但是目前对于我们这个特定的开发团队短期内(我加了这么多限定词就是害怕引起争论,否则有人就会义正词严地驳斥道:EJB 不能产生商业价值,你不是又喝了两盅吧?)无法产生商业价值的技术——EJB、.Net、AOP、MDA...... |
|
返回顶楼 | |
发表时间:2007-07-16
引用 回到我们的话题上来,我想要说明的就是:一切方法,设计,思路,技巧,如果不能切实的降低代码总数+文档总数,那么他就是“害人”的东西。
这种思想的确有很多可取之处! 但是,感觉是只重视第一次的开发,就不考虑维护了!这个是不是就是软件开发里面的“贪婪算法”呢?! |
|
返回顶楼 | |
发表时间:2007-07-16
问题是,对于有些庞大的,复杂的,迭代的,开发周期很长的项目和产品,80%的时间可能不是第一次编码。
|
|
返回顶楼 | |
发表时间:2007-07-17
YuLimin 写道 以一种合适的方法带动80%的团队成员快高效、开心地完成任务,剩下的20%回家种田去即可。
以一种更合适的方法带动20%的团队成员更高效完成任务(不管你快不快乐),剩下的80%去作销售 (我们老板的想法。) zqrain 写道 问题是,对于有些庞大的,复杂的,迭代的,开发周期很长的项目和产品,80%的时间可能不是第一次编码。
不到20%用来编码50%时间用来修正与变更。一年时间转眼就过去了。 引用 回到我们的话题上来,我想要说明的就是:一切方法,设计,思路,技巧,如果不能切实的降低代码总数+文档总数,那么他就是“害人”的东西。 降低文档总数量? 我不太同意 我认为是要把可能会用到的信息作成索引 减少修改过程中查找的时间。 |
|
返回顶楼 | |
发表时间:2007-07-17
这个效率要包含多个指标,除了开发速度,还要包括:
健壮性,可进化性,可阅读性。 可进化性,瞎起的名字,软件一定要是可进化的。因为我们需要不断适应客户的需求变更。软件当然是能够改变的,但是改变的成本是不同的。有可进化性的软件应该是易于适应变更的,这需要单元测试技术和重构技术的支持。 可阅读性,软件要让别人看懂。开放速度再快,写的代码别人看不懂,或者自己过了3个月就看不懂可,就不是好代码,就是瞎快。仅仅是为了让代码容易阅读,就值得去重构。 应该还有其他的指标,大家集思广益。 |
|
返回顶楼 | |
发表时间:2007-07-17
庄老大干脆直接在第一版改好了,这样舒服得多。
有的人对“效率”有误解。没有质量的效率不是效率。所谓谈效率,一定是在开发满足需求的软件的前提下谈的,否则效率为0,没有谈的必要。 从敏捷的角度看,设计水平的高低,不在于能够在多大程度上准确的预见今后可能的更改,而在于能够在多大程度上用最简洁的设计实现当前的需求。 |
|
返回顶楼 | |