目前对于一个开发人员来说，没有几年的项目开发经验，对于技术的理解可能不是很深。工作2年了，接触的都是针对某一行业的系统开发，可能使用的技术基本固定，比较好项目可能就是后期对代码框架的优化，对其进行二次封装，对系统进行拆分多个模块，抽象构建代码框架，最后使得项目适合多人快速开发，最后就是对业务进行运营监控。
但是到后期可以参与这些的员工，多数都是老员工，当然了要求也比较高，技术业务都得了解，但是也可能导致最后项目失败，最后重新开发。
作为一个开发经验不足的员工，了解一些业务场景，看看人家的解决方案，自己可以想到解决更好的方案吧,通过这个过程再去学习技术，个人感觉不错，因为不管上面场景，基本的解决的方法都有相通之处，不同仅仅是业务处理的细节过程不一致而已
比如BPM-优点就是流程监控，ESB-典型的BUS数据交换，ETL-典型的数据抽取,Batch-批处理（周期性规则机制），Drools-判断机制 Queue-队列，Cache-缓存机制，这些可以进行组合，就可以出现多种的解决方案，其里面的实现机制都很相似，但是其针对场景不一致而已。
工作中，一下不可能接触到这些东西，但是细想工作中的解决方案，思想都在这些场景里面有，仅仅是目前不适合实际项目，需要一个过程。但是作为一名开发人员，接触不到场景，大家也得学习，以后的项目优化或许就可以使用的到，仅仅是时间问题而已。
最近做项目，也渐渐发现，业务做好之后，代码优化做起来不是很容易。比如现在我们前段采取ExtJS的展现，但是项目的页面很多，多人开发，一个人和一个的代码格式不一致，或者大量的粘贴复制，机械式的开发，因为也来公司没多久，所以处中后期阶段，JS以及进行的二次封装，但是还是粘贴复制，重复还是很多，再进行重构，要求挺高。不过还是有解决办法，可能不是很好，但比现在的好。后端我基于Struts，Spring-JDBC，里面的大量的sql拼串，这个真想不出什么好办法(涉及这样的复杂SQL基本都是报表)，但是做成OLAP吧有没有必要，数据量不会很大，表样基本固定，导出EXCEL，打印等功能。目前唯一优化的就是对报表数据进行定时发布，形成中间历史表进行存储，定期发布报表数据，存成一个表里面。
对于业务而言，复杂的业务交换都可以拆分的很细，针对单表的CRUD，但是对于事务也是基于简单的配置，不存在分布式问题，虽然是基于BS架构，针对共享数据库进行开发，可能有时涉及FTP。