项目流程与管理

 
原来大型项目的开发不是先从编码开始的，而是要首先摸清用户需求，进而写出需求规格，在需求规格的指引下完成概要设计和详细设计，这些在整个项目成型中，远比编码时间要长很多，也是在这个时候，我了解了所谓的CMM即能力成熟度模型原来是有不同的级别的，而我们当时遵从的，则是华为的5级ＣＭＭ，这算是最高级别了。

需求分析、概要设计以及详细设计，通常会占用我们很多人几个月的时间，我记得我第一次参与大型项目的时候，费时近２０天，书写了长达１９７页的概要设计和详细设计。依据要求，概要设计要明确表示项目的所有功能，以及性能标准，并给出参考依据；详细设计则除了细化实现方案外，更要具体到每个模块的每个接口的详细实现，可以说，写完了概要设计，其实整个项目的架构构成已经完全明确了，而详细设计，我们甚至具体到了每个函数的具体实现，当时的要求是实现每个函数至少90%的功能，也就是说，详细设计要和实际的代码实现完全吻合，这种吻合已经具体到了每个条件处理语句，也是从这里我知道，一个普通的程序员，如果你不具备自己的思维，还真是一个代码民工，你甚至没有表现自己思想的机会，这样的程序员，其实只能算是入门级的程序员，而我有幸在坚持完试用期后，顺利的跨越了这段级别，没有强人和牛人的帮忙，我可能走的弯路会多不少，成长也会慢不少。

确定一个项目的架构是否有问题，则是通过众多专家对概要设计和详细设计的评审来实现的，也是在这个时候，我才明白，其实评审一个项目，是对一个程序员编程思想成长最快速的方式，你要想真正找出概要设计和详细设计的问题，必须具备熟练的基本技能，更要有很好的编程思想。没有这些，怎么能够找出这些设计的问题呢？而如果设计找不出问题，你到代码实现的时候才发现问题，那将会浪费多少时间和精力来重新构筑项目框架呢？也是在这个时候，我领教了这些编程高手的严密的思维能力，这些所谓的评审专家洞察问题的能力实在是太强了，正是从他们对我的设计的评审，我才更清晰了我的每个设计细节，有些问题，我还真是在设计的时候没有考虑到，甚至模糊不清，这些都难以逃过这些评审专家的法眼，我的编程思想能力的提高，在第一次设计说明书完成之后，在经历了评审之后，得到了极大的提高，我记得，我写的这197页的设计说明书中，评审历时了四天，而评出的问题则超过300个，严重问题和致命问题也占了50个以上，想想，如果这些严重问题和致命问题我没有发现的话，那么后续的写代码时间会浪费多长呢？当我针对这些缺陷进行整改完成时，已经又一个星期过去了，我不得不佩服这些评审专家，当我改完这些缺陷并在此经过复审和修改之后，我几乎闭着眼睛就能想象到我的程序的工作模式，我能想想到每一个细节的具体实现方式，它们在我的脑海中已经成型，没有思考不透的地方了，以至于开始写代码的时候，近万行的代码量，我也只是区区１０天，就轻松的完成了。这或许是大型项目特有的，我很庆幸自己有这样的机会，以至于在以后的日子里，我研究这些所谓的处理流程时，发现其实除了能够解决编程难题的同时，最大的好处是大大降低了项目的不可控性，即项目的风险已经无形中降到了最低。

对于很多公司来说，一个项目的最大风险就是交付问题，而造成这个问题的主要原因则是因为对时间的预估和实际有严重的偏差，这些偏差主要来自对疑难问题的预估不够，再加上编程人员的流动，需求的不停变更。但如果真有这么一个成熟的处理流程的话，这些其实还是能够避免的，通过对需求分析的讨论，甚至能预估到用户会有什么样的额外需求，这时候，你的需求规格已经能将主要的需求都完全涵盖了，有了需求规格的指引，你则对框架有了一个确认，大家再通过讨论和进行概要设计再到评审，基本上能够完全控制以后的架构变更问题了，而详细设计细化了每个功能细节。这样，即便用户临时提出需求，也很难影响到架构，影响不到架构的问题，可以说都是小问题，我们流出预估的时间，项目的可控性，从技术上来说，已经完全解决了，而剩下的资源配比问题，则是项目经理和资源经理操心的事了，做这样的程序员，真是倍感成功。

编写代码，对于我来说其实到了这里已经没有任何难题了，因为在设计完毕之后，我的C++技能已经经历了一次洗礼，不懂不会的、设计不合理的早已在设计的时候，在众多评审专家的指正下，外加我自己的努力下，得到了圆满解决。而对于各种协议设计，我也基本掌握，只等在写代码的时候，复习一遍，用真实的编程语言转换一下我在详细设计的时使用的伪代码描述的功能，怎么能不快呢？

林锐博士曾写了一本书《高质量C++/C编程指南》，我在这里简单的说一下，一个真正的程序员，一定要有良好的代码编程风格，否则在后续编码遇到难题的时候，你想找个人问，将会变得异常困难，我这点遵守的非常好，以而良好的代码编程风格，对一个程序员来和公司来说，都是莫大的财富。

