软件过渡开发: 就是程序员使用了不必要的方法, 对所开发的软件在可用范围外, 采取了不必要的扩展. 分为技术和业务上的过渡. 技术上, 程序员一般为了学习的目的, 将新学习到的东西用到了日常的工作上. 业务上, 程序员希望将一些组件进行无限的扩展, 以满足可能而未形成需求的设计.
任何一个项目经理或开发经理对此都头痛不已, 不仅不能按时完成任务, 还造成软件性能低下, 难以维护等问题.
新技术
新技术是过渡开发的头号罪人. 有时候, 对于一个很简单的需求, 无论是客户/经理/销售/技术主管往往推荐使用最新的技术(当然是各有目的的), 最先进的设计. 结果呢?不言而喻了. 我曾经接手过一个系统, 有两期. 第一期使用jsp/servlet, 第二期使用的是struts, ejb. 留给我的只有痛苦了, 第一期的程序较整洁, 写的东西易懂, 直接, 维护也很简单. 而第二期的程序要边改边骂, 客户不满意速度, 也不满意效果.
新方法.
来看看这个程序.
类:
class A{
private int id;
public void getId(){
return id;
}
public void setId(int id){
this.id=id;
}
}
方法A
A getA(){
A a = new A();
a.setId(getValueA ());
return a;
}
方法B
interface Updater(){
public int getValueId();
}
class A1 extends A{
public A1(Updater upd){
setId(upd.getValueId ());
}
}
A getA(){
A1 a1 = new A1(new Updater(new Updater(){
public int getValueId(){
return getValueA();
}
}));
return a1;
}
可以对比一下, 方法A和方法B. 从几个方面看, 代码长度/执行效率/可维护性, 谁优谁略? 真难以想象, 可以写的出方法B的程序员能花那么多心事去写这么些”有难度”和”挑战性”的代码来.
未来需求
这是一个有想法的设计师或程序员经常会犯的错误. 我也曾经犯过这个错误, 当时需要操作一个XML文件, DOM提供的方法不太够, 就花了好几天写了一大个XML文件操作的通用类. 结果时间花了不少, 能用到的方法也就那么一点. 现在想想, 以前也确实傻得可爱.
要知道什么是需要得, 什么是对事情没有帮助得, 我慢慢长大.
