工作感言-1-构建完整的解决方案

写在前面:

    最近金融危机--》经济危机了，接到的项目明显减少。感谢这样给了我一个思考的机会。

    想把最近几年的工作感言整理一下，为以后的工作做些准备。

 

 

序言:

    今天写的是：构建完整的解决方案。 原因是在过去的几年中，经常面临“需求变化”的问题。努力寻找了很多年的解决方案，现在想来，或许问题还是出在我们自己身上，因为我们当初的基础不对。一句“客户并不真的清楚自己的需求”，我们真的明白这句话的含义并知道如何应对了么？

 

1. 什么是“完整的解决方案”？

“完整解决方案”顾名思义，就是包含了客户的所有真实需求，并可以合理实施的方案。定义很简单，简单的像围棋只有黑白二子一样，唯一的问题就是：可能的变化多了点，不确定性高了点。

    相对围棋而言，软件的需求和方案的问题简单很多了。

    主要的问题在于，我们的“需求”中忽略了很多客户的隐形需求。

    隐形需求包含哪些呢？一般而言包括：

    1.1 维护需求

    1.2 升级需求

    1.3 易用性需求

    1.4 性能需求

    基本而言，现在客户也在不断成熟，以上需求会或多或少的提到，但是，请注意，很可能不够全面。 所以我们需要认认真真的考虑一下，这些需求到底应该包含些什么。

 

• 维护需求

    客户对维护的要求，一般至少包括这么几个：

    1. 日志需求。 这个比较复杂，后面会单独考虑。

    2. 故障定位的能力。 就是说，当系统出现问题时，客户希望系统能够通过某种方式迅速查明故障的原因，并找到解决或者规避的办法。

    3. 日常维护。 通常包括软件和硬件的“健康检查”。

    4. 故障报警。 当系统出现严重故障时，能够给出足够的信息，并触发故障处理流程。

• 升级需求

    一般来说，客户对升级的需求有这么几点：

    1. 可控制的升级。 即检测是否可升级、是否执行升级、多个升级目标的选择、升级的计划任务等都是可以控制的，比如可以设定自动检测是否升级；设定自动升级到最高版本；设定执行升级必须为手工设置；设置手工升级时可以立即升级也可以指定计划任务时间等等。

    2. 不影响业务的升级。 基本上客户都希望升级这个事情，不要影响他们的业务。但是有些系统实在太老了，基于这种旧系统的再开发项目必然受限于原系统的升级方案。这时就考虑：1.能不能通过升级，使系统以后升级不再影响业务；2.如果不能，怎样使（本次后以后）升级对业务的影响最小。

    3. 升级的简单性。升级应该简单快捷，没有太多的参数需要配置，没有太多需要手工干预的步骤。

    4. 升级的完整性。尤其是对于分布式系统，升级时需要考虑各个部件之间版本的一致性。一个升级方案必须是完整的，不能在升级以后出现由于版本间不兼容的原因而导致系统无法工作。举个例子：
    一个简单的CS系统，采用加密通道进行通讯，现在升级加密算法，该如何设计呢？
    假设是互联网应用，有上万个客户端，该如何设计呢？
从这个例子可以看出，系统的设计，从一开始就必须考虑这些“隐性”需求，否则系统架构可能都要推翻重来。

• 易用性需求

    通常提到易用性，大家会觉得无非是界面啦，帮助啦。没错，但是不全。

    让我们看几个例子，可以大概理解一下易用性是什么概念。

