最近真是忙的昏头转向，再加上天气逐渐转冷，很是有些不爽。今天dreamhead提醒我好久不更新Blog了，我也想更新，但是写点什么呢，工作相关的吧。

今天抽出一点儿时间来改一个系统的大Bug，这个问题早已定性，只是由于修改工作量较大，范围较广，而不敢轻易修改。不过眼看系统要上线测试，不改也不行了。

问题主要是由于系统锁资源使用不当，导致有时一些指针在无锁保护的情况下’裸奔’，解决方案就是在业务一层加锁，将底层的接口实现替换为无锁。在修改的过程中常常会遇到这样的情况：

rv = action1
 if (rv != X_SUCCESS) {
  return xx; 
 } 

rv = action2
 if (rv != X_SUCCESS) {
  return xx; 
 } 

action1和action2是需要在锁保护下的两个操作，对于上面的代码在任何一个可能退出该函数的出口，我们都需要进行解锁操作，所以一般方法就是：

locked;

rv = action1
 if (rv != X_SUCCESS) {
  unlocked;
  return rv; 
 } 

rv = action2
 if (rv != X_SUCCESS) {
  unlocked;
  return rv; 
 } 

unlocked
return rv;

这时候一旦还有更多的action或者是嵌套actions，代码维护起来就很是不方便，比如：
rv = action1
 if (rv != X_SUCCESS) {
  if (….) {
   ….
  } else {
   ….
  }
  
 } 

rv = action2
 if (rv != X_SUCCESS) {
  return rv;
 } else {
  rv = action3
   if (rv != X_SUCCESS) {
    return rv;
   }
 }  
…
return rv;

这时候我们会想到在一个’关键路径’上加上解锁操作即可，这段代码在离开该函数前必将被执行，锁资源也必将被释放，而实现这种方式的一个好的方法就是使用goto，我们看一下用goto后的代码。
locked;

rv = action1
 if (rv != X_SUCCESS) {
  goto over; 
 } 

rv = action2
 if (rv != X_SUCCESS) {
  goto over;
 } 

over:
 unlocked
 return rv;
看起来的确简单直观，逻辑清晰，整个函数就唯一出口。有人说goto不好，影响程序的结构化，其实goto很好，关键要看你如何用，滥用当然不好，像那种从前goto到后面，在从后面goto回来的代码是极力不推荐的。记得刚入司时只是教条的记得书本上说不要使用goto，甚至有的C编码规范’三令五申’不许使用goto，看了公司的代码中居然大量使用goto，当时感到不解，在以后的工作中渐渐体会到goto也有它的好处。任何事物都有其两面性，关键看你如何对待了。

饿了!回去煮面吃 － 肉酱面:)

今天部门的一个同事很痛苦的向我求助。问题是关于一个新功能的测试，如果是一般的功能也就罢了，关键是这个功能是基于我曾做过的一个框架的，而这位同事由于是临时被指派的工作，对我的那个东西完全不熟悉。

问题就在这，当时写那个框架的时候目标就是为了部门内部其他项目的高度复用，也就是说其他项目如果有类似需求，使用我们的框架经过一系列配置就可以满足需求，至多需要一个简单的二次开发过程，可能需要提供若干业务相关的接口实现，编译到动态共享库中，把该库的名字和位置写到配置中即可。

这个框架的确消除了很多复杂的且易在各个项目中重复分布的功能，在部门的几个项目中都有使用；而且当初为了使框架更加通用，更加利于二次开发，我们采用了很多外部配置的方式，并且首次在C组采用xml的配置文件，毕竟xml的表达能力要比单纯的key = value型配置文件强大许多，可读性也更好，当初的目标毕竟是理想的。

实际的情况是，这些为了通用型留出的配置接口在实践中用的很少，但是其他第一次接触该框架的维护人员在了解它的时候又恰恰被过多的配置弄得晕头转向，无奈之下就来问我。复杂性由如何开发这些功能，到如何使用理解我的框架了。复杂性转移了。这也让我想起了最近看的关于J2EE中关于EJB的一些言论了。当初Sun在提出J2EE规范的时候更多的是考虑如何屏蔽掉分布式应用的复杂性，让开发人员不用关心分布式技术难点，结果导致最初的EJB只有Remote接口；而在实际应用中大部分Web应用都是部署在Single Machine Sing JVM上的，而Remote接口反倒降低了J2EE服务器的性能，这也许和复杂性关系还不是很大。继续说EJB，到后来开发人员发现要想开发出好的符合J2EE精神的应用，还是要去了解分布式协议的，这就大大提高了EJB的使用门槛，使大部门人望而却步。其实到后来的框架时代我觉得也是一样，框架的出现，一来可以让大家避免使用EJB的痛苦，开发出without EJB的应用，但是同时大家却都忘记了框架本身的复杂性了。试想要开发出好的Web应用，如果不对框架本身有所了解可能吗？特别是框架本身蕴含的各种设计思想，这也充分证明了复杂性的’此起彼伏’的特点。

下面的问题就是：复杂性没有消失，为什么大家还在用呢？目前软件业都在努力作着这些事情，即尽量让开发人员只关心问题域，业务域。无论是EJB还是各种轻量级容器框架的出现都是在努力向着这个方向前进，毕竟你在走向成功的道路上无需再reinvent the wheel了，虽然了解wheel的过程仍然复杂，仍然坎坷，但是照比以前也要好上很多了。

想到哪，说到哪，有些’语无伦次’，不知道大家能不能理解其中的意思。:)