接近歲末,一種總結(jié)的沖動總是在內(nèi)心里燃燒。這一年來,自己一直都是在做電子稅務(wù)相關(guān)的項目開發(fā);前期的數(shù)據(jù)抓取與數(shù)據(jù)映射花了2個多月的時間,然后從6月底開始基于公司的電子發(fā)票框架來做泰國的解決方案。不知不覺半年已過,身在其中時覺得時間過得很慢,每一天都有不同的問題需要去解決,不同的概念需要去理解,可是現(xiàn)在回頭看,怎么會需要用六個月的時間呢?好長呀。其中的原因可能很復(fù)雜,有需求的不確定性和套用框架后的客觀工作量,但是我現(xiàn)在回頭看,最消耗工作量的應(yīng)該是自己對框架本身及其所用的一些組件的理解上,這在某種程度上也說明自己客觀上來說學(xué)習(xí)能力還是偏弱,而且沒有做定期的總結(jié),導(dǎo)致現(xiàn)在回過頭來,仿佛時間被虛度了一樣。
其實這個框架本身是一個狀態(tài)管理機(jī),提供一個統(tǒng)一的用戶界面讓業(yè)務(wù)用戶可以管理自己的電子發(fā)票的發(fā)送狀態(tài)。由于在發(fā)送過程中需要先去主數(shù)據(jù)庫里抓取業(yè)務(wù)數(shù)據(jù),然后將其按照特定的格式轉(zhuǎn)化成消息內(nèi)容,并把這個消息交給消息中間件進(jìn)行封裝和發(fā)送,并解析返回的消息。其實這個消息中間件本身并不負(fù)責(zé)通信,它通過調(diào)用統(tǒng)一的通信接口將消息交給通信中間基于SOAP通信協(xié)議生成網(wǎng)絡(luò)消息并傳輸?,F(xiàn)在寫下來好像其實這個東西并不復(fù)雜,但是因為在開發(fā)過程當(dāng)中需要理解電子發(fā)票框架本身的Action Handler和Process Manager,消息中間件中Message Interface等概念,因此工作量也就相對較大了。
其實說到最本質(zhì)的原因,還是自己對于消息通信等領(lǐng)域的知識沒有任何先前的經(jīng)驗和認(rèn)知,因此在開發(fā)過程中學(xué)習(xí)和調(diào)研花費(fèi)了大量的時間,這個的確是一個巨大的劣勢。雖然說你能夠通過學(xué)習(xí)去彌補(bǔ)這些知識,但是要花的成本是比一個有經(jīng)驗的人要多很多的,所以自己能夠在項目中去學(xué)習(xí)這些東西是很重要的。
寫了這么多,好像前面的內(nèi)容都跟標(biāo)題沒有任何的關(guān)系,別著急。前面我說的是自己失敗的例子,我覺得接觸到一些自己沒有涉及到的領(lǐng)域是客觀事實,在承認(rèn)這個事實的基礎(chǔ)上,如何提高自己的學(xué)習(xí)效率呢。我暫且把學(xué)習(xí)一種新東西理解成認(rèn)識新事物吧,因為世界上的科學(xué)知識大體可以分為兩種:認(rèn)識論和方法論,而連接兩者的橋梁是“實踐”。前面所述就是一種不好的實踐。
我之前的學(xué)習(xí)方式是通過局部的方式去擊破各個概念,這樣做其實很費(fèi)時間,因為你如果一開始就著眼于局部很容易就與整體割裂開來,產(chǎn)生類似于盲人摸象的錯誤認(rèn)知;也許你在學(xué)習(xí)局部時,也會去了解一些與該部分有交互或者間接影響的模塊,但是由于沒有整體的認(rèn)知,導(dǎo)致之后在學(xué)習(xí)其他模塊時又需要重復(fù)去理解之前的模塊,這樣會有大量不必要的重復(fù)性學(xué)習(xí)發(fā)生,而且更糟的是會有錯誤的認(rèn)知。
所以我覺得一個好的認(rèn)識過程應(yīng)該是先系統(tǒng)性全局性地去了解某個事物,具體可以從一下幾個方面來著手:
1.它在整個用戶故事里扮演的角色是什么?提供了哪些功能?
2.它的出現(xiàn)解決了什么問題,帶來了哪些好處?
3.使用它會有哪些局限?如何解決這些局限?
基于這三個維度,基本可以對于新事物有一個整體的認(rèn)知,之后在將新事物拆分成多個模塊逐個擊破,那么就會事半功倍。將這個思路應(yīng)用到我前面說到的項目:
電子發(fā)票框架的本質(zhì)是發(fā)票的周期管理,具體包括憑證創(chuàng)建,創(chuàng)建消息,傳輸消息,解析返回消息等功能;
它的出現(xiàn)是為了解決很多國家都有電子發(fā)票的需求,但是對于一個電子發(fā)票來說,其所有的狀態(tài)轉(zhuǎn)換,消息生成等部分的代碼和功能實現(xiàn)是通用的,這樣每個國家的解決方案不需要重新寫一個生命周期管理和消息生成的代碼,而只需要關(guān)注于具體的狀態(tài)和消息映射。
它的局限是對每個國家的解決方案帶來了很大的開發(fā)成本和工作量,因為它自身引進(jìn)的很多新概念有一定的學(xué)習(xí)成本,這些學(xué)習(xí)時間可能并不比重新寫一套hard code的狀態(tài)管理機(jī)制短。但是這個局限性對于后期的維護(hù)是十分友好的,因為統(tǒng)一的通用部分的代碼調(diào)用,使得全球化的公司有統(tǒng)一的用戶體驗,而且通用代碼部分的質(zhì)量也是對整個軟件質(zhì)量的保證。
從表面上來看,電子發(fā)票框架提供了創(chuàng)建消息,通信并返回消息的功能(實際上創(chuàng)建消息的工作該框架會交給消息中間件來做,該框架只負(fù)責(zé)決定調(diào)用哪個消息中間件預(yù)定義好的消息格式,并把映射前的主數(shù)據(jù)傳給消息中間件;消息中間件對每個消息格式的具體實例會生成一個消息實例,并基于電子發(fā)票框架提供的數(shù)據(jù)生成外部消息格式,然后將該消息傳給通信通信中間件,由通信中間件來完成具體的通信工作),從細(xì)節(jié)上來看這個觀點(diǎn)是錯誤的,但是從全局上來說卻是準(zhǔn)確的。