• • 在桌面系统的竞争中，专业而强大的Unix败给了经常被人批评的Windows系列，因为windows安装简单，升级简单，安装新的游戏或者软件也很简单，操作起来更是如此，直观的图形界面虽然设计和功能不太丰富和强大，但是相对于unix必须先学习“文件系统”概念，再学习命令行而言，“树”的概念用户可以无师自通，拖拽更是没有命令行可以比拟；
  • 同样是微软，C++语言乘微软之名，挟操作系统之利，语言和开发环境都不可谓不强大，但是结果怎样呢？IDE方面多数人还是用SI，语言方面，微软更是不得不推出C#来与Java抗衡。就因为SI看代码的时候查找上下文方便；Java比C++开发起来方便；
  • 在中文输入法的竞争中，强大高效的笔画输入法败给了拼音输入法。现在拼音输入法大行其道，笔画输入几乎鲜有提起。

    最主要的，是业务模型要和客户的一致。这个应该算是基础。业务模型代表着思维模式（比如输入法），也就是说，要从客户的角度来设计系统，而不是机械的堆砌数据和流程。

    一般来言，易用性的需求还包括：

    1. 常用的功能应该能够直接了当的访问。比如财务系统，不同的角色有不同的常用功能，系统应该设计为可以根据角色来打开不同的初始页面；再比如我们常见的游戏，Save/Load菜单通常都在主页面上，没有谁设计成非得看完片头（还不能跳过）再新建游戏然后再一路杀到存取点才可以读取进度。
    这里，不推荐严格的学术分级模式。或许这样看起来很专业，但是不好用。

    2. 操作应该照顾客户的习惯，尽可能的降低客户的学习成本。当然，前提是正确定位你的客户群。

    3. 优雅。举个例子，log。
    写log的时候，不要一口气写个7、8G的log文件，尽可能的根据某些标准来归类和拆分。例如按照时间，按照log的级别。
    还是用MS的VS Studio做例子，编译错误可以直接通过双击跳转到源代码所在，而不像Makefile那样只是生硬的输出文件和行号。
    打开一个巨大的文件，给出一个可度量的进度条，总比只显示一个沙漏要好吧？
    现在，应该可以理解什么是“优雅”了吧？我的理解，就是专业，而且体贴。

• 性能需求

    好像现在性能需求越来越被重视了，所以我的废话也不多说，简单讲，包括：

    1. 首先分清楚哪些部分各自有什么样的性能需求。用户参与的操作，性能要求通常高于其他操作。

    2. 知道自己的上限。达到上限的时候，通过合理的方法让系统给予提示，而不是直接瘫痪。当然，这是理想主义。只能无限接近，不能达到；

    3. 性能要求要包括可靠性要求。

    性能是需要设计的，而不是仅靠硬件来实现。所以，在客户没有提到性能需求时，你需要通过各种渠道，真正的确定系统的性能要求是什么。 “先做做试试”的结果往往是推倒重来。子曰“有的放矢”是也。

• 日志需求

    最后来说说日志需求。

    日志需求是和客户的隐性需求密切相关，并且几乎全部涉及的一种需求。例如：日志要记录维护信息和升级信息，日志还要简单明了，一看就知道写的啥意思，另外日志记录功能还不能对系统的性能有大的影响。

    其实“日志需求”的全称应该是“客户和我们利用日志想做些什么的需求”。

    （晕死，刚刚写完了，点击“发表文章”，结果只有以上这么些，还得重写）

    根据我的经历，我认为日志需求应该包括这么一些内容：

    1. 日志必须记录关键事件和数据（维护性），例如操作者，操作名称，结果等；

    2. 日志内容应该便于分析和过滤（易用性），例如哪些是配置数据，哪些是用户操作等；

    3. 日志的级别应该动态可调。java的log4j是个好的开始，但是“修改配置文件，重启系统”的方式还不能算是动态可调；在实际系统中，大多数客户不会因为查看日志而重启他们的系统。

    4. 日志级别的调整粒度应该具有足够的层次和大小。整个系统的级别，或者某个模块，甚至某个类的日志级别可调都是可以做到的。Java和C#都已经有现成的模块可以实现（就是“动态调整”还不够）。其他语言我不是很熟悉，我想没有现成的模块，自己开发也不是很困难吧。

    5. 日志的输出格式和设备应该可控。例如，指定日志输出到磁带机上的时候，如果更换磁带，应该不中断系统的运行和日志的记录。另外，日志经常会用来定位故障，如果输出可控的话，那么专门写一个工具来接收和过滤日志信息，从而定位一些难重现问题就成为可能。

    6. 日志的性能。通常在哪里写日志，写些什么内容，都是代码里写死的，只能控制是否输出。如果在调用日志输出前进行大量的运算（例如字符串拼接和序列化），那么对系统的性能是有较大影响的，最好在代码中，能够保证这些运算都是在确定会被输出后才进行。具体实现就仁者见仁，智者见智了。log接口和简洁性和效率在这里要有一个平衡。

 

好了，今天就写到这里。计划下一篇文章写写如何在项目中将客户的这些隐形需求具体化。