接近歲末禁漓，一種總結(jié)的沖動總是在內(nèi)心里燃燒。這一年來择示，自己一直都是在做電子稅務(wù)相關(guān)的項(xiàng)目開發(fā)令境；前期的數(shù)據(jù)抓取與數(shù)據(jù)映射花了2個(gè)多月的時(shí)間，然后從6月底開始基于公司的電子發(fā)票框架來做泰國的解決方案贮喧。不知不覺半年已過筒狠，身在其中時(shí)覺得時(shí)間過得很慢，每一天都有不同的問題需要去解決箱沦，不同的概念需要去理解辩恼，可是現(xiàn)在回頭看，怎么會需要用六個(gè)月的時(shí)間呢？好長呀灶伊。其中的原因可能很復(fù)雜疆前，有需求的不確定性和套用框架后的客觀工作量，但是我現(xiàn)在回頭看聘萨，最消耗工作量的應(yīng)該是自己對框架本身及其所用的一些組件的理解上竹椒，這在某種程度上也說明自己客觀上來說學(xué)習(xí)能力還是偏弱，而且沒有做定期的總結(jié)米辐，導(dǎo)致現(xiàn)在回過頭來胸完，仿佛時(shí)間被虛度了一樣。

其實(shí)這個(gè)框架本身是一個(gè)狀態(tài)管理機(jī)翘贮，提供一個(gè)統(tǒng)一的用戶界面讓業(yè)務(wù)用戶可以管理自己的電子發(fā)票的發(fā)送狀態(tài)赊窥。由于在發(fā)送過程中需要先去主數(shù)據(jù)庫里抓取業(yè)務(wù)數(shù)據(jù)，然后將其按照特定的格式轉(zhuǎn)化成消息內(nèi)容狸页，并把這個(gè)消息交給消息中間件進(jìn)行封裝和發(fā)送锨能，并解析返回的消息。其實(shí)這個(gè)消息中間件本身并不負(fù)責(zé)通信芍耘，它通過調(diào)用統(tǒng)一的通信接口將消息交給通信中間基于SOAP通信協(xié)議生成網(wǎng)絡(luò)消息并傳輸≈酚觯現(xiàn)在寫下來好像其實(shí)這個(gè)東西并不復(fù)雜，但是因?yàn)樵陂_發(fā)過程當(dāng)中需要理解電子發(fā)票框架本身的Action Handler和Process Manager斋竞，消息中間件中Message Interface等概念傲隶，因此工作量也就相對較大了。

其實(shí)說到最本質(zhì)的原因窃页，還是自己對于消息通信等領(lǐng)域的知識沒有任何先前的經(jīng)驗(yàn)和認(rèn)知跺株，因此在開發(fā)過程中學(xué)習(xí)和調(diào)研花費(fèi)了大量的時(shí)間，這個(gè)的確是一個(gè)巨大的劣勢脖卖。雖然說你能夠通過學(xué)習(xí)去彌補(bǔ)這些知識乒省，但是要花的成本是比一個(gè)有經(jīng)驗(yàn)的人要多很多的，所以自己能夠在項(xiàng)目中去學(xué)習(xí)這些東西是很重要的畦木。

寫了這么多袖扛，好像前面的內(nèi)容都跟標(biāo)題沒有任何的關(guān)系，別著急十籍。前面我說的是自己失敗的例子蛆封，我覺得接觸到一些自己沒有涉及到的領(lǐng)域是客觀事實(shí)，在承認(rèn)這個(gè)事實(shí)的基礎(chǔ)上勾栗，如何提高自己的學(xué)習(xí)效率呢惨篱。我暫且把學(xué)習(xí)一種新東西理解成認(rèn)識新事物吧，因?yàn)槭澜缟系目茖W(xué)知識大體可以分為兩種：認(rèn)識論和方法論围俘，而連接兩者的橋梁是“實(shí)踐”砸讳。前面所述就是一種不好的實(shí)踐琢融。

