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

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/