最近意外發(fā)現(xiàn)JunitFactory這個(gè)關(guān)鍵字，于是便去研究了一下，研究發(fā)現(xiàn)后得到更有意義的發(fā)現(xiàn)。
首先我們大概講一下什么是JunitFactory. JunitFactory 其實(shí)就是Junit's Factory.如果曾經(jīng)是java的開發(fā)人員
應(yīng)該大家都知道Junit 就是java的單元測(cè)試。他的功能是什么呢？其實(shí)主要是檢查一個(gè)方法輸入相關(guān)參數(shù)后得到的
結(jié)果是否是自己期望的。而且在以前的應(yīng)用中，往往是開放人員根據(jù)參數(shù)預(yù)先心中算出結(jié)果然后手工放入到Junit中，
接著運(yùn)行這個(gè)junit 看看是否成功或失敗。而JunitFactory則能預(yù)先輸入相關(guān)參數(shù)包括邊界參數(shù)，然后也能預(yù)先得
到與剛才相關(guān)參數(shù)相關(guān)的結(jié)果。然后自動(dòng)生成對(duì)應(yīng)的Junit。這個(gè)聽上去好像有點(diǎn)牛了。因?yàn)槟阋婪椒ㄊ菬o(wú)法去
完全去分析的。那他是怎么去做的呢？比如說(shuō)有這么一個(gè)方法：
public int plus(int i, int j)
{
return i+j;
}
那么預(yù)先得到的junit是
int result = new MathDemo().plus(100, 1000);
assertEquals("result", 1100, result);
和
int result = new MathDemo().plus(0, 0);
assertEquals("result", 0, result);
兩種情況。
如果你把 plus中的 i+j 改為 i+10+j,那么junit就會(huì)自動(dòng)變成
int result = new MathDemo().plus(100, 1000);
assertEquals("result", 1110, result);
和
int result = new MathDemo().plus(0, 0);
assertEquals("result", 10, result);
同樣如果改為string 那么他的junit也會(huì)相應(yīng)的改掉。當(dāng)然也許你要問(wèn)如果我的方法很復(fù)雜，那么他怎么能自動(dòng)分析產(chǎn)生
預(yù)期的結(jié)果？我的答案是肯定不能完全能產(chǎn)出所有結(jié)果。為什么？因?yàn)槿绻愕姆椒ú皇莣ellformat 或者說(shuō)不符合尋常的思
路(我們稱之為低質(zhì)量代碼，本來(lái)想說(shuō)垃圾代碼，后來(lái)想想不太文明)那么還需要自動(dòng)分析嗎？那就沒(méi)這個(gè)自動(dòng)分析的價(jià)值。
怎么自動(dòng)知道這些代碼是wellformat 還是unwellformat 的呢？其實(shí)這需要兩種工作的集合，經(jīng)驗(yàn)豐富的人工辨別和有規(guī)律
的機(jī)器辨別。值得注意的是，該JunitFactory的Eclipse pluign 就需要用戶填寫JunitFactory的website,并且保證運(yùn)行
JunitFactory的時(shí)候，網(wǎng)絡(luò)是通的，他能連接到她的服務(wù)器。他同時(shí)upload 當(dāng)前需要junit的方法，并有相應(yīng)的反饋。其實(shí)
這種兩者合一的方法也解決了審核代碼的問(wèn)題，所以junitFactory 官方的解釋就是With a full suite of
characterization tests generated by JUnit Factory you can bring your legacy code under control，
就是能合法地控制代碼。
上面是JunitFactory帶給我們具體的東西，我現(xiàn)在想討論的是軟件公司的管理模式，特別是code的管理模式。我沒(méi)有進(jìn)
過(guò)500強(qiáng)的軟件公司，所以沒(méi)有能有幸接觸他們的管理模式。但我認(rèn)為如果能把JunitFactory的模式引入軟件公司的話，這是
一件很好的事情。 這種code模式大致是這樣的
流程：coder可以先根據(jù)需求去代碼服務(wù)器詢問(wèn)某個(gè)通用的方法是否已經(jīng)在代碼服務(wù)器中存在，如果存在并已經(jīng)被用過(guò)，那么
可以自己從代碼服務(wù)器中獲取該通用方法，如果沒(méi)有那么就需要自己code該方法，coder 通過(guò)本地代碼檢查器開發(fā)完成一個(gè)
方法后可以上傳給代碼服務(wù)器，然后由代碼管理員來(lái)審核并反饋。 審核通過(guò)并測(cè)試通過(guò)就可以進(jìn)入代碼服務(wù)器，并作相應(yīng)的
功能描述版本控制什么的。
這個(gè)管理的模式的只是code開發(fā)管理模式，不包括需求分析模塊，軟件的需求分析等環(huán)節(jié)同樣需要做。
這個(gè)模式的好處是：
1.能在coding的時(shí)候就能參與代碼的管理，而不是coded之后再去參與代碼的管理。這樣可以節(jié)省很多走流程所造成的時(shí)間浪
費(fèi)，coder可以在這個(gè)方法還沒(méi)有審核后 可以寫其他的方法。那么有的人就會(huì)說(shuō) 我后面的方法是基于前面的，我豈不是要等
待審核的結(jié)果。那我就要問(wèn)，難道你的這個(gè)模塊都和這個(gè)方法耦合這么緊，如果真的是這樣 那么設(shè)計(jì)有問(wèn)題。
2.能充分實(shí)現(xiàn)reused 的軟件思想。雖然reused 對(duì)于任何一個(gè)公司或開發(fā)人員講，他們都會(huì)知道，但是很多真正的情況卻不
是很理想，導(dǎo)致不可能充分利用reused的原因有很多，比如員工的溝通不夠，已有的項(xiàng)目積累太多 以及寫的方法是不是能
reused。這應(yīng)該歸咎于一個(gè)制度上的問(wèn)題，如果用這種模式，coder 的代碼必須經(jīng)過(guò)審核，也就在源頭上解決了這些問(wèn)題。
3.解放新的職位，很多軟件公司沒(méi)有給coder 很好的職業(yè)規(guī)劃，其實(shí)不是很多公司不想，只是沒(méi)有合適的職位給他做。那么
新的代審核人員其實(shí)是需要開發(fā)經(jīng)驗(yàn)很豐富的人員來(lái)承擔(dān)，同時(shí)他只要read code 而不需要再去write code。那么這一新的
職位可以部分解決這個(gè)問(wèn)題。