本文共 2564 字，大约阅读时间需要 8 分钟。

总的开发基调：选成熟稳定的，简单易想的，利于快速开发的开发基调，反之不怎么好。

企业级开发总的来说，是追求进度的，有点保守的，

为了追求进度，总是复用前期项目的代码，不管前期代码做的如何。

优点是：毕竟前期代码都经过工业级测试了，已经变得成熟稳定了；你自己如果新实现个代码函数，leader 一般情况下不愿意采用，怕有风险不稳定，关键是组内开发基调要保持一致，团队规范协作胜于个人独自表现。

缺点：会变得比较保守，前期项目代码一旦复制过来，如果不加以仔细修改和重构，还是有些问题的，代码会变得比较臃肿难看和难以调试。但是有些时候毕竟代码长什么样子，要看leader 个人的决策了。

平常要学会阅读和整理电子邮件，明白开发过程中的各种业务需求和开发模式。

软件开发流程：

FD:

最重要的是分析FD式样书和不断和客户沟通式样，明白了必须先了解客户需求，

即看懂FD式样书，这是前期式样，然后还有后期式样即：QA（该式样书需要你不断地去提问，和客户交流）

遇到代码中间比较陌生的功能，需要我们作出对应时，我们应该先明白它是基础功能，还是扩展功能，这是首先要区分开不同的开发阶段，上面这是要明白熟悉我们的开发模式。如果是基础功能肯定要开发的，但如果是扩展功能的话，这时不要急着编码的，要先明白客户需求。我们要开发时，肯定要先向日本客户要具体的式样，即FD式样书，这样才能正确的开发。

 SD:

下来重要的是SD阶段，这一阶段是代码结构设计，相当重要的一个阶段，关系到代码的后期可维护性。而且语言也是相通的，最主要的是软件的结构设计。

但是我们基本上没怎么好好考虑设计，就是以前的代码拼凑，见bbb_pcc文件，

可能是为了考虑进度，还有省事。这种情况自己也没有办法，各自有各自的编码负责范围；另外还有写SD文档，review SD文档，这些也是必要的，leader好像跟我说过跟她讲问题，不要直接跟她讲代码，用平实的语言讲出。

 PG：

下来重要的是编码，每个人都有自己的独特编码风格，这跟个人的性格有关，所以后期交换review代码时，也应该选选性格相异的人来review对方的代码。这一阶段有很多技术性的讲究，学生阶段的追求的技术可能就停留在这一阶段吧。

编码前期涉及到要阅读好母代码版本，这时候要明白做好代码阅读笔记和用比较形象的图画出软件的大致结构框架。这一点是很重要的，省的以后忘了还得重新看。并且最重要的是做好笔记，也是在梳理你的表达思路，并且减轻大脑思考负担。但是阅读代码时，要结合着自己的业务去有选择性的阅读，并且日式代码有比较完善的开发文档，并且日式代码是文档式代码，讲究严格按文档开发代码。可以问日方要FD，SD文档，有助于你阅读代码。

 MK1:

下来是Review阶段，即MK1阶段是比较重要的，这一阶段关系到你以后调试的是否痛苦性。我们是开review会议，但我觉得应该在这之前，先review一下对方代码的整体架构再说，这样开会会有备而来。Review对方后的代码一定要及时修改，否则到以后调试阶段就要痛苦了。所有的错误尽量在编译和review阶段解决掉，因为有时候一个小错误，review阶段本来能很快看出来的，但是如果放到以后CT测试阶段，就很难看出来了。

我们前期的review代码阶段的review记录都是比较零散的，以电子邮件的形式发出的。后来leader采用MANTIS软件进行管理时，这一阶段的质量控制开始慢慢规范起来，小组成员就不会忘记别人的指摘和提醒了。

 MK23:

下来是MK23阶段，感觉这一阶段有些在应付，但也是比较重要的吧，还是要进行良好的单元测试吧。

 CT：

下来是CT阶段，是出成果的阶段，也是最忙的阶段，可以说前面几个阶段都是意淫的阶段，只有这个阶段比较实在些。CT测试阶段前面还有个疏通测试，是看看代码大致能不能跑起来。因为CT阶段之前都没有进行过代码逻辑功能检验的。

这个阶段就是登录到测试机子上，调试代码。我们的调试都是在看代码输出的LOG信息，根据输出的log信息判定是否正确。因为是多线程调试吧，只能这样了。

输出log信息调试有啥好处，见前面技术类的总结4。

CT阶段知道了C语言指针如何容易出错，如何调试和避免出错及用C开放大型软件时，怎么进行内存管理。见技术类总结3；

在这个阶段知道了如果发现错误，有可能是最近几天其他人的修改（比如谷悦添加了一条语句）所导致。所以先找到那条语句，注释掉看看以后代码运行会咋样。

 做deadline功能改造时，发现PJSD下面当遍历每个节点的CPU时，有两种不同的方式，一种是通过下标来遍历，一种是通过CPU哈希表遍历，我觉得这不具有可读性，容易误导新人看代码。写代码时，应该讲究统一，不应该有两种方式，统一为一种方式，这样以后BUG调查时，就不会怀疑这个地方是个BUG了。

2012/01/05

1.在协助陈SAN开发 统计情报添加工作过程中，明白了有些东西调查和研究之前是要先向客户确认的。原来我是做命令行方面的统计情报添加的，但是如果要让其显示成功，PJMD那边也得做些修改，而我并没有事先想到PJMD那边的修改是否可由我们这边完成，这个是要先向客户确认的。以免工作完了，客户说我们修改了他们的PJMD方面的东西，导致PJMD工作跟以前不一样了，反而会责怪我们。

所以拿到一项开发工作，首先明白区分清责任范围，只干份内工作，需要干分外的事，需要先得到客户的同意。

2.我还想到了之前做PADEADLINE开发时，也在PJSD里面修改了一些比较重要的数据结构，但是我修改之前并没有先征求组内成员的同意。所以搞多人协作开发时，需要注意这方面的东西

3.我的LOG机能方面的开发，也碰到了一个可以学习的地方。拿到一项开发，先不要想技术方面的东西，先明确自己是要干什么的。具体哪一方面的开发。比如LOG机能开发是做JOB执行时命令行方面的LOG机能开发。这几行字最起码要搞清楚，知道开发范围。这些东西估计是非技术方面的东西，应该是工作经验积累吧。这些东西东西是靠工作来获得的，从技术的角度学不到的。还有刚才说的1,2方面的东西也是这个理。

个人心语：不要抱怨外包公司的开发环境不好，技术烂。只要你个人善于总结，还是能学到很多东西的。

转载地址：http://xurvb.baihongyu.com/