我是程序员------笨鸟飞呀飞（14）

技术成长（1）

处在这样一个高手如林的公司，技能想不成长都难，这段时间也因此成为我目前为止技术成长最快的一阶段，即2006年和2007年。

程序员往往都有一个认知的误区，认为大多时间都是在编写代码的，这也是我最初的思想，但其实不是，如果让我现在对程序员给个定义的话，我认为一个真正的程序员，需要具备很好的知识面，很好的逻辑思维能力和文字表述能力，有架构思想和文档构造能力的人，这样的程序员才算是具备实力的程序员。

很好的知识面不是一蹴而就的，需要你持续不断的努力学习新的技能，可以说，业务能力是一个程序员最需要首先学习的，因此，知识面如果很宽，熟悉业务的能力就相对较快，那么你融入工作的速度也会非常快，而很好的逻辑思维能力主要表现在程序的算法和调试思路上，真正研究算法的人，不见得能成为一个优秀的程序员，但一个优秀的程序员，必须要掌握一些常用的算法，有时候，一些算法思路是经过艰难的思索才能获取到的，而只有具备了很好的逻辑思维能力，你才能够有目标的去想，有线索的去调试，调试则是整个编程过程的重中之重。

在那段时间里，我在这些强人和牛人的带领下，对业务熟悉能力越来越强，正是在那段时间里，我真正了解了TCP/IP协议原来有那么多内容，理解了抓包工具的使用方法，知道了怎么熟练分析十六进制码流，学得了众多的调试技巧。

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

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

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

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

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

林锐博士曾写了一本书《高质量C++/C编程指南》，我在这里简单的说一下，一个真正的程序员，一定要有良好的代码编程风格，否则在后续编码遇到难题的时候，你想找个人问，将会变得异常困难，我这点遵守的非常好，以至于当我的代码完成时，被杨姐大为表扬了一番并将我写的代码当做样本让大家学习。我感到无比的激动，而良好的代码编程风格，对一个程序员来和公司来说，都是莫大的财富。

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

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

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

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

你不要以为他们给你是为了偷懒，恰恰相反，当你开始指点新人的时候，你就会发现，许多的问题，你自己解决起来，会比指导一个新人去解决，要快速和简单的多，因此，遇到肯给你机会的人，肯知道你的人，你如果不抓住，那是多么可悲的事情。