Reflections on software multiplexing

zhaozj2021-02-17  81

Since I have recently launched a maintenance of ActiveX's products, I have the opportunity to regain more than one year of COM technology, and I also have the opportunity to re-examine the evidence of technology, and some of them, this The feeling seems to go back to the road to see the road they have passed. Different, losing his life road, the success or failure is lost; while the development of the technology still follows the rules of the survival of the fittest, but the boundaries between the advantages and disadvantages seem to be not so obvious, but some make people confuse. For example, multiplexing.

Software reuse has always been considered an important means of improving software engineering, and people expect to improve productivity through multiplexing previous code or components, improve product quality. Software reuse is generally divided into source level multiplexing and binary multiplexing. For source level multiplexing, many important design paradigms have now been developed from various different aspects. For example, OO is encapsulated by a function of data and processing data to reach the multiplex, and GP is separated by separating data structures and processing between the methods of processing these structures and the type of data, to make data structures and methods to be multiplexed. For the reuse of binary grade, there are currently a very mature component model, such as COM, CORBA, etc. Moreover, there are also some very good guidance software multiplexed, such as Design Patterns. These are all indicated that the software multiplexing should be doubtful is a very important idea in software design. Each of us should fully consider the reuse of our code when writing code. This is always the creed of my follow. One. But now I am a little confused.

Still first talk about my recent work. The product I took over was a set of ActiveX Controls written in a few years ago (the earliest annotations in the code can be traced back to the 1997 year. When I saw this bank, I first thought that "my 1997" is called "My 1997". Songs), due to the long history, except for the product's manual, there is no documentation about the code, I can only rely on the source of the source and zero broken annotations to figure out the intentions. I have to admit that although many different people have made of various reasons for various reasons, the overall structure of the code is still very good.

In order to maximize the reuse requirements, these seniors develop a set of their own ActiveX Control libraries from ATL2.1, which is responsible for handling Control's properties, interfaces, events, and messages. The set library simplifies the complexity of the ATL window programming, fixes some errors existing in ATL2.1 at the time, this library should be very easy to use (I just guess, because most of them didn't understand L ). The logic and UI based on the BLIB library are separate, and most of the logical errors do not need to change the library code.

However, the BLIB library is now maintained, but it seems not easy (it may be limited in my level). In my opinion, now it has several obvious shortcomings:

1. Because it is based on the development of early ATL2.1, the current popular programming environment (VC6 or VC.NET) no longer supports ATL2.1, so the BLIB library has to bring the source code of ATL2.1. This looks a bit behind. At the same time, all products based on this library cannot be easily migrated to a higher version of ATL, so they cannot benefit from the upgrade of ATL. (Even if it is already ATL7.0, I have to find a way to engage in the help documentation of ATL2.1.)

2. Because of the need to support multiplexing, the BLIB library has expanded almost important parts of each ATL. Due to lack of corresponding documents, this makes reading, maintaining these code a more difficult thing, many times, the extension code looks like only some subtle differences in the code in ATL, making people difficult to understand. 3. In fact, the BLIB library has not been real multiplexed. The original intention of this library is perhaps in order to build this library for future products. However, in the process of establishing the ActiveX Control product, Microsoft launched ATL3.0 in 1998, which makes this library a bit behind. And developed the predecessors of this library or left the company, or joined other projects, no one came to migrate. The length of the sky has not been used for a long time, and there is no BLIB library.

In the process of reading and maintaining these codes, I can't help but always think, Joshua Kerievsky said that the design mode will cause excessive design in the early stations of the design. So, will it cause excessive design when designing too much? Or, this situation I have encountered is not an excessive design? In my opinion, if you don't consider the reuse, for such ActiveX Control, there is no need to develop a set of libraries, just need to use the ATL itself. In this way, it will not be a problem to a higher version of ATL migration. The maintenance cost of the BLIB library is very high (my personal feeling), if it is based on it, it makes sense. However, it is just a product, this cost is not too high.

Therefore, I am a little confused. The reuse of the code has always been considered by me to be considered in the design coding process. Therefore, these predecessors are also a quite reasonable practice based on multiplexing considerations in the development of their products. I will choose to write a library as a subsequent product. (Maybe there And the force is less than L). However, developing a library will inevitably increase the maintenance difficulty of code, let alone this library is based on another regularly upgraded library. From a maintor's point of view, I would rather code less than some reuse, and more easily. After all, I am more concerned about how to quickly understand the logic in the program, find out the error. This is a pair of contradictions, to be or not to be, how should we go? We can't make a sure how tomorrow will, we write the code today, will it be used in other places tomorrow. So how do we determine the importance of multiplexing for our code? Refactoring to patterns can reduce excessive design caused by Design Patterns, then have a method such as refactoring to reusable, reduce excessive design caused by multiplexing?

The above record is some of my recent fans, welcome to discuss and shoot brick J

转载请注明原文地址:https://www.9cbs.com/read-31507.html

New Post(0)