在前述合作开发过程中，应用软件合作开发并不是从第二步棋进行到最后一步棋，而是在任何阶段，在进入第三阶段前通常都有一步棋或一百米的追述。在测试过程中的难题可能将明确要求修改内部结构设计，使用者可能将会提出一些须要来修改需求附件等。

1、工程项目内部结构设计

工程项目内部结构设计的主导力量思想，我真的能理解为两种，一类是全然内部结构设计，两个是单纯内部结构设计。

全然内部结构设计是指在具体内容撰写标识符以后对应用软件的各种方面都调查好，做好详细的需求分析、撰写好全数的合作开发文件格式，内部结构设计出流程全数业务流程后再早已开始写标识符。

换言之，是全数的计划好了，能看到最终的样子，再开打。这好像也是很多应用计算机科学里头明确要求的那样。早已开始的时候，我真的此种方式不错也。什么都计划好了，照著做是了。

不过这里有位明显的难题，是谁来做这个轻松的计划？估计只有及其BT的人了，但是大部分人的想全然内部结构设计，并且没严重错误，或者早已有三种预备队的纠错计划，并能简单明了的实行。以达到终极目标。这种的修为，没许多年的组织工作经历是不可能将的。我也没这种的胆量，因此我也就舍弃了此种设想。

单纯内部结构设计：单纯内部结构设计一类概念，一类能接受的单纯的内部结构设计，起码资料库早已定下来，基本业务流程早已确定的计划，来作为流程内部结构设计的早已开始，并即时依照前述情况的进展来修改具体内容的功能内部结构设计，但此种功能修改不能是修改资料库内部结构。

也是说资料库内部结构是在程式设计以后经过反复深入研究的。此种方式减少了后期内部结构设计的天数，把标识符撰写组织工作和部分内部结构设计组织工作放在了一起，前述延长了工程项目合作开发的天数。在我看来全然内部结构设计方式明确要求有很吓人的后期内部结构设计人员，那么单纯内部结构设计明确要求有很有内部结构设计洞察力的伊藤清。伊藤清更为重要是K标识符的人而且要负责流程构架的内部结构设计。

因此对流程员的明确要求就极高了。 单纯内部结构设计的成功的两个百分点是伊藤清内部结构设计的方法论内部结构单纯并能依照须要来调整其方法论内部结构，是标识符内部结构灵巧，单纯内部结构设计带来的另外两个变化是会议会比较多，伊藤清之间的沟通交流就变的很重要。现在通常的较大型应用软件公司基本上都是采用单纯内部结构设计的，假如那些很大型的应用软件公司。

归纳，单纯内部结构设计考验的是合作开发人员的能力。全然内部结构设计考验的是后期内部结构设计人员和整个工程项目组完整能力。(各种文件格式的撰写，合作开发人员一定会要写一部分的。)

2、内部结构设计变化和需求变化

合作开发人员最怕的是什么呢？内部结构设计变化，还是需求变化？我真的需求变化是最最致命的。

当你的两个工程项目资料库都定下来后，而且早已合作开发了若干个组织工作日，突然接到甲方公司提出，某个功能要改变，原先的需求分析要重新改，如果这个修改是涉及的资料库的表内部结构更改的话，那真是最致命的。

这就意味着工程项目的某些部分得重新推倒重来，如果这个部分跟已完成的多个部分有牵连的话，那就后果更可怕了。

因此当碰到此种情况发生，作为工程项目经理的你就应该考虑先查责任人，究竟是自己的需求分析做的不够好，还是客户在认同了需求分析后做出的修改，如果是后者的话，你全然能明确要求客户对他的这个修改负责任！那么，呵呵，客户先生，对不起了，本次新增加的需求将归入另外两个版本。如果是改变前面某个需求的定义，那么说不定就要推倒重来了，不过这个时候到不用太在意，毕竟错的是客户。(工程项目正式早已开始前没没说清楚其需求)。

因此，各位看客，在需求分析做好后，在开工以后一定要叫客户认可签字，并且在合同上要注明，当由客户原因引起的需求改变而造成合作开发成本的增加，客户要为此买单地。

如果在需求不变的情况之下，内部结构设计发生了变化，这个仅仅是我们内部之间的矛盾，商量一下就能解决。在单纯内部结构设计中，因为后期的内部结构设计是不完整的，那么当进入任何两个新的模块进行合作开发时，都有可能将引起内部结构设计的变化。合作开发人员的水平的高低就基本上决定了应用软件的好坏。