我之前的學(xué)習(xí)方式是通過局部的方式去擊破各個(gè)概念，這樣做其實(shí)很費(fèi)時(shí)間簿寂，因?yàn)槟闳绻婚_始就著眼于局部很容易就與整體割裂開來漾抬，產(chǎn)生類似于盲人摸象的錯(cuò)誤認(rèn)知；也許你在學(xué)習(xí)局部時(shí)常遂，也會去了解一些與該部分有交互或者間接影響的模塊纳令，但是由于沒有整體的認(rèn)知，導(dǎo)致之后在學(xué)習(xí)其他模塊時(shí)又需要重復(fù)去理解之前的模塊克胳，這樣會有大量不必要的重復(fù)性學(xué)習(xí)發(fā)生泊碑，而且更糟的是會有錯(cuò)誤的認(rèn)知。

所以我覺得一個(gè)好的認(rèn)識過程應(yīng)該是先系統(tǒng)性全局性地去了解某個(gè)事物毯欣，具體可以從一下幾個(gè)方面來著手：

1.它在整個(gè)用戶故事里扮演的角色是什么？提供了哪些功能臭脓？

2.它的出現(xiàn)解決了什么問題酗钞，帶來了哪些好處？

3.使用它會有哪些局限来累？如何解決這些局限砚作？

基于這三個(gè)維度，基本可以對于新事物有一個(gè)整體的認(rèn)知嘹锁，之后在將新事物拆分成多個(gè)模塊逐個(gè)擊破葫录，那么就會事半功倍。將這個(gè)思路應(yīng)用到我前面說到的項(xiàng)目:

電子發(fā)票框架的本質(zhì)是發(fā)票的周期管理领猾，具體包括憑證創(chuàng)建米同，創(chuàng)建消息，傳輸消息摔竿，解析返回消息等功能面粮；

它的出現(xiàn)是為了解決很多國家都有電子發(fā)票的需求，但是對于一個(gè)電子發(fā)票來說继低，其所有的狀態(tài)轉(zhuǎn)換熬苍，消息生成等部分的代碼和功能實(shí)現(xiàn)是通用的，這樣每個(gè)國家的解決方案不需要重新寫一個(gè)生命周期管理和消息生成的代碼袁翁，而只需要關(guān)注于具體的狀態(tài)和消息映射柴底。

它的局限是對每個(gè)國家的解決方案帶來了很大的開發(fā)成本和工作量，因?yàn)樗陨硪M(jìn)的很多新概念有一定的學(xué)習(xí)成本粱胜，這些學(xué)習(xí)時(shí)間可能并不比重新寫一套hard code的狀態(tài)管理機(jī)制短柄驻。但是這個(gè)局限性對于后期的維護(hù)是十分友好的，因?yàn)榻y(tǒng)一的通用部分的代碼調(diào)用焙压，使得全球化的公司有統(tǒng)一的用戶體驗(yàn)凿歼，而且通用代碼部分的質(zhì)量也是對整個(gè)軟件質(zhì)量的保證褪迟。

從表面上來看，電子發(fā)票框架提供了創(chuàng)建消息答憔，通信并返回消息的功能（實(shí)際上創(chuàng)建消息的工作該框架會交給消息中間件來做味赃，該框架只負(fù)責(zé)決定調(diào)用哪個(gè)消息中間件預(yù)定義好的消息格式，并把映射前的主數(shù)據(jù)傳給消息中間件虐拓；消息中間件對每個(gè)消息格式的具體實(shí)例會生成一個(gè)消息實(shí)例心俗，并基于電子發(fā)票框架提供的數(shù)據(jù)生成外部消息格式，然后將該消息傳給通信通信中間件蓉驹，由通信中間件來完成具體的通信工作）城榛，從細(xì)節(jié)上來看這個(gè)觀點(diǎn)是錯(cuò)誤的，但是從全局上來說卻是準(zhǔn)確的态兴。