为什么要在大连数据恢复软件开发维护这一章讨论组件化开发的话题呢？

      我有一个简单的逻辑，软件维护是对软件系统的改造，只有扩展性好的软件系统才便于改造，组件是扩展性最好的程序结构形式。所以，我要讨论组件化开发。

      对于软件维护来说，组件化开发的想法似乎有点过于理想，这要求大连数据恢复软件开发人员在软件维护阶段到来之前（准确地说，在软件开发之初），就必须开始考虑将来的改造问题。这不是一件简单的事情，然而，这是一件必须做的事情。

      很少有人会对将来的事情进行有效的预判：有些人是没有预判的意识（例如，软件开发新手）；有些人是没有预判的能力（例如，大多数大连数据恢复软件开发组织中掌握了话语权的软件开发人员，否则，软件行业会更加光明）；有些人是拥有丰富的预判能力，却否认它的存在（例如，敏捷开发高手）。

      敏捷方法不屑于对将来的预判，它提倡“刚刚好的设计”思想。“刚刚好的设计”这种说法，很容易让人产生歧义。这是一种不负责任的说法。

      致远服软认为：http://www.soft8.com.cn/，软件的设计方向和设计的主体结构必须足够好，换句话说，方向和主体结构至少要保持5年以上的稳定，想想Linux、Windows、Eclipse吧。只有在设计细节上，我们才应该考虑大连数据日志存储开发成本与回报之间的平衡，可以采用所谓“刚刚好的设计”。

      要想做到足够好，就必须进行预判。我们来看一个故事。

      有一家人家做了新房子，但厨房没有安排好，烧火的土灶烟囱砌得太直，土灶旁边堆着一大堆柴草。

一天，这家主人请客。有位客人看到主人家厨房的这些情况，就对主人说：“你家的厨房应该整顿一下。”

     主人问道：“为什么呢？”

     客人说：“你家烟囱砌得太直，柴草放得离火太近。你应将烟囱改砌得弯曲一些，柴草也要搬远一些，不然的话，容易发生火灾。”

     主人听了，笑了笑，不以为然，没放在心上，不久也就把这事忘到脑后去了。

     后来，这家人家果然失了火。左邻右舍立即赶来，有的浇水，有的撒土，有的搬东西，大家一起奋力扑救，大火终于被扑灭。除了将厨房里的东西烧了一小半外，总算没酿成大祸。

      为了酬谢大家的全力救助，主人杀牛备酒，办了酒席。席间，主人热情地请被烧伤的人坐在上席，其余的人也按功劳大小依次入座，唯独没有请那个建议改修烟囱、搬走柴草的人。

      大家高高兴兴地吃着喝着。忽然有人提醒主人说：“要是当初您听了那位客人的劝告，改建烟囱，搬走柴草，就不会造成今天的损失，也用不着杀牛买酒来酬谢大家了。现在，您论功请客，怎么可以忘了那位事先提醒、劝告您的客人呢？难道提出防火的没有功，只有参加救火的人才算有功吗？我看哪，您应该把那位劝您的客人请来，并请他坐上座才对呀！”

      主人听了，这才恍然大悟，赶忙把那位客人请来，不但说了许多感激的话，还真的请他坐了上席，众人也都拍手称好。

      事后，主人新建厨房时，就按那位客人的建议做了，把烟囱砌成弯曲的，柴草也放到安全的地方去了，因为以后的日子还长着呢。

     什么事情都要有个预见性。如果自己没意识到，听听别人的建议也是好的，防患于未然总比出了险情再去补救更为重要。