知难而进
——反思我带的第一个版本
下面逐个阶段回顾，并就出现的问题进行反思。
1、需求阶段
仅仅花费2周左右的时间，简单从互联网获取资料、竞争对手网站/试用包分析、基础云平台部署预研，就开始了版本。
对于研发人员的我们拿到的是一份很宽泛的需求文档，涉及范围很广。包含：
（1）产品易用性改进：向导部署、图形化界面&命令行接口的后台、多序列号合一、非IE内核浏览器（Chrome、Safari浏览器）支持。
（2）产品功能改进：部署模式变化、非产品相关功能删减。
（3）产品性能改进：保证速度达标且保证有好的削减效果。
反思：
需求点（3）是真正到了集成测试阶段中期才识别出来的。且属于历史遗留问题，和早期的架构和设计有关，只能做边边角角的缝补，，即便花了很长时间，但仍然难得到既定目标。
这种问题，应该放到版本的早期识别，且定好改动目标和截至时间，不能达标走规避方案。
2、设计阶段
两个模块向导部署CGI后台以及序列号模块是进行了方案选型和微型/概要设计的。其中序列号方案时候对于场景考虑是不充分的。
在虚拟化平台上，由于安装包可以任意Copy，同时序列号也是可以任意Copy的。是不是用户买一个序列号就可以任意使用了呢？
这里就需要提防：
（1）两个相同序列号对接，校验判定，结果：不允许对接。
（2）多个相同序列号的分支接入一个总部，结果：不允许对接。
（3）一个分支接入多个相同序列号的总部，结果：不允许对接。（当时想到这种场景，但因为是小概率场景，就没有关注）
反思：
小概率场景对于开发来说也必须考虑，一旦出问题就是灾难性后果。不要把问题留给用户，有可能预见到的问题要一网打尽、消灭在萌芽状态。
事实也证明，后期再去处理该问题，一是本身实现机制不便于扩展，很难改动，且改动可能引发。二是项目进度很紧张，不可能留太多时间处理。
3、编码阶段
如下所示：（仅是示例，实际比这难排查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如下
，执行一个 shell 以运行命令来开启一个进程。
而对于一直在跑的系统，1天、2天可能不出问题，对于性能环境要求24×365运行的话。会很容易出问题，很耗费性能，导致连接中断。且非常难排查。
反思：
这些最终排查出来都是细节不注意的小问题，但是如何在高压的项目环境下最快排查问题所在、并修正问题，着实需要花精力去学习、去积累。
4、集成测试阶段
分模块之后，利大于弊。利是：独立的模块可以分开转集成，提交测试部测试。但注意此时关键路径就成为后面才开始模块。
团队里面就可能出现：后台已经实现，在等待与前台对接。几个独立模块都完成了，就等待合入。
反思：
如果模块之间有等待关系，比如后台CGI等待前台html、JS页面对接。此时后台可以自己构造数据进行手动或者自动化测试。
有等待关系的模块也可以先开始BVT案例执行。总之，不要等待，这样整个版本的进度才有保障。
5、系统测试阶段
才能做到人在旅途，感悟人生，享受人生。
