本篇文章主要用于客户端升级程序整个从需求、设计、开发、测试和发布整个过程中的回顾，用于梳理这过去大半年时间内，在此项目上面的经验教训，在以后开发类似项目时，避免走弯路，避免自己挖坑以及踩坑。
需求
客户端升级程序主要是为了升级客户端，整体逻辑很简单，从指定策略服务器获取升级策略和文件列表，下载完成后，根据策略指示来提示用户升级。
需求和产品人员在最初的设计中，加入了手动自动两种模式，升级策略也有先下载后提示，先提示后下载和不提示三种主要策略，每种策略下面还细分，升级类型也有细分。种种可能性压过来，在具体实现上，要考虑的地方非常多，虽说后期有过一定的设计优化，仍然不改整体升级逻辑的复杂性。
小结，在产品需求阶段，开发人员要有一定的介入，产品人员不要想着第一期就把能想到的所有功能和情况都给上线，做好功能点规划，哪些比较重要，哪些不那么重要，分批次上线功能，完善程序的自我更新机制即可，第一期就搞这么复杂，导致后续的开发和调试耗时过长。
设计
在产品人员出设计交互图时，往往比较随机，按照自己的想法去做，各个图之间的交互逻辑，图上面按钮的有效前提条件，出错的情况下的提示界面以及重复出错的处理，都没有太过细节的梳理。在实际开发中，会碰到各种错误情况，各种具体的交互细节流程未定的情况，在这种情况下，要如何顺利走下去？真是个麻烦事儿。具体处理，在开发章节详细说明。
开发
错误处理
在第一次迭代开发过程中，没太多考虑错误，只要不影响后续逻辑，就可以正常走下去。到后来测试人员提示，有些错误需要提示而程序没有提示，在增加了错误提示后，测试人员又提示，在某些测试环境下，错误提示的太频繁了，不好。紧接着又改成针对指定错误，提示指定次数的方案。在错误弹框的可重入性问题上(下一次错误来了，上一次的错误框还要不要存在?)，在下载文件时碰到网络断开和网络质量不好的情况下该如何提示？在获取策略时碰到网络问题，又该如何提醒？如何在网络质量不好的情况下，尽最大可能的下载文件等等各种错误情况下的提示处理，开发和测试的理解又有了分歧，而这些在需求文档里面就一句话，下载成功，提示升级，而失败的情况根本就没写清楚，可能他们在写之前都没考虑到有这么多不同的情况出现。他们有他们的局限性，我在想，如果是我去设计这个产品文档，考虑各种错误的话，会不会变得像老太婆的裹脚布一样又臭又长？哎，产品设计真是一个需要各种权衡利弊的工作，开发到现在，自己回想刚开始接手这个项目时，肯定没想到过有这么多可能的错误情况需要处理。做到现在，理解到，要想把一个软件做到健壮性是多么的不容易，因为有各种已知未知的错误在等着你去踩。
小结:在开发过程中，涉及到同类型的错误提示积累到一定数量的情况下，再去和产品讨论该如何处理。在讨论时，先给出自己的意见，因为产品人员最终很大可能会采纳你的意见。商定同类型错误处理后，需要及时将讨论的结果更新到需求文档中去，给开发和测试都通知下，下次就按照这样的错误去开发和测试。
版本管理
每次提交给测试测试的版本，必须要有一个版本号，每次提交时，版本号要按照一定规律递增，同时在发布目录下，写好每次修改的ChangeLog，方便测试回归确认和开发追溯。
log日志
对于后台运行程序的测试，在开发测试阶段，打log是很重要的。这里打log有两种方式
- 使用第三方log日志库
- 自己写log日志库
使用第三方log日志库的好处是方便快捷，成熟可靠，但坏处是发布时，需要带上相关的dll，如果在发布版要求不能带上不相关的dll，那测试版和发布版就有了区分，这样不利于发布版的测试回归。
自己写的log日志库，好处短小精悍，不用带dll，在配置文件中增加一个开关即可即开即用。
在开发前期，我一直是用第三方log库的，在后期发布测试时，就改为自己写的log库。
网络下载
在开发环境中，网络可以认为是百分百是好的。而在测试中，会出现各种各样的网络，3g，4g，城市公用wifi，公司wifi，局域网等等。在下载策略或者下载文件的过程中，真的是会遇到各种情况，脑子里要时刻想着，我们生活在一个网络不稳定的世界，程序中一切的处理，要按照网络不稳定的情况下来处理，因此，我在下载阶段增加了超时重试、断点续传、在下载过程中响应强制退出、优化下载失败优化策略、优化在同步等待下载结果时UI界面卡顿等各种异常情况的处理，在这里，推荐一个网络测试工具 NetLimiter, 它可以限制指定进程的上传和下载速度，可以模拟各种异常的网络环境，非常方便实用.
在测试网络不稳定情况下的下载时，需要根据待下载的文件大小，设计好合适的超时时间，对于文件下载，根据待下载文件的大小和预定的最低网速（20KB/S）来设置超时时间，同时设置好低速阀值检测相关的选项。对于策略下载，考虑到最大的策略文件大小为1KB左右，针对这种情况的下载，暂时就用最低网速(500B/s)配合两次超时时间(3s,3s+3s)来下载，这样，即可满足低速下下载尽可能快完成，又保存不影响已经出现的弹框的响应.这种在程序中预先设定的最低速度，需要和测试说明，让他们在测试时，有目的性。
配置文件
一般来说，测试环境和开发环境的配置文件是不一样的，例如IP地址，相关服务器地址等等，在开发过程中，千万不要把测试环境的配置文件上传上去了，造成在开发阶段访问了不正确的网址。
调试相关
- 在调试阶段，可以通过附加启动参数，来模拟正常操作
- 调试时，获取程序的执行路径 GetModueFileName获取的是测试程序被调动的路径，而GetCurrentDirectory是获取的真实运行的路径。前一个在Debug和Release得到的结果是不同的，这是要特别注意的
- 升级程序在升级自身这一点要特别注意，可能存在其他文件被占用的情况，要在升级自身时，杀死当前目录下可能正在运行的进程。
- 在定位窗体时，建议使用窗体标题名称，窗体标题名称建议使用当前所在路径的md5值的后四位
- 程序退出时，最好采用正常退出需要的函数，因为在清理时，会清理掉一些必要的变量。只有在万不得已的时候，才能用exit来强制退出。
- 升级前，对于本地文件有效性和个数的校验，是很有必要的。