组件重用需要专人负责

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

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

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

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.

The component development team will need special skills and they need to be isolated from the contingencies that make it hard for people working on specific projects to take a long range perspective. The component development team is charged with building a library of reusable components. They will buy some and develop others, often starting with existing components but typically modifying them quite a bit. There are lots of issues these developers will face. Do you design components in the abstract (UML specifications) and then implement them in specific languages as COM+ or EJB components, or focus on implementations right from the start? How do you test components? Who is responsible for approving changes in the components and how do you control versions? Figuring out how to develop and manage component resources will take time.

Then, once the manager and the team feel that they are on top of that, they, or others, will need to train the actual application developers in the reuse of existing resources. This will also take time. Team managers will need to be educated to require and reward reuse rather than the rapid development of code. Individuals will need to be available to help developers design applications to take advantage of reuse. Its never the case that all of the components needed for an application can be reused. It would be impossibly inefficient to aim for such a thing. The key is recognizing what elements of an application can be handled by reusable components and what will require one time development.

I don't want to try to lay out the entire transition here. The key, however, is a Manager of Component Development, and a group that is focused on acquiring, creating, and maintaining reusable components. When I critique an organizations and find a dozen component development projects underway, each trying to figure out how to handle the various problems they face without any high-level help, I know the organization hasn't figured out what its doing yet. It has blundered into a major software transition without realizing it or planning for it. One or two teams, by shear hard work and individual brilliance may produce a great e-commerce application. But the company isn't ready to systematically duplicate that effort when it seeks to create another eBusiness application. Nor will it be ready to modify that and other applications as new technologies and eBusiness processes emerge in the years ahead.

On the other hand, when I visit organizations and see such individuals in place, I know the company has thought about what it is doing and has a transition plan. With a little luck, the organization with the manager is going to get better and better at systematically creating component-based applications. And, at the same time, I expect they will start reducing the time and cost of application development while simultaneously increasing the quality of the applications. They have a plan to take advantage of what the component transition really offers.