构建完整的解决方案.docxVIP

构建完整的解决方案 序言： 今天写的是：构建完整的解决方案。原因是在过去的几年中， 经常面临“需求变化”的问题。努力寻找了很多年的解决方案，现在 想来，或许问题还是出在我们自己身上，因为我们当初的基础不对。 一句“客户并不真的清楚自己的需求”，我们真的明白这句话的含义 并知道如何应对了么？ 什么是“完整的解决方案”？ “完整解决方案”顾名思义，就是包含了客户的所有真实需求， 并可以合理实施的方案。定义很简单，简单的像围棋只有黑白二子一 样，唯一的问题就是：可能的变化多了点，不确定性高了点。 相对围棋而言，软件的需求和方案的问题简单很多了。 主要的问题在于，我们的“需求”中忽略了很多客户的隐形需求。 隐形需求包含哪些呢? 一般而言包括： 1.1维护需求 1.2升级需求 1.3易用性需求 1.4性能需求 基本而言，现在客户也在不断成熟，以上需求会或多或少的提到， 但是，请注意，很可能不够全面。所以我们需要认认真真的考虑一 下，这些需求到底应该包含些什么。 维护需求 客户对维护的要求，一般至少包括这么几个： 日志需求。这个比较复杂，后面会单独考虑。 故障定位的能力。就是说，当系统出现问题时，客户希望系 统能够通过某种方式迅速查明故障的原因，并找到解决或者规避的办 法。 日常维护。通常包括软件和硬件的“健康检查”。 故障报警。当系统出现严重故障时，能够给出足够的信息， 并触发故障处理流程。 升级需求 一般来说，客户对升级的需求有这么几点： 可控制的升级。即检测是否可升级、是否执行升级、多个升 级日标的选择、升级的计划任务等都是可以控制的，比如可以设定自 动检测是否升级;设定自动升级到最高版本;设定执行升级必须为手 工设置;设置手工升级时可以立即升级也可以指定计划任务时间等 等。 不影响业务的升级。基本上客户都希望升级这个事情，不要 影响他们的业务。但是有些系统实在太老了，基于这种旧系统的再开 发项日必然受限于原系统的升级方案。这时就考虑：1.能不能通过升 级，使系统以后升级不再影响业务;2.如果不能，怎样使（本次后以后） 升级对业务的影响最小。 升级的简单性。升级应该简单快捷，没有太多的参数需要配 置，没有太多需要手工干预的步骤。 升级的完整性。尤其是对于分布式系统，升级时需要考虑各 个部件之间版本的一致性。一个升级方案必须是完整的，不能在升级 以后出现由于版本间不兼容的原因而导致系统无法工作。举个例子： 一个简单的CS系统，采用加密通道进行通讯，现在升级加密算 法，该如何设计呢？ 假设是互联网应用，有上万个客户端，该如何设计呢？ 从这个例子可以看出，系统的设计，从一开始就必须考虑这些“隐 性”需求，否则系统架构可能都要****重来。 易用性需求 通常提到易用性，大家会觉得无非是界面啦，帮助啦。没错，但 是不全。 让我们看几个例子，可以大概理解一下易用性是什么概念。 在桌面系统的竞争中，专业而强大的Unix败给了经常被人批评 的Windows系列，因为windows安装简单，升级简单，安装新的游戏 或者软件也很简单，操作起来更是如此，直观的图形界面虽然设计和 功能不太丰富和强大，但是相对于unix必须先学习“文件系统”概 念，再学习命令行而言，“树”的概念用户可以无师自通，拖拽更是 没有命令行可以比拟； 同样是微软，C++语言乘微软之名，挟操作系统之利，语言和开 发环境都不可谓不强大，但是结果怎样呢?IDE方面多数人还是用SI， 语言方面，微软更是不得不推出C#来与Java抗衡。就因为SI看代 码的时候查找上下文方便；Java比C++开发起来方便； 在中文输入法的竞争中，强大高效的笔画输入法败给了拼音输入 法。现在拼音输入法大行其道，笔画输入几乎鲜有提起。 最主要的，是业务模型要和客户的一致。这个应该算是基础。业 务模型代表着思维模式（比如输入法），也就是说，要从客户的角度来 设计系统，而不是机械的堆砌数据和流程。 一般来言，易用性的需求还包括： 常用的功能应该能够直接了当的访问。比如财务系统，不同 的角色有不同的常用功能，系统应该设计为可以根据角色来打开不同 的初始页面;再比如我们常见的游戏，Save/Load菜单通常都在主页 面上，没有谁设计成非得看完片头（还不能跳过）再新建游戏然后再一 路杀到存取点才可以读取进度。 这里，不推荐严格的学术分级模式。或许这样看起来很专业，但 是不好用。 操作应该照顾客户的习惯，尽可能的降低客户的学习成本。 当然，前提是正确定位你的客户群。 优雅。举个例子，log。 写log的时候，不要一口气写个7、8G的log文件，尽可能的根 据某些标准来归类和拆分。例如按照时间，按照log的级别。 还是用MS的VS Studio做例子，编译错误可以直接通过双击跳 转到源代码所在，而不像Makefile那样只是生