大项目与小项目区别

在工作之前接触的大多是小项目，而工作之后接触的都是十几万行以上的大中型项目。有了一定经验之后，对于不同规模项目的设计过程也有了一点自己的想法。

    首先，项目的大小不是由代码规模决定的，项目的目标、受众的期望与数量、能产生的经济效益、管理层的重视程度、市场前景等才是项目规模评估的主要依据。然后进行人力、时间、预期目标的平衡。

    在这里我不想谈软件工程方面的问题，而是想说一说对不同规模软件采取怎样的设计思路。

    小型项目讲求的是快速开发，可以由最简单的，能满足用户最低需求的原型开始，然后经过一次或两次迭代（代码重构和功能添加）以完成目标系统。为了避免重构与代码复用的困难，在设计的初期，要尽量采取松散的架构，模块划分的粒度要尽量细一点。由于这种项目大多人员少、工期短，因此在原型阶段可以不做设计，让原型能够跑起来才是重点，而在迭代过程开始的时候，就需要做一些设计工作了，首先将原型的大体结构还原出来，这时可以进行几次项目组内的讨论，调整设计与讨论新功能以及有可能的新需求如何能够低成本的添加到原型中去，可能会加入几个中间层（或叫代理层），分离开功能与界面。这将产生一份初步的设计文档，包含系统架构、业务逻辑、静态结构（模块划分、模块关系、类图等）。在迭代的过程中补充详细设计文档，整理功能测试用例提交给测试人员（如果有的话），直到迭代完成，进行第一次系统测试。

    大中型项目则要在立项初期就要对项目的总体架构进行设计与评估，虽然仍然可以采用原型法，但原型的设计必须依照总体架构进行，这时的原型可能就已经是个庞然大物。系统的总体架构受很多因素的影响。例如用户数量达到一定规模，一些面向少量用户的框架和技术就必须抛弃；数据量达到一定规模，则要考虑数据存储与检索的策略；性能要求苛刻的平台上，则要将设计更加合理的数据结构和算法作为重点；若系统需要跨平台，那么就要考虑如何将操作系统和GUI抽象出来（这里不考虑使用跨平台GUI库的情况）。这样一来系统难免变得繁杂，因此，必须有一个大体的框架图以及若干个越来越细化的框架图，并在系统的设计过程中不断的修正。这个框架必须是优秀的，容易扩展的。在设计的过程中可以通过一些测试代码来验证设计，同时修正设计。在没有可借鉴的设计的情况下，设计迭代是必要的，但一定要在系统的整体框架内进行调整，不然就说明前期的总体框架有问题，项目的风险极大。在良好的、松散的设计框架下，编码的初期会异常的顺利，代码量激增，这时就要考虑系统集成时的风险。系统集成困难往往是模块间接口与通讯方式的设计不足造成的，这需要很多的经验，因此一定不要忽视例如通信协议、线程间通信、数据共享、硬件接口等等问题。大型项目的人员多工期长，大多情况是每人都进行自己模块的设计与编码，由于设计的松散，每人的模块都十分独立，这时定期的设计交流是必要的，在交流的过程中，检查自己的设计，站在整体的角度，在脑海中形成系统运行的大体流程，理解自己模块在其中扮演的角色非常重要，这能在更早的时候发现设计缺陷，并进行及时的修正。

    不管是大型项目还是小型项目，其实都需要投入相当的设计时间，对于程序员来说，对其的重视程度也应当是相当的，不然软件质量很难得到保证。