别把问题复杂化

    我也找不到什么直接的理由来解释这该死的金融危机与我换部门有何关系，但不管怎么样，庆幸的是，我
只是被扫地出门而立即又被另一部门接手。
    如果按我两年前的性格我会一走了之，也许时间让我认识到“人在屋檐下，不得不低头”这句”至理名言“。
再加之我被劝告知金融危机之时不宜变动，先静而观之。
    OK，我便静而观之。先把手头的活玩转开来吧。
    其实有时候很是羡慕那些电子产品，有多种语言的说明书，悲哀的是人却没有，所以人用起来总是最难
的。这是站在管理者的角度来说，而站在被使用的雇员的角度来说，我们会埋怨为什么不被正确地使用？也许
人这种由简单的神经组成复杂的神经系统而控制的自然产品太过多样性和灵活性，使用本来就不精确的语言来
描述这本身就不固定的“产品”实在太难。所以需要时间，也许时间是最好的解决方案。
    也罢，即来之，而安之。所以投入地开始工作起来。分配到我手头上的第一堆任务的第一个任务，是为一
个中间件写测试程序。其中一个问题是为中间件的文件管理接口进行测试。我花了一天时间搞定了如何在现在
的平台上写代码，调试，并把我自己的构想在屏幕上表现出来。
    接下来就是对这个测试程序实现的思考。他们的需求如下图：

    我一开始的设计是这样的，①和②都是静态的字符串，而④是由多个③组全而成的，并且⑤是由多个
字符串组成的。所以我做出了一个抽象：将字符串进行抽象成StaticText,它有一些像前景色，背景色，
是否可见等一些属性，则①和②分别是一个StaticText的对象，⑤则由多个OptionItem构成的集合，
而OptionItem是一个可变的字符串，也就是说OptionItem的属性比StaticText多一些，所以我让
一个OptionItem包括了一个StaticText进行封装，④是一个ListView，它则由多个ListItem构成，
每一个ListItem的组成与OptionItem的组成原理一样，不过是由多个StaticText组成，由为它由多
个属分别表示一个文件的属性域。如果是这相抽象的话，类图如下：

    其中Dumper是一个文件显示器，也就是说当查看一个文件时需要显示文件内容。它应该在ListView的
位置上。当我有了这个腹稿后，我便开始实现基本的组件。
    当我正要看到整个架构将要出现雏形的时候，当我正在佩服自己的速度的时候，当我在叹服于这个设计
的优良的时候，当我正想着以后我的工作将会因现在所做的抽象工作而效率将大大被提高的时候，当我正
在神速般地敲击键盘的时候，我的组长走过来，听完我的设计构思后，很不情愿地告诉我：“你不能这样做”。
    “不能这样做？”，我蒙了。“不能这样做，你不能再去抽象，你得基于现有的接口进行开发，得让日本
人(该死的日本人)看得明白，你以后的每一个测试程序都是基于已经抽象好的接口开发的，而不是你自己的。
所以，你这样做把它们的接口都藏起来了，代码在review的时候我想肯定是通不过的。”
    “那这不是在禁锢我们的思想吗？”，我是在责怪（有点直）。
    “是的。我也认为是这样，但你必须得按要求，我们这边的规定来做。”，组长还是很有耐性的。
    他跟我解释了为什么不能这样做，他也觉得我这样是不错，但不允许。别把简单问题复杂化。

    恰巧的是跟朋友交流的时候他问到我一个关于如何设计的问题，有三行字符串和一个外框，他问我如果要
我来实现显示我会如何设计。我正好把我对这个测试程序的写作构思告诉了他。（边框也有字符表示）正好符
合这个将字符串和边框进行抽象的设计思路。
    但是也有一个更糟糕设计方案，就是先打印一个边框，然后一竖，然后打印"Hello World!",完后又打
印一竖表示右边框，其他几行也照此例一一画出。个人觉得这种实现方案是比较丑陋的，而我的设计思路是比
较合理的。
    而就是这个合理的设计被不允许，组长所告诉我的就是让我用后一种方案去实现这个测试程序的界面描
画。My God!我得把我好几天的工作全部扔进垃圾桶。这难道就是项目管理中所谓的交流的成本？
    《人月神话》里把人月的实现说成是不可达到的神话，指出交流的成本太高，我似乎有点明白。而我只能
把我所有的成果都不情愿里扔进回收站，但愿有一天能将其还原，而不是永远被打入死牢……
    不过“别把问题复杂化”这句话还是值得思考地……