谈谈公司开发平台及一些随感

一、问题是这样提出来的
   问题一：A银行POC和B银行POC，我们花了很多时间，也付出很多的辛苦，特别是开发人员通宵达旦的努力，也没有拿下这个单子，表面看，我们公司没有IRS产品，别人安硕有产品，能快速满足客户业务的需求，并要价可能也要少很多，从而我们和C公司的PK中败下阵来。想想很是不甘啊。因为不是我们没有努力，不是因为我们的技术不行，业务没有理解到位。
         没有成熟的产品顾然是很大的愿因，但我觉得实现产品的好的开发平台才是更大的愿因，因为我觉得，这两次开发人员为什么时候这么努力，花了这么多的时间去做事，我们很多时间不是在解决业务上的问题，而是在解决技术问题。为某一个功能点，为某一算法的实现而花了更多的时间，因为我们开发时，开发人员总是以个体来而对一个功能开发，而没有得到好的支持(我们总是一个人在战斗)，最多就问问别人或网上查资料。做为个体，技术能力总是有限的。所以我们在做项目时，开发人员要得到的支持，最重要的是靠一个好的开发平台来实现的。
   问题二：本人10多年开发中，感觉到开发总是很累，总是没完没了的需要学习，但总是做不好，如：我们开发的项目软件，总是不好维护，可读性差，由于IT人员流动总是很频繁，前一个开发的功能在移交下一个人维护或继续开发时，总是需要比较长的时间来了解及撑握，如果一个软件（应用程序）在经过两人或两人以上开发,或运行了一年后，需要按业务的变更做出修改时，由于大家开发的风格及素质不一样，代码就会写得各式各样，可读性和维护起来就更难了，有时甚至不如重做，如此就会花费更多的人力成本，软件开发成本主要就是人力成本，从而减少项目的利润。公司项目是一个一个的做,留下了一堆的文档和代码，如果下一个项目来了，如果遇到某一问题，总是在网上查资料，或请教公司某一牛人,这样是方便，但不系统，信息总是片面的，如果从原有项目工程上修改，更痛苦，一大堆可读性不强的代码，花的时间和找到重新修改的难度不如重做
   问题三：来到交行，接触到普元开发平台，我很是激动，它的设计思想，他的实现方式，就是我内心一直要找完美开发的平台，但很多同事不喜欢它，内心不接受它，呵呵，不是因为它运行慢，有这样哪样的问题，而是开发员心想：我靠，我辛苦学了这么多年的技术，到头来就让我拉拉框，拖拖线啊。怕自已学的JAVA没有用武之地了，我想这也是中国程序员对这个本土的很优秀的软件产品不感冒的原因，如果它开源一部分，让开发人员也可以自已开发普元的组件就好了，可能普元更有市场哦，当然普元是一个商业软件，由于商业上的原因，公司很少会用它，但是可以借用它的设计思想，实现方式，在现有开源的JAVA产品，不光是SSH（struts+spring+hibernate）,还好jbmp,osworkflow(工作流),drools(规则引擎)，axis2(Web Service)等优秀的产品，来整合一个好的开发平台。
