知难而进
——反思我带的第一个版本
这个版本是公司推向海外市场，全面推进虚拟化（Windows Hyper-V平台、VMWare平台）以及AWS云平台的第一个试水版本，总耗时近3个月。
下面逐个阶段回顾，并就出现的问题进行反思。
1、需求阶段
仅仅花费2周左右的时间，简单从互联网获取资料、竞争对手网站/试用包分析、基础云平台部署预研，就开始了版本。
对于研发人员的我们拿到的是一份很宽泛的需求文档，涉及范围很广。包含：
（1）产品易用性改进：向导部署、图形化界面&命令行接口的后台、多序列号合一、非IE内核浏览器（Chrome、Safari浏览器）支持。
（2）产品功能改进：部署模式变化、非产品相关功能删减。
（3）产品性能改进：保证速度达标且保证有好的削减效果。
反思：
需求点（3）是真正到了集成测试阶段中期才识别出来的。且属于历史遗留问题，和早期的架构和设计有关，只能做边边角角的缝补，即便花了很长时间，但仍然难得到既定目标。
这种问题，应该放到版本的早期识别，且定好改动目标和截至时间，不能达标走规避方案。
2、设计阶段
两个模块向导部署CGI后台以及序列号模块是进行了方案选型和微型/概要设计的。其中序列号方案时候对于场景考虑是不充分的。
在虚拟化平台上，由于安装包可以任意Copy，同时序列号也是可以任意Copy的。是不是用户买一个序列号就可以任意使用了呢？
这里就需要提防：
（1）两个相同序列号对接，校验判定，结果：不允许对接。
（2）多个相同序列号的分支接入一个总部，结果：不允许对接。
（3）一个分支接入多个相同序列号的总部，结果：不允许对接。（当时想到这种场景，但因为是小概率场景，就没有关注）
反思：
小概率场景对于开发来说也必须考虑，一旦出问题就是灾难性后果。不要把问题留给用户，有可能预见到的问题要一网打尽、消灭在萌芽状态。
事实也证明，后期再去处理该问题，一是本身实现机制不便于扩展，很难改动，且改动可能引发。二是项目进度很紧张，不可能留太多时间处理。
3、编码阶段
（1）典型越界Bug如下所示：（仅是示例，实际比这难排查N倍，要是面试题大家谁也不会错，平时运行都是32767之内的值也不会错，但一旦出错就是越界溢出，后果很严重）
<span style="font-size:14px;"><span style="font-size:12px;">#include <stdio.h>
#include <stdlib.h>
int main()
{
short int ival_1 = 32767;
short int ival_2 = -32768;
short int ival_1t = 0;
short int ival_2t = 0;
int i = 0;
for ( ; i < 10; i++)
{
ival_1t = ival_1 + i;
ival_2t = ival_2 - i;
printf("ival_1t = %d, ival_2t = %d\n", ival_1t, ival_2t); //都会越界
}
unsigned int uival_1 = 32767;
unsigned int uival_t = 0;
for (i = 0; i < 10; i++)
{
uival_t = uival_1 + i;
printf("uival_t = %d\n", uival_t);
}
return 0;
}</span></span>
（2）典型使用方法错误Bug如下
在定时脚步里面不要使用Popen类似的接口。原因如下：popen() 函数通过创建一个管道，调用 fork产生一个子进程，执行一个 shell 以运行命令来开启一个进程。
而对于一直在跑的系统，1天、2天可能不出问题，对于性能环境要求24×365运行的话。会很容易出问题，很耗费性能，导致连接中断。且非常难排查。
反思：
这些最终排查出来都是细节不注意的小问题，但是如何在高压的项目环境下最快排查问题所在、并修正问题，着实需要花精力去学习、去积累。
4、集成测试阶段
分模块之后，利大于弊。利是：独立的模块可以分开转集成，提交测试部测试。但注意此时关键路径就成为后面才开始模块。
团队里面就可能出现：后台已经实现，在等待与前台对接。几个独立模块都完成了，就等待合入。
反思：
如果模块之间有等待关系，比如后台CGI等待前台html、JS页面对接。此时后台可以自己构造数据进行手动或者自动化测试。
有等待关系的模块也可以先开始BVT案例执行。总之，不要等待，这样整个版本的进度才有保障。
5、系统测试阶段
在所有模块转集成之后就是系统测试阶段。这个时候最容易出问题的地方就是模块间的对接。如：向导部署的一个页面就需要客户输入序列号，并在后台调用序列号相关解码程序进行校验。一是校验序列号格式的正确性，二是校验序列号的合法性（如解析出网关ID进行字节匹配）。
反思：
到了预发布的冲刺阶段，任何一点代码改动都要慎之又慎。
一是重新打包要耗费半小时时间。且要导出VMWare支持OVA数据包，导出Hyper-V的数据包，以及导出不同平台的包要4个小时左右的时间。
二是一点改动都要进行验证，而验证需要耗费的时间远大于我们改动的时间。
时间非常重要，稍有不慎，是拖延的整个团队的工时。
这点，我做的也非常不好。自动打包脚本前期由于打包速度的考虑，没有重新编译内核（2015-1-5月份之后，主要内核改动代码的确很少），但是直到3-20号才发现，之前的两个Bug都涉及修改驱动、需要重编内核。（非常抱歉，个人失误影响团队）
6、预发布阶段
包已基本稳定，等待验收中。
整体反思——我究竟学到了什么？
从历史的角度，我们的经历的大部分我们都会淡忘。但那些深思过、你通过、你被鄙视过的经历、你为某个问题争得面红耳赤的经历，我都不会忘记。
1、 我有了全局的视野。
早期的几个版本都是站在模块的角度看待问题，只知道自己模块的实现的功能。多点就是知道与自己对接的模块的功能。视野停留在接口实现、接口对接、模块功能实现、模块案例测试与联调，模块最终无Bug。
现在对产品的过去和未来，尤其对产品的功能和市场需求角度都有了新的认识。会对后面的模块开发从思维角度有“洞开”的效果。
2、我更会从客户的角度考虑问题。
作为研发编码实现人员，面对突入起来的需求变化，真的不忍心改掉自己“滚烫”的代码。但如果这个变化更有利于客户理解，更利于客户操作，我们就得“拥抱变化”。
骂两句后，还得伏下身子改代码。
3、我学会了在高压环境下更加高效的工作。
没有压力的IT不是IT码农。在高压的环境下不盲目保持清醒头脑。之前一年前也说过的，要在每天早上列举今天需要完成的任务。这样每天就是解决一个个问题的过程。
碰到比较难解决的Bug的，也要列举上每天解决的步骤和思路。便于理清思路和把握方向和进度。
4、我知道了Bug是改不完的。
项目后期，或许测试兄弟是为了绩效还是什么原因，会“往死里测”。但一个10余年工作经验的老专家审视我们的项目的时候，笑着说了句“Bug是永远改不完的”。
要根据需求、计划进行修改，后期功能性的Bug必须改。非功能的体验、无关痛痒的Bug可以不用改。这点要勇敢说不，我做的还不够好！
5、我知道了影响版本整体进度的关键路径的重要性
版本是模块的集合，如果一个模块“拖了后腿”，其他模块再快也是未完成、未达标。而“拖了后腿”的模块就成为关键路径。
尽早识别关键路径的风险并及时采取跟进措施，对团队开发有很大帮助。
6、 我收获了英语口语的长进，我更加敢说了。
2014-3-20 pm23:47 思于家中床前
作者：铭毅天下
转载请标明出处，原文地址：http://blog.csdn.net/laoyang360/article/details/44500851
如果感觉本文对您有帮助，请点击‘顶’支持一下，您的支持是我坚持写作最大的动力，谢谢！