前两天已经开始后悔我们的选择，现在更加离谱的事情来了，那个老板给我们买来了脱排和煤气灶，对我老婆说是帅康牌的，我老婆问了下价格，他不愿意说，说不会超过我们的标准，我老婆说1500左右的就可以了，老板说就那个价格，后来老婆去验货，发现脱排的盒子上印的是帅康小旋风，而煤气灶上是帅康飓风，说明书里面则没有牌子，老婆打了煤气灶的说明书上的两个上海的维修电话，一个无法接通，一个不存在，然后跟老板说了，他说现在没有时间，明天再说。
我回来查了一下，恰好有和帅康小旋风相关的新闻，都是伪劣产品新闻，另外那个帅康飓风的煤气灶假得更直接，说明书上没有具体的厂家名称，上网搜索了下，帅康确实有飓风系列产品，但是全部是脱排。
那个老板真的把我们当作什么也不懂的傻子吗？或者是有心试试我们？或者完全是有恃无恐想宰我们一笔？
但愿我们这次遇到的不是黑社会的
解惑
解己之惑，解人之惑
日：2007年4月3日
这个并不是我一时兴起的胡言乱语，而是我的肺腑之言。如果你仔细的审视一下你所在的项目的代码，你可能会发现其中60％以上的代码是何其的类似，充斥其中的都是类似的判断和循环，在项目的框架或者架构稳定下来以后，项目的工作就是每天重复类似的工作，然后就是这些类似的代码的比例越来越大。如果项目的架构或者框架代码不够好，而某一天有一个需求导致这些代码都要进行某种简单或者复杂的更新，那么你的噩梦就来了。
软件开发的最大困难也就随之出现，如果你的框架足够好，共通的需求只会导致一个或者有限的几个地方的修改，如果框架不好，那么你就准备把那个修改重复几十遍或者几百上千遍吧。衡量一个软件的设计是否足够好，我想最重要的标准就是它能多大程度上消除这样的情况。仅仅有了好的架构其实也不够，开发人员可能会复制一段类似的代码，导致超出框架设计的代码重复，这个就是检验项目管理是否足够好了。
设计一个简单易懂、易于扩展、易于维护的框架并不是很难的，结合OO设计的原则和一些设计模式就可以做到，但是问题并没有结束，如何消除业务代码中存在的类似代码结构才是真正的问题所在。
我没有解决方案
当然，软件开发也并不是只有消除重复代码这一个问题，但是我感觉，如果能够较好的消除代码重复，那么软件的开发效率和质量以及可维护性将更好。
PS：我并没有说完全消除重复代码，代码的重复性是不可避免的，典型的例子就是单元测试代码。
每个人设计API的思路可能都不一样，而我们公司的一些代码的API的设计很有意思，一个例子：
public AppGroupConfigValueObj get(UserSession _userSession, AppGroupConfigValueObj invo) throws DataException
{
long start = System.currentTimeMillis();
try
{
Long id = (Long) invo.getId();
if (isDebug() )
SessionLogManager.getInstance().getLogger(this.getClass()).debug("get group" + id);
AppGroupConfig eb = this.appGroupHome().findByPrimaryKey(id);
if (isDebug() )
SessionLogManager.getInstance().getLogger( this.getClass() ).debug("Get( UserSession _userSession, AppGroupConfigValueObj invo) elapsed time = "+ (System.currentTimeMillis()-start));
return get(eb, invo);
}
catch (Exception e)
{
throwException(e);
}
return null;
}
private AppGroupConfigValueObj get(AppGroupConfig eb, AppGroupConfigValueObj invo)
throws Exception
{
AppGroupConfigValueObj vo = (AppGroupConfigValueObj) ServerUtil.getValueObj(eb);
if (invo.getApps() != null)
{
Collection collection = eb.getApplications();
if (invo.getApps().getCount() == 0)
vo.setApps(new ValueObjList(collection.size()));
else
{
Iterator it = collection.iterator();
while (it.hasNext())
{
AppConfig a = (AppConfig) it.next();
vo.addApp((AppConfigValueObj) ServerUtil.getValueObj(a));
}
}
}
return vo;
}
解释一下，这个API的功能是这样的，主要参数AppGroupConfigValueObj 是一个Map结构的对象，另外包含一些父子关系，如果你需要的是一个轻量级的结果，那么传入的对象只需要设置ID就可以，典型的用法是这样的：
get(cuSession, new AppGroupConfigValueObj(appGroupId))
如果你需要一个重量级的结果，也就是需要它的一些子表的数据，那么就要设置子表的关系，并添加一个空的对象：
AppGroupConfigValueObj appVo = new AppGroupConfigValueObj(appGroupId);
appVo.addApp(new AppConfigValueObj());
get(cuSession,appVo);
还有第三种用法，就是你希望那些子表数据不填充，但是需要知道子表数据有几个，那么你的调用代码就是：
AppGroupConfigValueObj appVo = new AppGroupConfigValueObj(appGroupId);
appVo.setApps(new ValueObjList());
get(cuSession,appVo);
我不知道这种做法源自何处，但是很明显是原来的某位高人，而比我资历更老的一些同事沿用了这个做法并且没有在文档中记录这种方法，当我苦苦寻找一个简单的get(cuSession, appGroupId)方法时没有任何结果，最后看其它部分的代码才知道了这个诀窍。
以前也经常遇到这个问题，但是没有找到解决方案，今天再次遇到这个问题，搜索了下没有什么头绪，很多答案试验了下都是错误的，不得已，自己试吧，最终的结果是：
replaceAll("\\\\", "\\\\\\\\")
就是把字符串中的\替换成两个\，呵呵，变态吧。
我们已经开始了一个新的阶段，这个阶段的开始并不顺利，因为我遇到了一个原来并不是很常见的问题，我竟然找不到合适的API供我使用，而且是我们系统的基础服务的API，原因不是别的，就是因为命名规范，第一是方法名，原来的很多API的方法名就是开发人员随意取的（我们没有编码规范或者说命名规范），一个公共的Session Bean的Proxy的方法名竟然叫getAll，而它仅仅是返回一个特定的对象的集合，一般这样的方法都应该叫getAllXxxx，第二是有些术语修改了，但是只是把界面上用户可以看到的文字修改了，后台的API的方法名和类名都没有修改，如果你不是相关的开发人员，你怎么可能弄清楚呢？而原来为什么没有修改方法呢？很简单，一些少数的地方使用反射调用，所以用IDE的重构方法可能会漏掉一些地方，所以他们不敢改，举一个真实的例子说明这个命名的修改导致了多么大的问题：
app group-> app
app template -> component
app -> component instance
说实话，在这一点上，我们的产品实在是失败，因为自从我做开发依赖，所去过的公司还没有说哪个公司没有命名规范的。
© 2025 解惑
本主题由Anders Noren提供 — 向上 ↑