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