Object-oriented misunderstanding and Technical Selection misunderstanding

 

Object-oriented misunderstanding and Technical Selection misunderstanding

Wu Yu

Taiyan Network Studio

 

During the break, I chatted with colleagues in the organization about the Technology Applied in the company's programs. He said that we should use more off-the-shelf technologies instead of self-developed ones. He gave an example. Our company has a decoding program that converts the received fix protocol (a financial data protocol) into the relevant struct, if you use the "CIN> ndata" method, it will be much more convenient. Also, if you use the ACE network communication function, the development speed will be much faster, ACE also provides more interfaces.

I thought about the sub-lines of his speech and thought he had a lot to gain from object-oriented and third-party tools. He's right. At least it sounds reasonable. But just as any truth has its scope, he noticed the universality of things, but did not consider the particularity, complexity and sustainability of things.

In terms of the fix protocol, it is more similar to the XML protocol. I have seen a lot of XML parsers, but I have never seen any of them use the "CIN> ndata" Method for parsing. The simplest reason is that the efficiency is too low. Objects are often used to increase development speed at the expense of efficiency. However, financial data is always required to be timely and accurate, and efficiency is almost the first. In addition, the use of some object-oriented methods, especially virtual functions, will greatly increase the complexity of debugging. He may have done a lot of development work, but I believe that his debugging technology will not be very good. At least he has never encountered the great troubles brought to the debugging work due to not careful development.

There is a saying that "simple is the best" about development. However, my understanding is essentially different from my understanding. What I understand is simple: Technology and complexity, and sustainability. The simplicity of his point is, in fact, the current development is easier and better. As for the future, it is not his responsibility.

 

We have discussed whether to use ACE once. Ace is suitable for large-scale network development, especially the tens of thousands of concurrent online servers. Our program simply uses network communication for sending and receiving, with no more than 20 sockets. Not to mention the complexity of the introduction. To put it simple, it is very easy to find a socket programmer ~ 5 K, and the program will be easy to locate. However, if Ace is used, if the original programmer leaves and finds another one, the cost will be much higher, and the related debugging technology will be different. In addition, if there is a bottleneck in ACE, or our requirements exceed what Ace can provide, it is difficult to find related personnel for how to scale. The off-the-shelf lesson is that we use the TimesTen database. When developing a low data volume, its throughput is very timely, but when the data volume reaches a certain level, even TimesTen's technical support staff do not know how to meet our needs. Think about it. We spent so much money to purchase the TimesTen Database Service and did so much development, but we had to abandon it at the end. What is this for the company?

All tools are intended for use. We also encourage the use of advanced and convenient tools. However, developers should exercise caution when using any tool or technology. You must know that the technical staff must solve the development problem, but the company must also solve the operation problem. From another perspective, things may be different.