项目的大小衡量标准,以及项目演进的方法(填空架子,持续集成,边开发边测试效果)

java项目的大小衡量标准:

  • 微型:只是一个人,甚至是半日工作在几天内完成的软件;  

  •  小型:一个人半年内完成的 2000 行以内的程序;  

  • 中型: 5 个人在 1 年多的时间内完成的 5000-50000 行的程序;  

  • 大型: 5-10 人在两年内完成的 50000-100000 行的程序;  

  • 甚大型: 100-1000 人参加用 4-5 年完成的具有 100 , 0000 行的软件项目;  

  • 极大型: 2000-5000 人参加, 10 年内完成的 1000 万行以内的程序;  

   以上摘自:《软件工程概论》   郑人杰、殷人民编

这样的观点是以代码行作为计量标准的,认为代码行多的自然项目也就大了。

参考:http://zhidao.baidu.com/question/303914133298509404.html

---------------------------------------------------------------------------------

那就是重复的代码,一定要被合并成函数,或者是类的方法。这样首先是节约代码,但是更重要是,结构开始展现,从彻底的面条代码变成有条理,有结构的代码。人的认知能力是有限的,记忆能力是有限的,屏幕尺寸也是有限的。当你把几百行面条代码变成,几个函数以后,首先,你用来理解代码的单元变化了,从大逻辑上,你可以把每个函数当作黑盒子,总体结构就变成,调用几个函数了。然后当发现系统有问题,且你怀疑出在某个函数内的时候,你可以只分析这个函数的输入输出,就可以定位问题是否是在这个函数内。确定后,你修改和去理解的难度也大大降低。

以前有一个原则,叫做重复两次的代码块,必须函数化。一个函数尽量在几十行内。不见得非要100%的严格执行,但是建议认真体会,时刻反思。

写代码的过程应该是,先写厚,然后再写薄。写一段时间就反思一下,实现的结构是否合理,是不是太过冗余。当你的代码总是能保持一定的结构和复用程度以后,代码行数就会是项目规模的良好评估参数了。多一行,就说明逻辑确实复杂了一层。如果形成这样的习惯以后,随着代码量的增长,你的功力自然会加深。

其实写程序,就是一连串逻辑,你可以抽象他们,也可以具象他们,在看全局的时候抽象,可以帮你思考问题,看清big picture,可以理清头绪。当做具体实现的时候,你可以回到具体的细节上,但是,有了全局的抽象结构,你可以只关心一个局部的细节。

刚才我和我们公司主程在商量新产品的开发步骤,我跟他回忆我们之前开发这个2万多行交互排版系统。我说,如果我们一开始,一个模块一个模块的从头做起,一步一步做精,那么也许我们做几年才能做完。但是实际上我们是先把每个模块都定义好,实现了一个空架子,然后一点一点完善。这样有几个好处,第一,这东西是可以持续集成,边开发可以边测试整体效果,可以不断的改进,不需要瞎子摸象。然而,我们实际上,从始至终可以掌握进度,可以看清轻重缓急。这样,这个项目才可为,否则就完全不可控。

当你能顺畅的切换你的抽象层次,你其实就明白了什么是架构。

参考:http://ourcoders.com/thread/show/1739/

原文地址:https://www.cnblogs.com/findumars/p/4567937.html