H.E.'s Blog

   经常采用Java语言和一些开源技术为客户构建一些中、小型的web项目，目前来说对与我们团队承接的每一笔软件项目都是赚钱的，但关键的是如何缩短开发周期，确保产品质量，并提前交付获得更高的价值，所以我们在开发的过程中尽可能的使用一些简洁的方法。
例如：web层使用spring3 web框架，操作数据库那层使用 Jenkov 的 mrpersister 和 Apache 的 dbutils，将这2个框架进行组合使用，自己再对这2个框架薄薄的封装一个抽象类，满足了我们的期望，可再次缩短交付的时间。

   这样就不用管web层传过来的是多少个参数反正都是一个对象，直接传入DAL层，而每个DAL层中的方法写2-3行代码即可，除了根据不同的业务逻辑写查询的SQL语句，在开发上基本没什么“重活”了。反之，如果使用 iBatis 或者 Hibernate 、Struts 框架 xml和java都将需要维护，无形中加大了我们开发的成本，延长交付时间。
 
在小团队开发中这种框架我认为是不错的选择，但随着开发队伍的壮大，加上客户对项目二期新需求的提出，其他客户的新项目到来。一下 人多了，口杂，事情多看，任务多，计划多看，变数多，忽然之间有点乱了。此时貌似不如团队成员人少的时候来的进度快，大家商讨几次之后还算一切都平静了下来。

  其中我发现一种现象，例如：没有iBatis 中 XML的限定后，SQL语句可以写在com\aswish\common\sql目录下 再给DAL里面的方法引用，也可以直接把SQL语句写在DAL的方法里面，另外，对于打SQL印日志可以通过Log4J打印SQL，还有成员通过System.out.println打印，还有人偷懒不打印SQL日志，有的成员在每个Action方法里面都打印日志 ，有的人觉得麻烦就不打印，等等这些小问题，小细节，但排错的时候就不一样了通过打印日志能很快的找出原因。还有，对于DAL层程序方法调用上有的新成员开始的时候不习惯我们的这种开发框架，按照自己的习惯来导致最后帮他排错的时候也费了一些力气。使用这样山寨框架灵活性很强，但是导致了开发上一致性比较差，最后修复Bug的时候降低了工作效率。记得在《淘宝网架构师岳旭强的年度展望》http://www.infoq.com/cn/articles/yuexuqiang-share-outlook   一文中提到 “有一个故事，在数据层的前期版本，为了做到透明的路由，曾经采用无SQL的方式，所有的数据库访问都是写代码来做。上线后发现一个非常痛苦的问题，无法和SQL对应，排错非常难。曾经一次DBA发现数据库上一个查询耗费太多资源，把优化后的SQL给开发人员改进，开发人员好几天没找到具体是哪个查询。”  似乎他们也遇到了和我们相似的问题。

   项目现在已经交付给客户了，也算是非常非常，再次 再次的体会到 为什么很多大型项目需要 Spring Struts Hibernat 这样的组合，至于Spring的配置文件具体怎么使用我现在都统统还给了Rod Johnson 大叔，但深刻的明白了大规模开发中一致性非常的重要，也许这样的框架并不能给行效率上带来多大的提高，但是在规范上可以进行统一。总结这次的教训，将来还需要整理出一套具有一定规范性的ORM山寨版框架，会想些办法在山寨框架中去制约在编码开发上一致性。没有最好的框架，但适用的才是最好的。所以不是不敢这样继续折腾下去了，而是在想下面该怎么接着折腾，呵呵。

BTW：
大家都是在业余时间折腾这些项目，工作时间基本上晚上所以面对面沟通比较困难，在网上交流又不大方便，也是我们面临的问题。
上述这的过程是值得去反思的，需要不断总结一切导致挫折的因素，那是今后的财富之一。

–end–