行业与架构

架构，是一种相对不变的代码框架，在市面上已经存在好多框架，比如BBS论坛代码框架、网络游戏代码框架等等。

 

项目代码框架的作用是提高项目的开发速度，能轻易满足各个项目的需求，并且针对多种设备，能轻易实现功能。这是一个美好的愿望，这种愿望不单是由技术来支持，而且还需要行业的支持。

 

地铁终端设备这个行业的现状可以说比较混乱，各个项目有其地域的特点，每个地方的业主都有其独特的见解，从外观到硬件选购，到软件流程（前台流程，后台流程等）都需要特别定制，SC不一样，票卡业务不一样，大量的数据都不一样。。。这样导致设计软件架构的难度非常大，因为一个软件的功能都不确定，那我们的框架就要灵活到。。。像代码一样，也就是说基本没有框架之说了。。。

 

这个估计也是"多头效应"（每个地方的地铁业主都是一个头头）导致的结果。再看看铁路方面的终端软件，由于铁路方面有最大的头头--铁道部，所以对设备软件的功能定制比较统一，去到每个地方的设备都是相同的外观、相同的硬件、软件、流程等等。这样就能有个框架出来了，因为框架实际就是相对稳定的代码。

 

再想想别的行业，例如电视机行业。电视就那几个功能，功能固定，拼的就是质量和价格，每个人都可以到市场上购买，那这样就有了电视机的框架了--电路板，接收器等等。。。不同的只是一些外观之类的地方。这样的一个规范统一的行业所导致的结果就是生产越来越快，质量越来越高，成本越来越低。如果每个人对电视都有特定的要求，我相信没几个人能买得起电视了。。。

 

那我们针对这种大环境的困难，是不是要放弃呢？当然不是，现在的解决方法至少能想到两点。

 

首先是积极领导行业发展，因为行业不会一下子变得规范的，需要厂商和客户的共同努力，其实客户也不想提那么多的要求，谁买东西还想费脑筋阿，只不过他不太了解我们一些功能制定的原因，他觉得这些功能不适合他使用，所以他才提出一些比较特殊的需求。如果我们能对这些需求都有个深入的认识，告诉客户，他提的这些要求能通过我们现有的某些功能或者某些功能的组合来实现。或者他们的问题能用我们现有的流程来解决，而且告诉他们，这个流程是我们对多个客户的需求调研后所得到的一个比较好的流程，然后一步步去说服他们。这样相信业主也会信服我们，对我们越来越有信心，也能树立我们在行业里的形象。

 

第二个是从技术角度来想的办法，既然问题的根源是多头效应，那我们就针对每一头都做一套比较稳定的代码，比如广州的项目就有个广州的代码框架，北京的就有个北京的框架。。。因为虽然各个地方的功能流程会比较大不同，但每个地方的功能流程应该是大致不变的，有了广州的代码框架之后，以后凡是做广州的项目就在这个代码上改，北京的也一样。但这样的前提是，我们这个代码框架必须要非常稳定。

 

如果想要更统一，那我们就在每一套框架下面，提供一个统一的平台，这个平台提供这些框架要调用的接口，比如界面接口、硬件接口等。。。就类似于现在的Ｈ３。如下图所示：

 

 

希望真到哪天，终端设备能像电视机行业一样，规范统一。