3、标识符撰写

当需求定下来资料库也定下来后， 其实我们就能进行实质性的编码了，按照我的看法，两个人单独程式设计最好，能即时偷懒。(上网，和MM聊聊)，但是现在的应用计算机科学项目越来越大，工期也越来越紧，事实上我们两个小组里面，通常有3-5流程员，因此我们要强调团队合作性。那么你写的标识符使得别人要能够看懂，我们必须在前述的撰写标识符过程中要有详细的编码规范，编码规范在很多书籍里面都提到过。但起码以下的一些规范是我们必须要遵守的：

一）源流程文件内部结构：每个流程文件应由标题、内容和附加说明三部分组成。（1）标题：文件最前面的注释说明，其内容主要包括：流程名，作者，版权信息，简要说明 等，必要时应有更详尽的说明（将以此部分以空行隔开单独注释）。（2）内容控件注册等函数应放在内容部分的最后，类的定义按 private 、 protected 、 pubilic 、 __pubished 的顺序，并尽量保持每一部分只有两个，各部分中按数据、函数、属性、事件的顺序。（3）附加说明：文件末尾的补充说明，如参考资料等，若内容不多也可放在标题部分的最后。

二）界面内部结构设计风格的一致性：由于采用可视化程式设计，所有的界面均与Win32方式类似，相应采用的控件等也大都为Windows操作系统下的标准控件，而且参考了其他一些市面上相关的企业内部管理的应用应用软件。基于单纯易操作的原则，贴近使用者考虑，使用者界面采用Windows风格的标准界面，操作方式亦同Windows风格，这种在实施过程，能降低对客户的培训，也能使使用者容易上手，单纯易学。

三）编辑风格：

（1）缩进：缩进以 Tab 为单位，两个 Tab 为四个空格大小。全局数据、函数 原型、标题、附加说明、函数说明、标号等均顶格书写。

（2）空格：数据和函数在其类型，修饰（如 __fastcall 等）名称之间适当空格并据情况对 齐。关键字原则上空一格，不论是否有括号，对语句行后加的注释应用适当空格与语句隔开并尽可能将对齐。

（3）对齐：原则上关系密切的行应对齐，对齐包括类型、修饰、名称、参数等各部分对齐。

另每一行的长度不应超过屏幕太多，必要时适当换行。（4）空行：流程文件内部结构各部分之间空两行，若不必要也可只空一行，各函数实现之间通常空两行。

（5）注释：对注释有以下三点明确要求：A、必须是有意义；B、必须正确的描述了流程；C、必须是最新的。注释必不可少，但也不应过多，以下是四种必要的注释：标题、附加说明；函数说明：对几乎每个函数都应有适当的说明，通常加在函数实现以后，在没函数实现部分的情况下则加在函数原型前，其内容主要是函数的功能、目的、算法等说明，参数说明、返回 值说明等，必要时还要有一些如特别的软硬件明确要求等说明；在标识符不明晰或不可移植处应有少量说明；及少量的其它注释。

四）命名规范：坚持采用匈牙利变量命名惯例，所有标识符一律用英文或英文缩写，杜绝采用拼音，标识符中每个单词首字母大写，缩写词汇通常全数大写，只在必要时加_间隔词汇。

4、BUG修补

流程出现了BUG谁来修补呢，嘿嘿嘿……最好的办法是谁撰写谁修补，谁改坏谁修补。两个人改坏的标识符一人去修。两个人一起改坏的标识符两人一起修。

5、合作开发人员的测试

合作开发人员的测试是保证标识符能正常运行，在合作开发时候发现的严重错误往往比较容易修改。(另外两个好处是没人来骂你。因为只有你自己知道)。但是一旦应用软件到了测试小组那里出了难题，那么就多了很多天数来修改BUG，如果到了客户哪里才发现的BUG，那么天数就更长了，合作开发人员本身受到的压力也是到了最大话了。客户->公司->测试小组->合作开发人员。 这个全然是倒金字塔型的，承受能力差的一环很容易出事情的。

另外合作开发人员的测试除了保证标识符能正常运行以外，还有两个很重要的方面是要保证上次能正常运行的标识符，这次还是能正常运行。如果做不到这点，那么BUG就不断的会出现，很多BUG也会反复出现。于是应用软件看上去就有修补不完的BUG了。

如有应用软件合作开发需求，欢迎私信留言【应用软件合作开发类型+联系方式】,为你解答