组件重用需要专人负责

不知道诸位所在的公司如何，至少在我现在的公司，代码的重用性是很差的。同一个模块在多个项目组之间重复开发，甚至同一个模块在同一个项目的不同版本之间也是不同的人重复开发......我们把大量的时间放在了做重复性的工作上面，所以就谈不上什么创新了，因为根本没有时间了。

真诚的希望，哪一天我们的工作就像建筑一座大厦，只需要做设计，买来相应的材料就可以组装起来了。无法想象，如果每一个砖头都要亲自打造，何时能够完工。

作为一个普通的开发者，也许我无法改变现实。但是，如果你是一位主管，也许你就可以考虑考虑了。

Component Reuse Requires a Manager

Most companies are blundering into component development without a clear plan. That makes sense, when you consider that senior managers don't usually focus on technologies. They focus on results. Today, most companies are focused on the Internet and on developing e-commerce and eBusiness applications. To facilitate the development the new B2C or B2B applications, companies decide to adopt Java, buy EJB application servers, or rely on MTS and COM . Depending on the tools and servers they buy, they may acquire some components for reuse. If they do, however, those components are already implemented as COM or EJB components.

Making quick decisions and moving fast may solve some of the short-run demands that senior executives are placing on IT, but it won't prepare IT for long-run success.

The first step to planning for IT success is to recognize that the move to e-commerce and the Web is in fact a software technology transition. Of course it is also a business process transition and of course senior executives are more focused on implementing new eBusiness processes, but that doesn't change the way the CIO and senior IT managers should look at the transition. When you start using object-oriented languages like Visual Basic, C , and Java, you are moving toward object-oriented development. When you start developing COM and EJB components and acquire an MTS or EJB application server, you are committing your company to component-based development. Once you face this fact, then the question that follows is: Are you going to do it right, or are you going to try to blunder your way through a major technology transition?

Assuming you decide you'd rather do it right and master component-based development, you need to begin by creating a new job position. You need a Manager of Component Development, and he or she needs to report to the CIO or to the manager in charge of software development. Put another way, your Manager of Component Development needs clout and he or she needs to be located high enough to have a comprehensive overview of what the organization is doing.

The Manager of Component Development should not be responsible for developing component-based applications. Your whole IT group will eventually be developing component-based applications. The Manager of Component Development should be responsible for two things. First, he or she should be responsible for planning the transition. Second, he or she should end up managing the group within IT that is responsible for reusable component resources.

In effect, once an organization commits to transitioning to component-based development, it should begin to move toward an organizational structure that divides those who create and maintain reusable components and those who assemble components into applications. Moreover, until you have this kind of organization, and some component resources to reuse, you can't practice effective component-based development. Without it, you create a development team to create a new e-commerce application from scratch. The team decides on a language and an application server and then creates a design and starts creating components. They may buy some components from the server vendor or an outside resource, but usually they are under such time pressure that they don't have time to figure out how to acquire components for reuse. Besides, not being trained or disciplined to reuse components, most find it easier to create new components than to work through the significant learning curve that the transition to reuse necessarily requires.

The only way an organization can get ahead of this game is to appoint a Manager of Component Development and assign that person to manage the transition. The new manager will need to choose his or her targets carefully. First there will be staff training and an evaluation of just what component resources exist. Usually it's a matter of identifying some components from outside sources and other components that will need to be developed internally. Typically, someone will propose that component x (Personnel Record Update, Part Order, Account, or some such) is frequently used and ought to be standardized for reuse. It's rarely a matter of simply taking a component that was developed for one application and using it in another application. Instead, at this point our Manager of Component Development will begin to acquire a team of component developers who will specialize in creating, testing, and maintaining components for reuse.

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有