汽车实时监控系统项目濒临失败和延期的经验分析

背景，需求不很明确，工作量大，开发人员有限。

项目为在线汽车实时监控系统，采用在线google Map

1. 架构和选型

  1) 基础架构：

业务上分为几个子系统，各个子系统是相互独立的Java webapp可以单独部署，也可以一起部署到tomcat，并通过一个ROOT webapp， portal来访问，并通过一个简单的SSO来登录；每一个子系统可以单独部署在自己的数据库schema；各个子系统之间通过Camel数据集成，

实时数据通过Router（socket前置机，通过互联网/GPRS/3G/4G等网络将汽车GPS及其汽车总线信息数据传送过来）发送到Camal再通过一个Java app将接受到的数据写入Hbase。

  2） 技术选型：

      a) web: HTML5, Jquery/kendo, Spring MVC/Restful

      b) 后端：Spring, Spring-data, JPA

      c) 数据储存：SQL Server/Oracle（基础数据），Hadoop/Hbase（实时数据）

      d) 系统集成：Camel/Spring,Active MQ

3）架构3宗罪：

        本身的架构没什么问题，但是问题在于放错了坑，一个萝卜一个坑，但胡萝卜和红萝卜是有区别的，把红萝卜往胡萝卜坑里放就不合适了，总体总结：

   a )  Camel 滥用：camel本来很好用，其Camel架构也本身也没有问题，在系统集成也很简单，问题在于把Camel用烂了，其主要问题是滥用导致了代码调试和维护的难度增加，从而使工作量成倍增加。

        很多camel接口为了做到所谓的通用，而很刻意的通用，接口的定义和开发很自私，只考虑了接口本身，并未考虑接口调用方的便捷和可靠。接口定义简单，接口定义的返回结果太过结构化的。虽说结构化的数据很明了，但就是这样太结构化的数据导致了跟多的工作量。同样的事情使用JPQL或者SQL 2个小时即可完成，而使用结构化的数据等于在重复数据库select语句所要完成的工作，跟为可悲的是这些功能用结构化的数据来过滤很容易出错，且调试困难，从而导致开发时间数10倍增加，甚至几十倍，有些查询功能甚至前后超过2周的时间（2*5*8=80个小时，40倍）。

结构化数据和扁平化的数据：   这里的结构化数据指类似JSON/XML式的数据，扁平化数据指类似关系数据库的行数据。

结构化的数据的好处是对开发人员友好，不需要文档说明或者只需要程序doc，做一般的过滤和输出很不错，但做复杂的过滤和查询就比较费时，如果是多层数组或list数据就要嵌套N层循环，比较考验开发人员的细心和耐心了，所以这种情况不可取，而该项目中却用了这样的方式。

扁平化的数据简单明了，很多时候需要文档说明各个字段或offset所代表的意义，但做复杂的过滤和查询比较容易，一般一次loop就可以。

i)  为用二用，而不是为需二用。

ii) ESB接口的定义和实现不太科学，重复和交叉（笛卡尔积）查询太多，能自定义的查询条件很有限。

iii) 查询结果多为结构化数据，不易处理，并且没充分发挥数据库的威力，这种结构化数据造成了80%的无用数据，也浪费了80%的性能，通过一项日志观察，数据库查询占了整个应用性能的80%，导致慢的原因也是这种太多无用查询，而这些直接是Hibernate导致的。其中一项功能单体查询竟然需要1~2s，同样的需求使用SQL语句只需要几十MS。

b) 第二个败笔就是拿Hbase来做实时数据的监控，Hbase需要运维的支持，并且在大请求下性能很差，内存暴涨而溢出，从而Hbase集群奔溃无法使用，还有Hbase没有关系数据库那么友好的SQL查询语言和性能，hive实际上不好用且性能差。

 c) kendo 框架的错误使用，kendo提供了很丰富友好漂亮的UI组件，并且基于jQuery，本来是好的，但却非要拿把BS的程序搞成C/S就无语了，这就造成了在使用kendo中遇到了该遇到的不该遇到的问题，而且界面死慢不够流畅，多窗口多文档的方式并没有在该项目体现优势，事实上每次只能操作一个窗口，其他窗口被屏蔽，这个和传统的web页面方式没有什么区别，但它却需要更多地JS工程师时间和更多地经验，从而开发时间增加：

      i） 需要专门的JS工程师，而且要熟悉HTML5，CSS3。

      ii） 从事过传统B/S项目的 Java工程师（ 前端 ）无法胜任，或者需要花较多的时间学习才可以做前端开发。

      iii）出现的BUG几率比较高，复杂页面需要花费更多时间。

4）架构师几宗罪：

 a）架构师经验不足，架构没有很好的评估，看了quick start 觉得好就敢拿来用。

 b ) 架构师太追求新事物，不考虑健壮性。

 c）架构师追求自己学习新鲜流行技术，不考虑项目实际情况。

 d ) 架构师不考虑项目组对技术的熟悉度，以及新技术的学习曲线，导致没有系统的学习就来用，从而使使用中bug超多，修复bug花费了大量时间。

 e ) 架构师不够nice，把握自认为是核心的技术，不予共享。

 f ) 架构师太自负，写代码不自己测试，导致其他人调试程序花费更多时间，事实上架构师所写代码问题多多。

 h) 架构师太面向对象化，对于SQL/JPQL/HQL等的拼接和使用很是不看好，也看不起这种做法，这就导致了解决一个需要几分钟能修改的查询问题，需要花很长时间来解决，另一个问题就是架构师在选型JPA时，并未事先考虑这种查询的通用组件来支持这种缺陷。

g) 架构师书本主义，看本o'reilly，然后就本本主义大干一番，匹配式应用，不考虑需求和业务，中国式教条主义。

5) 程序员几宗罪：

   a. 做外包项目培养的懒惰性: 以完成工作而做事，而不是以自己想法而做事。

   b. 对架构师的抵触心理：软件设计经验差距、软件思想的差距较大。

   c. 对项目管理者的抵触心理：工作安排不合理，评估差异太大。

   d. 程序员责任心不强。

   e. 程序员太自负。

   f.  程序员编程技术兴趣不同。

6）项目管理几宗罪：

a. 工作安排不合理

b. 工作量评估差异太大

3. 需求、需求承诺几宗罪：

1） 需求不明确

2）需求管理不同步，需求参考不一致

3） 需求没有确认时间，项目结尾时还在提需求。

4）无意义的需求。