Shulou(Shulou.com)06/03 Report--

This article mainly explains "how to select software". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to select software".

The demand for type selection comes from business demands.

Selection is always business-driven.

I believe that the business works well, there are no performance bottlenecks, no compliance requirements, no new requirements to develop, and we don't want to change frameworks or components.

When the business has real demands, such as data synchronization, business decoupling, peak cutting and valley filling, distributed transactions and other requirements, we need to investigate the corresponding solutions.

At this time, we often face a lot of software, which one should we choose and which one should we use? If there are team members who are familiar with previously used software, there is a high probability that they will choose it. After all, they have experience in using it and know how to solve problems.

But if the team members have not used it, faced with so much software at this time, and in the limited time, how on earth should we choose? Or what should be considered in software selection?

Select the research object

Before we start the selection, we need to know who we are going to investigate.

If you want to use message middleware, the objects you need to investigate may be RabbitMQ,RocketMQ,Kafka and so on.

There is a need for data synchronization, the objects that need to be investigated may be otter,Datax,canal and so on.

If you want to use rpc services, the research objects may be Dubbo, gRPC, Thrift and so on.

It is no longer one by one here. In fact, what we want to say is that first we need to know the subjects of the survey, and then we need to see what we are going to investigate.

The content of the survey

(1) system architecture

To a large extent, the system architecture of the software determines the properties that are difficult to change, such as simplicity or complexity, scalability, high availability and so on.

So when we choose the type, we need to focus on the software architecture.

There is usually a corresponding architecture diagram in the official website of the software, from which we can see the basic components of the software, the ease of the architecture and so on.

. For example, the following figure shows the architecture of RocketMQ, from which we can see that the basic components of RocketMQ are NameServer Cluster and Broker Cluster, and we can further see that the basic responsibilities of NameServer Cluster are Broker Discovery, and Broker Cluster can achieve high availability through data synchronization.

In addition to the system architecture, we may also need to pay attention to the implementation language of the software, and if customized development is needed in the future, whether the team members have the corresponding capabilities.

(2) the community situation of the software

The community situation of the software is a point that I focus on when choosing the software type.

An active community is very important for open source software, because the active community shows that there are many users of the software, and many users have a lot of practical experience to refer to and exchange, and there is a platform for communication when you encounter problems.

In short, an active community can help you solve many problems in the process of using the software.

So from which aspects can we consider the community situation of the software? This is mainly about the community considerations of open source software.

Personally, I usually look at when the software was last submitted, the number of issue and its responses, and further look at the contents of the software's mailing list.

(3) documentation

The documentation of the product is too important.

No matter how well the product is made, there is no documentation and no one will use it.

Detailed product documentation includes, but is not limited to, software architecture, user manuals, performance tests, FAQs, etc.

If you research the corresponding software and find that you haven't found the architecture diagram or user manual for a long time, you should consider whether you should use the software or not.

It may take some time to read through the product documentation, but it's worth the time. Reading through the product documentation can give you a general idea of the whole product, what features it has, what functions it has, how it performs, etc., which you can get a good idea of.

Spring documents are what I personally think are very good documents, it is no exaggeration to say that you can read through Spring documents, 80% of the Spring problems are not a problem for you.

In addition, it is best to read the official document, if it is foreign software, try to read English.

(4) other

Including but not limited to compliance, laws, ecological tools, etc., for example, if the open source software agreement used is GPL, according to the agreement, all secondary development should be open source again.

Feature or function verification

After investigating the product, we should have a general understanding of the software, and now we need to get back to business.

Whether the features or functions of the product can meet the needs of the business is the most important reason for our selection.

The general principle is that software that can meet the needs of the present and the foreseeable future is the most appropriate, because such software can meet the requirements without being too complex.

At this stage, we will generally enter the manual work stage, which requires a variety of tests, such as basic functional testing, high availability testing, performance testing and so on. During the testing process, the test should be scripted and automated as much as possible, because the process may be repeated many times, and no one wants to do it manually again and again.

The tests here generally need to draw a conclusion, that is, whether the current software can meet the various needs of the business.

There are generally a lot of problems encountered at this stage, and active communities and detailed documentation can help you solve these problems, and team members should accumulate process assets for software use at this stage as much as possible.

Application stage

In the application stage, there are different application ways according to the nature of the selected software.

If the software is a basic software such as a database, the pilot application will generally be carried out first, because the influence of the basic software is relatively large, and choosing the pilot application can not only avoid big risks, but also accumulate experience through practice. to facilitate follow-up comprehensive upgrades.

If the software is only used by the current business and has little impact, then you should be confident and direct, don't be pussy.

Help others

After software research, functional feature verification, and the official use of the project, it can be said that you are now a member of the software community, so don't forget to share your experience and help other software users. after all, it was the community that helped you solve the problem in the first place.

Thank you for your reading, the above is the content of "how to select software". After the study of this article, I believe you have a deeper understanding of how to select software, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.