代码评审则是在代码完成之后紧接着要做的，评审代码主要是根据详细设计来操作的，评审代码的主要原因就是将潜在的问题在评审的时候解决掉，如果代码和详细设计不一致了，到底是详细设计还是代码除了问题，哪种解决方案更好，这些都是在代码评审之后，能够完满解决的。显而易见，通过代码评审，我的编程技能也得到了前所未有的提升。

而单元测试，则是解决编程时潜在问题的最好方法，单元测试要求测试到每个分支，因此单元测试，我几乎又花了一个月的时间来编写，说起单元测试，我原以为非常简单，也是到了这时候，我才知道，许多这样那样的功能问题，如果经历了认真全面的单元测试之后，已经几乎解决殆尽了，而单元测试大多是根据详细设计来实现的，详细设计和代码可以说几乎是完全一样的，这在代码评审的时候，已经将差异完全找出来了，因此，单元测试的评审，主要是为了查看你的测试能否涵盖整个分支，能否测试所有的逻辑处理功能，当然也包括异常处理是否合理。

当单元测试完成之后，后面则是进行集成测试，不要以为单元测试之后，就一切ＯＫ，做过大项目的人应该都明白，几乎所有的大项目，为了可扩展性、可维护性以及稳定性，都是模块化的，每个模块几乎都是不同的人实现的，而一个大的项目，可能有上百个人来配合实现。我们这个项目，参与模块开发的，就不下４０人，每个人只是对自己的部分进行了单元测试，其目的是为了保证在对接的时候，自己的模块内部能够正确处理功能以及各种异常，而不同的人，不同的技术水平，不同的设计思想，将这些东西揉和在一起，怎么也不容易。

集成测试的主要目的就是对各个模块的接口进行对接测真正试，只有对接的时候，你才会理解到，原来对同样的接口，即便你进行过详细的文字描述，在别人理解起来，还是有偏差的，集成测试就是要完成这些接口的正确稳定对接。集成测试也对每个参与人综合技能提出考验，是每个人提升技能的一个主要机会。你想，那么多的模块，不同的人完成，一旦出现问题，你必须找到问题是谁的，这除了考验你的调试能力、问题定位能力和代码阅读能力之外，更考虑你的耐性和思想，你总不能说这有问题了，那这个问题是谁的呢？你怎么证明问题是他的呢？有时候，一个模棱两可的问题，谁修改起来最好呢？这个都需要你的冷静思考，你的思维能力的严密，你的说服力的大小，因此，如果你有幸参与了集成测试并是主要调试成员之一，你真的应该庆幸，我的技能的飞速增长，正是有幸参与到每个阶段的原因。

 

系统测试和集成测试是不一样的，很多人都认为集成而是就是系统测试，但，远远不是，集成测试，主要测试的是模块和模块之间的接口的测试上，而系统测试已经是对所有模块集成后的整体测试了，如果将测试分为白盒测试和黑盒测试的话，系统测试开始，进入到了黑盒测试，为了进行系统测试，我们当时设计了许多测试工具，这些测试工具几乎涵盖了需要测试的各种正常和异常处理。系统测试综合考验了一个程序员的动脑、耐性、动手能力和定位问题的手段。

一个程序员技术水平高低，调试手段是一个主要的衡量标准，在系统测试阶段，你会发现，原来单步跟踪是很初级的调试技巧，真正的调试定位问题一般是通过日志信息来定位问题的，是想一下，你的项目一旦发布，客户拿到的是发布版，你不可能再依靠你的编程工具来对问题进行定位了，我们更多的则是靠日志信息来定位问题，日志的信息的种类多种多样，包括操作日志和运行日志，这很像飞机的黑匣子，当飞机出现了问题之后，首先是要通过黑匣子的分析来确认飞机的出事的原因，黑匣子记录的就是飞行员操作飞机的各种数据以及飞机运行状态的各种数据。同样，一个对稳定性和性能要求很高的项目，日志信息是定位为题的最强有力的手段，你可以这样想一下，一个程序，在你经过多轮次的测试之后，没发现问题，当交付给用户使用了几个月之后，突然发现出问题了，而这些问题并不是每次都能出现的，对于一个稳定性要求非常高的软件，你靠什么来排除出现的问题呢？拿着编译器去客户那里定位么？即便客户真正同意了，对于偶然出现的问题，你难道守护它，直到它出问题的时候跟踪么？如果恰好你上厕所的时候，或者你睡觉的时候出了呢？

正是通过系统测试，我发现了，定位问题，不是仅仅的调试一种手段，日志、各种模拟工具等，都是你定位问题的方法，不过最重要的是，你必须依据各种操作情况，想法重现问题，而众多的手段，都是为了让你的问题重现方便，只有问题如你推测的重现了，你定位并解决问题就很快了。而当问题重现的时候，我们则可以利用现有的各种编译器，去定位问题了，在这个阶段里，我第一次并体会到并学习了多线程、多进程情况下程序问题的定位技巧，三言两语还真的是难以说清。

系统测试之后，项目就会交给测试部，这时候是我们相对轻松的时候。而我又在这个时候被领导安排和测试部的测试人员进行对接，就是让我负责对所有发现的问题的跟踪、定位和协调修改。