接近岁末，一种总结的冲动总是在内心里燃烧。这一年来，自己一直都是在做电子税务相关的项目开发；前期的数据抓取与数据映射花了2个多月的时间，然后从6月底开始基于公司的电子发票框架来做泰国的解决方案。不知不觉半年已过，身在其中时觉得时间过得很慢，每一天都有不同的问题需要去解决，不同的概念需要去理解，可是现在回头看，怎么会需要用六个月的时间呢？好长呀。其中的原因可能很复杂，有需求的不确定性和套用框架后的客观工作量，但是我现在回头看，最消耗工作量的应该是自己对框架本身及其所用的一些组件的理解上，这在某种程度上也说明自己客观上来说学习能力还是偏弱，而且没有做定期的总结，导致现在回过头来，仿佛时间被虚度了一样。

其实这个框架本身是一个状态管理机，提供一个统一的用户界面让业务用户可以管理自己的电子发票的发送状态。由于在发送过程中需要先去主数据库里抓取业务数据，然后将其按照特定的格式转化成消息内容，并把这个消息交给消息中间件进行封装和发送，并解析返回的消息。其实这个消息中间件本身并不负责通信，它通过调用统一的通信接口将消息交给通信中间基于SOAP通信协议生成网络消息并传输。现在写下来好像其实这个东西并不复杂，但是因为在开发过程当中需要理解电子发票框架本身的Action Handler和Process Manager，消息中间件中Message Interface等概念，因此工作量也就相对较大了。

其实说到最本质的原因，还是自己对于消息通信等领域的知识没有任何先前的经验和认知，因此在开发过程中学习和调研花费了大量的时间，这个的确是一个巨大的劣势。虽然说你能够通过学习去弥补这些知识，但是要花的成本是比一个有经验的人要多很多的，所以自己能够在项目中去学习这些东西是很重要的。

写了这么多，好像前面的内容都跟标题没有任何的关系，别着急。前面我说的是自己失败的例子，我觉得接触到一些自己没有涉及到的领域是客观事实，在承认这个事实的基础上，如何提高自己的学习效率呢。我暂且把学习一种新东西理解成认识新事物吧，因为世界上的科学知识大体可以分为两种：认识论和方法论，而连接两者的桥梁是“实践”。前面所述就是一种不好的实践。

我之前的学习方式是通过局部的方式去击破各个概念，这样做其实很费时间，因为你如果一开始就着眼于局部很容易就与整体割裂开来，产生类似于盲人摸象的错误认知；也许你在学习局部时，也会去了解一些与该部分有交互或者间接影响的模块，但是由于没有整体的认知，导致之后在学习其他模块时又需要重复去理解之前的模块，这样会有大量不必要的重复性学习发生，而且更糟的是会有错误的认知。

所以我觉得一个好的认识过程应该是先系统性全局性地去了解某个事物，具体可以从一下几个方面来着手：

1.它在整个用户故事里扮演的角色是什么？提供了哪些功能？

2.它的出现解决了什么问题，带来了哪些好处？

3.使用它会有哪些局限？如何解决这些局限？

基于这三个维度，基本可以对于新事物有一个整体的认知，之后在将新事物拆分成多个模块逐个击破，那么就会事半功倍。将这个思路应用到我前面说到的项目:

电子发票框架的本质是发票的周期管理，具体包括凭证创建，创建消息，传输消息，解析返回消息等功能；

它的出现是为了解决很多国家都有电子发票的需求，但是对于一个电子发票来说，其所有的状态转换，消息生成等部分的代码和功能实现是通用的，这样每个国家的解决方案不需要重新写一个生命周期管理和消息生成的代码，而只需要关注于具体的状态和消息映射。

它的局限是对每个国家的解决方案带来了很大的开发成本和工作量，因为它自身引进的很多新概念有一定的学习成本，这些学习时间可能并不比重新写一套hard code的状态管理机制短。但是这个局限性对于后期的维护是十分友好的，因为统一的通用部分的代码调用，使得全球化的公司有统一的用户体验，而且通用代码部分的质量也是对整个软件质量的保证。

从表面上来看，电子发票框架提供了创建消息，通信并返回消息的功能（实际上创建消息的工作该框架会交给消息中间件来做，该框架只负责决定调用哪个消息中间件预定义好的消息格式，并把映射前的主数据传给消息中间件；消息中间件对每个消息格式的具体实例会生成一个消息实例，并基于电子发票框架提供的数据生成外部消息格式，然后将该消息传给通信通信中间件，由通信中间件来完成具体的通信工作），从细节上来看这个观点是错误的，但是从全局上来说却是准确的。