[经验总结]零九年六月北京之行总结

　　临近毕业，项目有了新需求，用了十天左右的时间实现了需求，周二下午，我们一行四人拿着未经充分测试的新版本赶赴北京。

　　周三上午开工，服务端的升级、导库都进行得很顺利，并按数据需求，在组织测量信息批量入库接口增加了验证案例号的功能。客户端遇到了些麻烦。首先入库与统计客户端的Excel文件导入问题，这部份的代码实现我也有参与，COM机制不熟，代码都是上网找的，自己也不放心这块功能。用户手中的Excel文件不能读取，后来发现将文件在Excel2003中另存一下就能正常读取，什么原因，现在还没分析出来。检索客户端也有问题：SESSION断了再检索会导致程序崩溃；检索结果翻页时遇到有测量结果的案例时程序崩溃；影像传输时可能出错然后崩溃；体积测量值准确度有待核实。这几个问题都会严重影响用户的使用，第一天加班到晚上十点，大多数的问题的解决方案还没有眉目，大家失望而归，原本准备呆一天就回学校的计划泡汤。

　　第二天，早餐时大家统一思想，不把BUG解决完不回去。搭公交又来到窄小的工作间，分配了任务就开工。我分到的解决影像传输的问题。测试了几轮发现影像传输的问题在笔记本电脑上出现机率高，看过了客户端的实现代码，客户端的代码采取是比较省内存的做法，接收一个文件的数据就写一个文件到磁盘中，我猜问题就隐藏在这。因为笔记本的磁盘写操作速度较慢，服务端程序在连续发送数据后，客户端不能及时接收，这样就导致了服务端的连接重置(Connect reset by peer)的错误。这个问题是属于拥塞控制的范畴。为使服务端的发送速度与客户端的接收速度同步，我在服务端程序的影像传输接口中加了一些打印调试信息的语句以减慢服务端的发送速度。重编译程序再做测试，问题解决！　到中午，大家齐心协力把客户端的SESSIOIN、翻页问题都解决了，只剩下最重要的问题--测量结果的准确度问题。刚开始相关开发人员与用户各持已见，开发人员认为新版本的计算方法更合理，用户用老方法测得的结果与文献数据相符，而且还用这些数据在国内发了一些文章。最后，为求得客观准确的结果，用到了水模测试的方法。水模测试的方法是利用水不易被放射线穿透的物理特性，将特定容积（100升）的装满水的容器放在MR机器中，并对其进行多层扫描。再用我们的软件，对多层图像建立3D模型并进行体积测量。在新版本的软件中，水模测试的结果是110升，而旧版本是220升，用户这时候终于同意采取新的体积计算方法了，但还是很无奈，因为这推翻了他们之前的论文数据。解决完这个问题后，时候也不早了，晚上进行了最后的客户端软件布署和测试。

　　流水帐记到这里，再来做个小结吧。(明天再写吧 )

总结：

1. 软件的稳定性是在设计、实现、维护的多次迭代循环中锻造出来的。系统自07年6、7月间开始设计，到08年年中实现原型系统，08年8月之后对整个系统的构架进行重新设计和实现，一直到08年10月才算是构建出一个可用的版本，在这之后，随着业务和需求的变化，系统在维持现有架构的条件下一直在不断的改进功能。历时两年，现在终于有了一个稳定、能满足用户需求的版本。

2. 对于实现中遇到的问题，在用户的运行环境下，要尽快的解决。代码实现中出现的问题不同于设计上的问题，这些问题往往跟运行的软硬件、网络环境有很大的关系。平常的开发中，不可能模拟出与用户完全相同的系统运行环境，很多问题暴露不出来。而且在问题解决过程中，需要与用户不断交流，这也是平常开发中难以做到的，所以对这些问题，应该在现场尽快解决。

3. 系统的关键功能一定要进行有说服力的测试与验证。软件是一种工程作品，软件的功能只能凭实践来检验，不能想当然，也不能光凭理论来检验。实践才能出真知。