二、面对问题，谈谈我的想法
1.建立开发平台，采用代码生成工具来提高平台效率，及开发的规范性：
     关键字：产品模具化，零件标准化
       开发平台，就是拿来开发工程项目的，开发过程中开发人员把业务需求实现就OK了，所以我认为好的开发平台，结构适当，功能越多越好，开发人员使用起，越简单越好。设计思想用构件式思想，借鉴了普元方式，采用工厂生产产品方式，使用模板引擎技术，实现了产品模具化，零件标准化。下面做一下简单的描述：
     代码模具化过程：首先在做开发以前,最能体现业务需求和设计思想的是设计出的数据库模型，这样，业务需求就转化为最小的粒度:表，及表中的字段,从而就可以使用模板引擎，对每一个表生成具有相应层次结构JAVA类，及类中多个标准方法，供表现层及业务逻辑层调用。这样代码就可以形成统一的风格及样式，维护起来就方便很多。所以，在这里我们的产品就是表格对应的JAVA类，零件就是JAVA类中的函数(方法)。这样，让业务尽量少去关心技术问题，而多思考业务问题。
    整个技术框架采用了struts2+hibernate+spring,根据交行经验，银行的表字段都是很多的，比如50-100,使用hibernate,就得会所有字段都查出来，所以加上了ibatis自定义查询对象，增强数据库查询性能，上面说的按业务需求生成一系列表的功能JAVA类，依赖hibernate,ibatis实现在数据库操作，同时所有的JAVA类，都采用了IOC的方面接受spring的管理，由于spring强大的容器功能，我们可以在里加入现在JAVA流行的开源产品功能，比如Web Service,工作流，规则引擎，acegi,及lucenc等功能代码，经过我们整理，就可以形成通用的SOA组件，数据库组件，日志组件，安全组件，报表组件，工作流组件，规则组件。。。。，供我们日常项目开发使用，当然每个组件优秀的算法和实现，可以在平时各项目的开发中积累和沉淀，这样，就可以形成我们优秀的，健壮的，护展性强的开发平台了
   2.不断从每个项目提取精华，丰富开发平台：
  都说员工个人要同公司一起成长和学习,但觉得IT技术开发这块公司(组织)更要同员工一起沉淀和成长，提高组织的技术学习能力,因为铁打的营盘，流水的兵，这些兵在这个“营盘”做项目，为公司赚取了项目利润，但这些“兵”的技能很少留下来，留下是一些文档和项目代码，文档是有用，但项目代码很少能发辉多少作用。其实每做一个项目都有他设计和功能代码亮点的地方,这些亮点也是公司（组织）的财富之一,我们应该用一个载体把它积累和沉淀下来，而IT人员流动是很频繁和正常的事，把公司（组织）技术的提高用人来做载体是不现实的，只有把每个项目精华和亮点沉淀到开发平台上,让所有的项目开发依托由这个开发平台，同时又丰富这个开发平台.配以说明文档,或一些DEMO例子，就能实现快速开发和减少难度，对开发人员的素质要求也降低了，重而做到了代码重复利用,降代了开发成本.
3.每日构建--管理绩效和保证开发的正确性：
  我们很多需求问题或代码问题，在开发中没有及时检查,积累时间越久，风险越大，可能后面发现，做出来的东西不是业务上需要的，和原来的设计走样了，可能又得重要做过，或修改。最好检查开发人员做事是否正确，最有效的办法是每日构建到测试环境，让测试人员或主管来检查。由于开发代码是分散在开发环境，开发人员使用版本工具管理代码是方便的，但让分散的代码集成在一起，能正常运行是要花时间,手工来做，是很难形成制度化的，除非配以人力资源，我们最好开发一个构建工具，从代码库中按更新日期或采用文件列表（开发人员每天更新的文件或目录）来提取，采用增量的方式来每日构建，一条指令OK了，这样每天就可以管理绩效和保证开发的正确性
4.固化软件成熟度规范的思想：
  我们总是在讲软件开发的成熟度CMM,很多公司已按要求做了很多文档,但效果不是很好，我们就说说它的第二级可重复，第三的已定义，第二级可重复不说了，讲进第三级已定义，软件工程的五阶段,需求,设计，开发，测试，布署，其中最重要是算前三阶段了。需求，设计我们都可以用文件模板来规定怎么写及写什么，算可重复也可定义了，如果开发也有模板(模具)不是一样的吗,每个项目都定义出标准的类和函数(方法)供开发者使用，也是可重复和已定义了,用模板(模具)把软件成熟度规范的思想体现出来及固化起来，这样开发的东西就不会走样，或增加了可读性，以及构件的重复利用.
 
三、总结：时间就是利润,完善开发平台，就是一个技术公司（组织）的学习、沉淀