|
|
|
| 您的位置:首页>>设计模式>>Reusenbsp;thenbsp;Componentnbsp;(下) |
|
|
Reusenbsp;thenbsp;Componentnbsp;(下)
|
| 2007-04-13 来源:www.javaresearch.org 作者:未知 |
***低估学习使用component所需要花的时间***
如果你对这个component完全地不熟悉，你到底要花多久才能了解要怎么样来使用它呢？如果你能够了解它背后的设计理念，你可能不用花太多时间，就可以了解它的意义。问题是，大部分可以称得上是component的东西，通常都十分复杂。即使拥有相当多的参考文件，许多人的学习，还是需要透过从使用这个component的经验中，慢慢观察，多多练习，才可以渐渐掌握它的精髓。这跟学习骑脚踏车与游泳的道理是一样的。
这个过程，非常像是透过component与原作者进行心灵上的沟通。然而我们常常会低估这样的学习，所需要花的时间。这通常还得要视你是否可以得到原创者的开示灌顶有关。如果你可以获得原作者的现场指导，通常会有机会顿悟；如果你只是透过文件想要了解他的神奇功用以及微言大义，要花的时间差不多就是跟你要透过电话性爱达到高潮的时间差不多久。
对于撰写component的人来说，每次有人用他所写好的component，带来的兴奋可能就真的跟透过电话性爱带来高潮差不多。刚开始会很新鲜，久了以后就没啥子感觉了。再久一点，等到所有使用的人把他们的问题跟抱怨用email把你淹没，或是又有一个菜鸟，希望大师可以拨冗指点迷津之后，这种心情，可能就会转变成跟专业的色情电话接听小姐一样吧。只会剩下虚假的高潮，跟交差了事的应付吧。
当然，这还算是你运气好，也就是说你所用的component，是真正有用的。然而有些时候，你会遇到这样的状况：
***错误的component设计理念，以至于reuse这些component反倒会降低生产力。***
这跟你抄数学作业，抄到印刷错误的解答还是抄错题差不多。只是通常发现的时候，都已经太晚了，老师都已经把分数打完还给你了。也很像是剃头剃到一半，打了一个瞌睡醒来后才发现，原本打算扎个马尾，这下子已经半边是个大光头了，不剃成整个大光头，就得要打扮成清朝的辫子头。老实说，用了设计不好的component，差不多就像这样。
根据调查，设计不好的component，在这个业界还真常见。(再次感谢灵犬莱西能够协助进行调查的工作)。我想这可能跟component到底是怎么设计出来的过程，有绝对的关系。
很多人都认为，可以被reuse的component，是某个天才，坐在树下被苹果砸到就想出来的道理。这种故事只是说明了大多数人不知道牛顿花多少时间去观察天象，并研究别人所研究出来的结果。老实说我也不是很清楚，毕竟他在做研究时，我并没有在现场目睹。
然而对于不好的component，我可是看到过不少。我不否认会有会有像我一样的天才，可以一眼就看出事情的本质，然后设计出可以重复使用功能超强bug超少的component。可是这样的人呢，通常像凤毛麟角一样地稀少。大多数比较好的component，都是建立在对于某个领域的了解与经验，将许多类似的东西抽离出来，才有办法做出应用很广，很容易reuse的component。简单地说，component应该是演化的结果。
经过实际运用、改良、测试、再改良，才会有功能越来越强，应用越来越广的component。当然，即使是天才，通常还是要经历过这样的过程。只是时间可能会短一些就是了。
然而有许多人就是弄不清楚，自己到底是天才，还是一般的凡夫俗子。所以通常会把自己的小小心得，当成光芒万丈的创见。然后就会写出没什么用或是设计很不好的component。受限于经验，通常这些component都会有不太好用的地方，甚至根本就是把一件简单的事情，变得非常复杂。
然而有这个特权可以设计component的人呢，通常都具有一定程度的政治影响力，老板才愿意投资时间跟资源在他们身上。通常隐含的结果，就是这种不太好用的component，会被强迫应用在项目里面。所以一个不是植基于经验与实际应用的component，带来的坏处远远大于所可以带来的好处。
除了经验以外，很重要的一点就是模仿。毕竟一个人的经验一定有限。现在有许多open source(开放原始码)的component。当你花时间下去trace(追踪)这些component，并且从实战中累积使用的经验之后，通常透过这样的模仿与消化，你建构component的能力就会成长，这个时候才会比较有机会做出更stable(稳定)更良好的component。
然而，老板通常都相信牛顿原本是个白痴，被苹果打到以后，忽然开窍顿悟万有引力这一套，所以会对开发component的流程有错误的期待，间接就会造成这样的现象：
***低估开发component的困难程度以及测试component的困难程度***
如果component是由经验中推导出来，也就会从以前的实作经验中，抽出适合的程序，来加以归纳与整理。这样的流程，由于是根基于以前的程序，所以在开发上与测试上，相对都比较容易。
然而一旦老板接受了component的开发是天启的结果这种神奇的观念，灾难马上就会降临。Component的好坏，只能建立在天才的高超想象力之上。然而这种纯粹根基于想象力的component，通常基石不稳，所以即使设计好了，还会面临相当多的困难。因为你所预测的运用可能根本不会发生；你始料未及的需求可能不断出现。要开发component的困难程度，相对地就会变成非常高。加上以往可能没有相关的程序当作基础，所以整个component的测试就会是一个梦魇。
更不要提，不当的设计通常会伴随着无数的修改。每次的修改，就会带来新的边际效应。久而久之，很有可能就会叠床架屋，变成一个巨大的怪兽。这个效应，如果伴随着原作者离开，会有更显著的影响。
如果你有维护过大型系统的经验，你就会了解这种可怕的现象。有许多时候，每个人都只维护很小的一个部分，所以并不知道自己的程序会带来什么结果。所以只能就单一模块或是单一个component来看。
问题是如果原作者离开了，通常要完全掌握他所写的程序，就需要从文件来了解他的想法。如果文件残缺不全，还是文件根本就写错了，那就只剩下程序代码可以告诉我们事实的真相。
问题是如果是维护一套既有的系统，通常我们还没有能力掌握事实的真相，就会收到要我们修改程序的需求。这些需求通常都会有蛮大的时间压力，不改不行。这时候就精彩了。你要对一个你不是完全了解的东西去做修改。所以边际效应会不停发生。为了降低边际效应，也因为他们没有时间跟精力去研究成千上万行的程序代码，所以通常的做法就是写一段程序，把原有程序计算出来的结果，加上一些新的运算，产生新的结果。
如果运气好，这个人还会写一些文件跟批注。问题是如果当你前面已经有数十个能力习惯不一的人做过这种事情时，事情的真相就没有人会了解了。你会看到有莫名其妙的循环，乱七八糟的程序流程。以及缺三落四的开发文件。你要了解一项东西，可能得要从第一个人的原始文件，一路读到最后一个人的文件，才能掌握大概的情况，还不要提第七个人文笔很烂，写的英文不知所云，第十五个人写的文件根本就写错了。
通常到了这个时候，我们会建议来个改版。对于大部分的人来说，资讯科技的不断进步，顺道解决了这个痛苦的维护问题。
然而如果你还没有机会遇到大改版，这时候通常你会需要解决下面这个问题：
***开发出来的软件，响应速度太慢，需要进行大幅度的改写***
不管使用什么开发模式，是演化型，还是天才型的，其实都有可能面临这样的问题。有很多时候，你写的东西不是弹性不够，而是弹性太高，以至于每次要产生出来这样的结果时，需要蛮长的运算时间。当然，那种因为维护的人更替太多，造成叠床架屋的component，更会有performance的问题。
使用者：以前我们只要20秒，就可以打完一张订单了。现在你们的做法的确比较有弹性，我们可以动态地去改变每张订单所需要输入的栏位。可是你们新版的程序，却需要花20分钟的时间，才有办法打完一张订单，单单那个画面要出现就要5分钟了！你们已经tune了三个月了，是有变得比较快啦，现在只要花15分钟就可以打完了，画面只要1分钟就跑出来了。可是还是很慢啊，你们打算怎么解决这个问题？
布鲁斯：可是你要注意到现在我们所提供的弹性啊！我们这个功能开发了这么久，功能这么强大，又把以前的bug都解决了…
使用者：我不管，我可以接受的是30秒。你们都是IT方面的专家，我相信你们一定有办法的…
任何时候，只要你所开发出来的软件，超出使用者的耐心以后，就会有改写的需求。使用者通常都会期待超高的响应速度，加上超级弹性的设定。问题是这两者通常是不兼容的。如果你要负责调整一个设计相当复杂的component的响应速度，通常所需要耗费的资源与时间，是远大于开发与测试component原型所需要花的时间与资源。所以很有可能会因为component的引进，反而项目造成进度的延迟，以及经费的超支。
还是回到component设计的过程来说，经过演化所形成的component，因为经过实际应用的洗礼，所以通常前几次的使用者，会负责逼出回应速度还可以接受，以及系统还保有一定弹性的component。经过整理出这些东西，建构出可以reuse的component，所能够造成的生产力改变会比较明显。所要担负的风险也会比较小。
***结语***
项目管理，原本就存在许多迷思。有一些植基于直觉的思考，可能会带来完全相反的结果。面向对象开发，其实并不是很新潮的理念。如果component都能reuse，那为什么我们还是需要越来越多的程序设计人员？为什么这些程序设计人员，还是需要日以继夜的工作，才写得出勉强可以运作的系统？
我想建立一套可以集体学习，共同开发的开发环境，加上演化式的component分析设计开发流程，才是发挥reuse component最大功效的基础。如果没有做到这点，任何期待引进component就可以改善生产力的想法都是不切实际的幻想。
即使如此，当你的老板还是要你开发可以reuse的component时，千万不要放弃这个难得的特权，毕竟，不是每个人都有机会把项目搞垮的，不是吗？ (全文完)
|
|
|
| |
