Reuse the Component2003-11-14 9:48:51
很多人把相同的观念用到了软件开发上，特别是在面向对象开发盛行之后，很多人通常会希望在开发软件时，应该有人先开发出一些可以共享的对象，然后让大家可以在不同的场合，不同的时机里重复使用(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时，这时候所面临的问题，就被提高到了另一个层次...(待续) --------------------------------------------- 摘自：CSDN.NET |
|
|