|
|
|
| 您的位置:首页>>设计模式>>Reusenbsp;thenbsp;Componentnbsp;(上) |
|
|
Reusenbsp;thenbsp;Componentnbsp;(上)
|
| 2007-04-13 来源:www.javaresearch.org 作者:未知 |
来源：Java周刊
我记得小时候要写数学作业时，如果遇到那种大家都解不出来的问题时，通常会有一个高手会先把解法解出来，剩下的人再依样画葫芦，照着抄一遍。只要高手没有写错，不会是每个人都错同样的地方，老师通常不会发现。只是有些时候，有些人抄的时候，把过程给写错了，却可以算出正确的答案，就有可能会被老师逮到。
很多人把相同的观念用到了软件开发上，特别是在面向对象开发盛行之后，很多人通常会希望在开发软件时，应该有人先开发出一些可以共享的对象，然后让大家可以在不同的场合，不同的时机里重复使用(reuse)，经过这样子产生的综效，就可以减少重复的工作，并且加速开发的流程，提高整个团队的生产力。
这通常给程序开发人员一个很好的借口，当他的进度落后时，他只要把reuse放在口上，大部分的项目经理都会愿意投资一些小小的时间与资源，在进行这样的工作上，特别是这样有机会让日后的生产力有倍数的成长。
在某次整个开发团队的status review meeting中，我们听到这样的对话。
布鲁斯(带着质疑的表情)：强森，我从你的status report中可以看到
，你目前的进度正在落后。你这个礼拜正在忙什么？
强森(有点兴奋) ：我这个礼拜正忙着设计跟开发一个可以共享的
component，所以花了不少时间。我想如果一切
顺利的话，大概再两个礼拜就可以完工。所以
整个进度大概目前会比目前的plan晚三个礼拜。
可是如果这个component写的好的话，我们就可
以马上发挥它的威力。如果每个人都用我新写好
的这个comonent的话，我预估可以省下我们一
半的开发时间。我想如果没有出大问题的话，应
该可以让大家提早两个月完成
布鲁斯 ：Good job。(面对其它的人) 我常常说，要work
smart，不要work hard。你们要好好跟强森学习。
艾力克斯，你的进度怎么样？…
一个月后的status review meeting....
布鲁斯(带着没有耐心的表情)：强森，你的那个共享的component现在进度怎么样了？你不是说，两个礼拜就写完了吗？现在都已经一个月了。
强森 ：我目前遇到几个比较tricky的bug，所以花了不
少时间在找问题，现在还差一些小地方还没做好
。我想应该再给我一个礼拜应该就没有问题了。
我想应该还是可以让我们提早一个月完成
implementation。
布鲁斯 ：要注意时间喔，还有quality。Quality是最重要的。
Implementation delay了一个月时的status meeting...
布鲁斯(带着没有耐心的表情)：强森，汤米跟艾力克斯还有洁西卡，都是call
你所写的那个共享的component，可是每个人都
遇到不一样的问题。你写的这个component到底
还有多少bug？到底什么时候才会稳定下来？
强森 ：我想可能是上次debug时，带来的side effect。我
想再给我一个礼拜的时间，应该就可以稳定下来了。
不过我想对于日后的项目应该可以有相当大的帮助。
布鲁斯 ：不是早告诉过你要注意Quality了吗？(对着整个team)
Quality是最重要的。我们做什么事情，都要确保它
的quality…
Implementation delay了三个月之后，强森离开了公司。留下一个勉强可以运作的component。在日后的project里，这个写好的component从来都没有被reuse过…
当然这里可以从对话中，发现一个有趣的现象：
- 一般的程序开发人员，非常喜欢使用If then else的描述。而管理人员，通常只会听到他想听的部分。
我用这句话来做比喻：『如果太阳从西边出来的话，天上就会掉下来很多很多的钱，让我一辈子也花不完。』
对一个程序设计师来说，这是一个完全make sense的statement。因为程序设计师通常都拥有良好的逻辑观念：『若A则B，如果A的值是false，B的这个block当然就run不到』。可是对于老板来说，他只听得到『天上会掉下来很多很多的钱，让我一辈子也花不完。…』
所以当强森说：『我想如果一切顺利的话，大概再两个礼拜就可以完工。』
指的其实是：『如果你运气好，再给我一个月就会写好了。这个component多有用啊。绝对值得花一个月的时间开发。可是如果你知道要花那么久，你一定不会support这件事。没关系，预估本来就会有误差。』要特别注意到的是，连他内心的想法，都包含了if then else的架构：
If (你运气好) then {再给我一个月就会写好了。};
component = 非常有用;
非常有用 = 绝对值得花一个月的时间开发；
If (你知道要花那么久) then {你一定不会support这件事};
嗯，这就是软件工程师跟一般人最大的不同。
然而对于布鲁斯来说，他只听到：『花两个礼拜，就有一个可以让整个team提早两个月完工的秘密武器，以后还可以reuse，我们以后就会有超高的生产效率，可以把对手远远?在后面…这简直就像是拥有自己的印钞机一样嘛。就算这个家伙慢了两个月，我还是可以从日后整体加速的时间补回来啊。我要不要跟吉娜报告这个好消息？因为我卓越的领导，才会有这么高的生产力，表现这么优秀，今年一定可以领一百张股票…』嗯，这就是老板跟一般人最大的不同。
根据非正式的调查(作者注：可以参考我跟灵犬莱西的访谈纪录为证)，reuse通常没有带来如同预期的生产力改变。在某些特殊的案例中，太强调要reuse还造成了schedule的严重落后。我尝试着归纳出下列原因：
*自以为厉害的程序设计师只想用他自己开发的component。
*开发软件最花时间的部分，并不是在于写程序本身。
*低估学习使用component所需要花的时间。
*错误的component设计理念，以至于reuse这些component反倒会降低生产力。
*低估开发component的困难程度以及测试component的困难程度。
*开发出来的软件，响应速度太慢，需要进行大幅度的改写。
以下我会针对这些原因，进行更详细的说明。
***自以为厉害的程序设计师只想用他自己开发的component***
对很多号称是程序设计师高手的人来说，开发自己的component，比起使用别人的component，要来得有成就感多了。使用别人的component，固然可以增加批评的乐趣，可是对于这些人来说，带来的不适可远大于带来的便利。最主要的原因在于：
-使用别人的component，就像把别人用过的保险套洗一洗，再拿出来用一样，虽然看起来外表没什么问题，可是，恶！谁知道里面藏什么脏东西？
女性读者如果没有用过保险套的经验，可以想象把别人用过的卫生纸晒干再来reuse…很恶心对不对？觉得很脏对不对？使用别人写好的component，大部分时候，差不多就是这样的感觉。
对于这些人来说，别人开发的component总是有不够完美的地方，即使外在接口定义的清清楚楚，使用各式各样的数据进行测试看起来没有问题，里面还是可能会暗藏玄机。想想看在电子表格的程序里面，居然可以玩仿真飞行游戏？
…别人写的东西，你如果拿不到原始码，你永远不知道到底藏了多少后门跟bug在里面…还是自己来吧。
然而当你写出自己的component，那故事就完全不一样了。大部分的人都希望自己写的东西可以造成轰动，让自己做好的这个小螺丝钉，可以使用在各式各样不同的场合。这很像是看着自己养大的孩子长大成人一样。即使它不成材，你还是认为它可以承担重要的责任，每次看到有人在用它，就会忍不住内心窃喜。当然，总有人不识货，会低估我们所撰写程序的一般性与超高的弹性。遇到这种状况，当然得要指责这种不具团队合作精神的行为。除此之外，建立一套一定要使用你开发对象的标准，在把这个文件列入你们公司的ISO文件中，就可以强迫使用这个component。对了，如果有谁看到我所写的薪资计算模块，请帮我告诉它，我很想念它。我还是觉得它是最棒的。
因为文人总是相轻，所以要说服其它人使用你所开发出来的component，就得要花相当大的力气。所以很多时候，所谓的reuse，其实都只有自己在reuse自己写过的component。
使用别人的component，是否可以提升生产力，其实还跟下一个问题有关：
***开发软件最花时间的部分，并不是在于写程序本身。***
共同开发软件，其实象是把一堆来自欧美非各个大陆，不同国家的人，共同聚集起来，用文言文来写新诗一样困难。最困难的地方，在于要能够彼此沟通，清楚了解到底要开发什么，还有要怎么开发这个东西。观念的沟通，是最花时间的。写程序本身其实并不是最花时间的部分。即使你看着良好的设计文件，你还是需要消化别人的想法，仔细地思考，再转化成你自己的想法，最后才会变成程序。而这个过程，并不是任何共享的component可以加速的。
所以对于生产力的提升，其实是在一个人已经清楚地知道他要负责撰写什么样的程序以后，并且也了解component要怎么使用以后，才会带来这样的效益。如果component的引进，可以让沟通观念的速度加快，只有在这个时候，才会带来生产力的提升。不过有关生产力的提升，事实上还是有极限的。
布鲁斯：你们不是拥有共享的component吗？所以生产力不是已经提升了50吗？你们不是对它越来越熟悉吗？应该可以越做越快啊。上次写了三个月的
程序，现在应该只要三天就可以写完了吧，咦，不是吗？
况且除了沟通以外，我们不可以低估找东西所需要的时间。你需要一个component，可是这个component到底在那里呢？有谁写过类似的东西呢？如果你运气不好，可能你会花三天的时间去找一个你一个下午就写好的东西。很多人都会选择自己动手写，而非找共享的component。所以越简单的小程序，就会有越多人想写写看。况且写写小东西，本来就是程序设计师在学习一项新把戏时，最常做的事情。所以轻量级的component，数量可能最多。累积起来也花掉最多开发的时间。
还好一家公司通常都会有几个超人，可以迅速帮你找到你要的信息。类似搜寻引擎的程序，可能可以帮你一点忙，可是这些程序运作的前提是，必须要有人整理过这些信息。而这个假设的不成立，通常也说明了为什么要推共享的component会相当困难。因为要使用的人，不知道你这里有好康的东西。
当你找到了这个component，你也了解在你完成你的工作时，会需要用到这个component时，这时候所面临的问题，就被提高到了另一个层次...(待续)
|
|
|
| |
