最近意外发现JunitFactory这个关键字，于是便去研究了一下，研究发现后得到更有意义的发现。
首先我们大概讲一下什么是JunitFactory. JunitFactory 其实就是Junit's Factory.如果曾经是java的开发人员
应该大家都知道Junit 就是java的单元测试。他的功能是什么呢？其实主要是检查一个方法输入相关参数后得到的
结果是否是自己期望的。而且在以前的应用中，往往是开放人员根据参数预先心中算出结果然后手工放入到Junit中，
接着运行这个junit 看看是否成功或失败。而JunitFactory则能预先输入相关参数包括边界参数，然后也能预先得
到与刚才相关参数相关的结果。然后自动生成对应的Junit。这个听上去好像有点牛了。因为你要知道方法是无法去
完全去分析的。那他是怎么去做的呢？比如说有这么一个方法：
应该大家都知道Junit 就是java的单元测试。他的功能是什么呢？其实主要是检查一个方法输入相关参数后得到的
结果是否是自己期望的。而且在以前的应用中，往往是开放人员根据参数预先心中算出结果然后手工放入到Junit中，
接着运行这个junit 看看是否成功或失败。而JunitFactory则能预先输入相关参数包括边界参数，然后也能预先得
到与刚才相关参数相关的结果。然后自动生成对应的Junit。这个听上去好像有点牛了。因为你要知道方法是无法去
完全去分析的。那他是怎么去做的呢？比如说有这么一个方法：
public int plus(int i, int j)
{
return i+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);
两种情况。
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);
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 或者说不符合寻常的思
路(我们称之为低质量代码，本来想说垃圾代码，后来想想不太文明)那么还需要自动分析吗？那就没这个自动分析的价值。
怎么自动知道这些代码是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之后再去参与代码的管理。这样可以节省很多走流程所造成的时间浪
这个模式的好处是：
1.能在coding的时候就能参与代码的管理，而不是coded之后再去参与代码的管理。这样可以节省很多走流程所造成的时间浪
费，coder可以在这个方法还没有审核后 可以写其他的方法。那么有的人就会说 我后面的方法是基于前面的，我岂不是要等
待审核的结果。那我就要问，难道你的这个模块都和这个方法耦合这么紧，如果真的是这样 那么设计有问题。
2.能充分实现reused 的软件思想。虽然reused 对于任何一个公司或开发人员讲，他们都会知道，但是很多真正的情况却不
是很理想，导致不可能充分利用reused的原因有很多，比如员工的沟通不够，已有的项目积累太多 以及写的方法是不是能
reused。这应该归咎于一个制度上的问题，如果用这种模式，coder 的代码必须经过审核，也就在源头上解决了这些问题。
3.解放新的职位，很多软件公司没有给coder 很好的职业规划，其实不是很多公司不想，只是没有合适的职位给他做。那么
新的代审核人员其实是需要开发经验很丰富的人员来承担，同时他只要read code 而不需要再去write code。那么这一新的
职位可以部分解决这个问题。
