软件架构————程序规模对构建的影响

交流和规模

如果项目中只有一个人，那么位唯一的交流路径就是这个人和顾客之间的交流。随着项目成员的增加，交流路径也随之增加，但是二者之间的关系并不是加性的，而是乘积性的，即交流路径的条数大致正比于人数的平方。交流路径越多，则画在交流上的时间也就越多，因交流而出错的机会也就越大。更大的项目要求采取一些组织技术来改善交流效率，或者有意识地对其加以限制。

通常改善交流效率的常用方法是采用正式的文档。而不是让50个人以各种可能的方式相互交流，而让他们阅读和撰写文档。

项目规模的范围

评估项目规模的方法之一就是考虑项目团队的规模。

项目规模对错误的影响

项目的规模既会影响错误的数量，也会影响错误的类型。也许不会想到错误类型也会受影响，但随着项目规模的增大，通常更大一部分错误要归咎于需求和设计。

在小项目中，构建错误大约占所有被发现错误的75%，方法论对于代码质量的影响不大，对应用程序质量最大的通常是编写程序的各个开发者的技能。

在更大的项目中，构建错误总数的比例逐步下降到50%左右；而需求错误和架构错误则弥补了其中差额。推测起来大概是因为项目越大，所需的需求分析和架构设计越多，所以这些活动产生错误的机会也就会相应地增加。

项目规模对产生率的影响

对于小项目，影响因素是程序员的素质；随着项目规模和团队规模的增大，组织方式对产生效率的影响也将随之增大。

项目规模对开发活动的影响

活动比例和项目规模

对于小型项目，构建尤为最主要的活动，它占了整个开发时间的大约65%。对于中型项目，构建仍处于主导地位的活动，但是它所占的比例已经下降到了大约50%。对于非常大型的项目，架构、集成和系统测试占去了更多的时间，而构建活动变得不再那么占主导地位了。

不论项目的规模如何，有些技术总是很有价值：有训练的编码实践、让其他开发者审查设计和代码、好的工具支持，以及使用高级语言。这些技术对项目很有价值，对大项目的价值更是无法衡量。

程序、产品、系统和系统产品

代码行数和团队规模并不是影响项目大小的仅有因素。另一个更敏感的影响因素是最终软件的质量和复杂度。

没能认识到程序、产品、系统以及系统产品在精致度和复杂度上的区别，是导致估算出偏差的一个常见原因。程序员用他们开发“程序”的经验来估计开发一套系统产品的进度，可能会低估10倍。

方法论和规模

在软件开发领域中，项目越正规，不得不写的文件数量也就会越多，用于确认已将完成的工作。做这些文书工作可不是因为写起来很有趣。撰写他们的原因在于：你要协调的人员越多，那么为了与他们相互协调，所需要写的文档也就越正规。

撰写文档的目的并不在于文档本身。例如：写配置管理计划的目的不是要锻炼写作技能。先写计划的关键在于，它能迫使仔细考虑配置管理，并且把计划向每一个人解释。