Whether it is 不要重复造轮子, or 站在巨人的肩膀上, for software developers, the code reuse is one of the most basic principles.
Code reuse, could be DIY (dont repeat yourself), you may be using someone else's code, or open source projects, or other team components, services, or public modules within a team of others to achieve these multiplexing greatly It reduces development time and cost of the project.
But what is a highly efficient, third-party code using the correct posture it? In practical operation, there will be some cases lead to loss of control of the use of third-party code, such as the use by a number of third-party code, but fell into disrepair when the line looks like an accident related to third-party code can not quickly locate and solve problems .
This article is reading "clean code" Chapter VIII 边界（Boundaries）some thought when.
This article addresses: https://www.cnblogs.com/xybaby/p/11372846.html
This article will reuse the code is divided into two categories:
- One is the code outside the team, specifically refers to common components within third-party libraries, open source libraries, the company's other team, characterized in that such code often need to do more generic, large and comprehensive; user project team is just very difficult to influence their design or implement fundamental.
- The other is the code within the team that some common module, common components of the project team members on their own package, which is the core services for the project, more convenient consultations changes.
How to reuse third-party library code
Here multiplexing, is not limited to the code, but also for long-distance call services. In general, the project will research, select some open source, will use some of the services on the basis of services or cloud computing in the company, I think this is considered a multiplex.
Minimized, code reuse centralization
Third-party libraries often the pursuit of function (service) is universal, so that the code will be able to work in multiple environments to attract more users. And users often only need to meet the specific needs of part of the interface, for unwanted features (as well as the use is not recommended), but it is a burden for the project, but will not properly controlled risk.
For example redis, not only do the in-memory database, but also persistence; supports both single-deployment, but also through sentinel, cluster to provide high availability and horizontal scaling; but also support the pub-sub (and relatively new stream). But in our project, only to memory cache, and availability, scalability, there is not much demand.
In principle, the use of third-party libraries, to use an interface (service) as possible, which is packaged into a separate file (class module), not using another library directly elsewhere. By adapting, only need some of the features included, unwanted features (interfaces) do not exposed.
This has the advantage that the unified entrance, will focus on all third-party libraries to use a minimal amount of code inside, easy to maintain. It is also, hierarchical thinking, the business code and third-party libraries decoupling, easy alternative implementations.
learning tests
To an open source project to introduce its own business code, the need for scientific research and a complete test. Research, including but not limited to: the degree of overlap with the business needs, the maturity of the open source community, activity and so on. The tests should include the following aspects
- function test
- Performance Testing
- pressure test
- Failure Test
The first two are the most basic testing, mainly to determine whether the third-party library function, performance requirements of the business, as well as master the correct use posture. The latter two, the test points are often third-party libraries run as a separate service deployment when.
For testing purposes, we will have some test code, reference may project comes unittest, code sample, tutorial, benchmark. But the problem is that such a test code is often used to throw, this has led to
- If a problem occurs later, we need to continue to debug, to determine whether to issue library itself, or our use of gestures.
- After the tripartite local library upgrades, application upgrades can not follow, because there is no means to ensure that the new version of the library provides the same contract.
The second question I think many, many people will encounter when dependent on third-party libraries upgrade, you upgrade project is to follow along? Comparison of two extreme strategies I have encountered, one is always updated to the latest stable version of the third-party libraries; the other is basically not to upgrade, maintain their own a particular version.
learning testAble to solve the second problem:
We will test all organized into a set of unit tests for functional use of these tests cover our needs for features, performance, and stability are a lot of aspects. When the updated versions of third-party libraries, we just put the unit test rerun it again, you can determine whether or not the code of the new code provides the same contract, it can be upgraded relatively safe.
Not difficult to see the previous section, "third-party code uses centralized" is the learning testfoundation, we clearly know that those interfaces should be tested, if you want to extend the use of third-party libraries, can be easily increased, maintenance of the corresponding test.
How to re-use code within the team
Within the team is very encouraged code reuse, the more common way is to form a variety of common components. So, if the programmer A programmer using the module B provides the public a problem, then how to divide the responsibility?
If the code is open source, there is no doubt that users can only blame, but in the team, do not seem to be attributed solely to the user. Users of public assembly generally will not have to use a complete test, will think, "are a team, you should providers to ensure quality, fast and easy to use."
I think that the main responsibility for user accounts, users should use it to test if the provider has provided the appropriate unit tests, but also through, it can be used directly. Otherwise, you should add the corresponding test case, if not pass, you can find a provider consultation. For the common module, common components provider, should also be obliged to provide high coverage of unit tests, to develop a time because itself will test and no additional workload; and secondly a user's copies of official guarantee, but also enhance their influence in the team.