关于JADSS
本来准备睡觉了的，可是看见Bluelava写的JADSS(DT) - 我们遇到的问题和挑战忍不住唠叨一下，如果明天早上去晚了，Bluelava帮我罩着一点，呵呵。
- 需求，还是需求。
由于当时甲方貌似非常赶时间，一直希望我们这边能先拿出一个可以用的版本来。于是我们便匆匆定下了结构：上层学MO，中间学DAO，下层则是基于Oracle Spatial的Com Provider。结果上层的MapCtrl经常在甲方的要求下改来改去，因为他们告诉我们MO不好使，你看SuperMap的控件有这样的功能哦；下层的Provider则常年累月的测试性能，因为它的速度在甲方那算大不大，算小却绝对不小的数据下面根本就没法用。
当然，需求的变更在软件行业应该是很正常的事情，大多数情况下甲方在拿到第一个版本之前根本不知道自己想要的是个什么样的东西。而软件行业和所有的服务业一样，顾客就是上帝，并且顾客比上帝还要牛逼的地方在于他们完全不用管什么叫做Free Will。所以我们理应在开始之前，学摩西和我们的顾客定一个约，旧约也好新约也罢，告诉他们最基本的游戏规则。在规则之内，我们可以随他们玩弄；规则之外我们要敢于说不，你要知道即使是程序员，也和妓女一样是有尊严的。 - 设计，离不开设计。
前面说了这么多，好像我在抱怨甲方，其实我一点都没有这个意思。如果你的顾客从你这里买了一面镜子，可是当他照镜子时却发现照出来的居然是屁股，那么你应该很能体谅他把镜子丢在你脸上的举动，何况我们的甲方并没有把那几万行代码打印出来或者直接抱起电脑来砸我们。
我们的问题在于我们为什么会制造出只能照到屁股的镜子。也许这一次我们的需求定义真的不好，但至少对于甲方要求的数据量和速度我们是早就知道的，可是为什么如此还会折腾出一个完全没法用的Provider？当然主要的原因是因为我的无能，可是除了我的无能之外呢？在项目开始之前，我们对整套工具都不是很熟，更不用说可行性分析，包括Com、OCI、Spatial，我们只知道它们能不能这么用，却不知道它们这么用行不行。我还记得有那么一个月，为了寻找更好的速度，每个周一我就check out一次代码，到周末备份一周的工作，然后undo checkout，结果整个月愣是没有check in过一次代码。
人们喜欢把微软的员工分成三等，第一等几乎看了所有的文档，第二等只是在用到的时候才会去看文档，第三等则很少看文档。想来我们都是很典型的第二等，这一等的人本来是应该拿来做应用型项目的，而项目中采用的技术通常由第一等的人定，他们根据项目来选择技术。我们呢，完全因为技术而技术，选这个技术，只是因为有人说好用，只是因为大家都用。既然对技术不了解，当然也谈不上设计，妄想和上帝在创世纪里做一样的事情。结果只好推倒重来，重来推倒。真不知道这种即使能马上做出来，却无法满足甲方需求变更，以后也没有丝毫扩展性和不可维护的东西有什么好玩的。 - 测试，居然没有测试
听起来似乎我不是很赞同给项目定方向和选技术的人，其实我也没有这个意思。如果敌人在你面前朝你开枪，你还有空考虑抓起来挡在胸口的东西是避弹衣还是昨天吃完方便面没有刷的饭盆吗？不能明白的是为什么当我们发现敌人只是虚张声势，其实连子弹还没有上膛的时候，我们不会把饭盆连着里面发臭的面汤一起丢向敌人，然后去找一件打不穿的铠甲。
原因倒是挺简单，因为我们根本不知道那居然是个饭盆。其实软件测试不单包括功能测试、稳定性测试，还包括性能测试、安全性测试。可惜我们连稳定性测试都没有做好，更不要说性能测试和安全性测试了。程序员做的最没有效果的事情之一就是自己测试自己的代码，那和肠胃消化极其不良的人狂吃东西却怎么也长不胖是一个道理。而让几个当时每天赶工十来个小时的人再去导几个G的数据，并用本该拿来编程序的电脑运行那么几个小时去测试性能，简直就像是在给牛吃屎的同时还希望它能挤出奶来。于是第一次读取大一点的数据已经是在项目开始一个半月之后，而第一个捣腾捣腾就可以简单的读出数据的版本却是项目开始半个月就已经存在了。其实我们都没有想到也不相信Oracle Spatial居然可以这么慢，直到我们装了ArcSDE。可是为什么我们不会早点装，早点测试采用Oracle Spatial并且业已成形产品的性能呢？
最近好废话，睡觉了，困。
PS：Bluelava，你还是把JADSS改成ComGIS吧。
PS2：祝我生日快乐！