A case in point
Let's start with a classic case: programmer small a long time in the A project development coding work, suddenly the same department under the B project emergency shortage, small A was transferred to the B project development, small a read many rounds of "a variety of" project documents, finally opened the idea, the results found that a bunch of pom files burst red, after the investigation found that their own local configuration of the A project team intranet remote warehouse address is missing a lot of B project code dependencies, ask the West to run to the extranet dependency complement, to solve the B project dependency issues; finally entered the coding stage, the results in the face of the use of Es problem, the B project in the version of the client and the A project is not the same, which is about Es sniffing, timeout mechanism, DSL writing style, API call is also a set of style and interface layer encapsulated by B project alone, so small a and spend time to look at the structure of the return object, encapsulation logic, API parameter call logic in order to achieve a better use of the effect ......
Although the above process we are not surprised, the team to the project as a unit, fragmentation is serious, although the same R & D department, but a change of project is like a change of work, and even under the same project, different modules, functional groups between the code variety, which is too common, so common behind the problem is:
- Lack of harmonized standards (documentation standards), leading to increased communication costs
- Lack of centralized technical support (stable and comprehensive private warehouse, R&D environment), high R&D preparation costs
- Ineffective learning (need to learn multiple artificially created external forms of the same technical point) Invisible consumption
Although there are various functions, products and projects, there are actually more technical overlaps, and these overlaps are consumed in the above three points every time, forming invisible cost waste and leading to low efficiency and quality.
The concept of "technology assets"
In fact, often think about a question, a technical team, or an enterprise's R & D department, what is its core assets, the answer may be a lot, such as team talent, team trust, team tacit understanding ...... and so on, but in fact, these are more virtual things, undeniable that these contents are really important, but it is a kind of "Soft power", not "assets". The so-called "assets" is after precipitation, can be directly reused to essentially reduce the production cost of "physical".
The R&D department and technical team in an enterprise is actually more of a production department in a software/internet company, which is like a production workshop in a real industry. Production workshop can be updated through the lathe, equipment to improve productivity, here the lathe, equipment, that is, "assets", then the R & D department of the "assets" analogous to come out, is the departmental level of technical standards, tools.
The meaning of "technology assets"
efficiency
In fact, most of the so-called "technological leadership", "technological innovation" is the essence of sewing, the real high technology or technology research is ultimately in the hands of a few people and enterprises, can quickly respond to and support the market is most of the enterprise research and development of the Theme. More "Musk" thinking, do not care about low or not low, can quickly respond to the market, quickly support the finished product is the hard truth.
- Building Block Patchwork: Quickly Building the Foundation for Project Development
- Standing for efficiency, rapidly building technical solutions through complete technical assets to accumulateWood splicing principleBeing able to quickly complete the construction and reuse of the main framework, supported by the complete technology flow, it is easier to focus the energy and resources to the core business and improve competitiveness.
- Public abstraction: reducing the fragmentation of the problem
- Just like the programming principle, extracting the commonly used and generalized parts and unifying them into one location, calling them directly when relevant capabilities are needed, and adjusting them in one place and responding to them everywhere when they need to be adjusted, can dramatically improve the efficiency of maintenance.
mass (in physics)
Technical assets are physical "experience" extracted from many rounds of projects and real-world operations, and are certified for certainty and stability. The same problems have already been solved and avoided at the technical asset level, and will not be reproduced in new projects.
Compared to hard-coding a new project, which relies on the experience and technical skills of the personnel, "building block" based code assembly relies on more specific and quantitative technical components, and the quality is more controllable.
(manufacturing, production etc) costs
Considered from a cost perspective, the presence of technology assets can significantly reduce hidden costs such as human efficiency and communication.
- Reducing the impact of "personal factors" and reducing ineffective learning time
- For team efficiency, a unified technology library, technology components can form an effective technical isolation zone, the overall neat and tidy, the same basic technical points using a unified documentation and use of the norms, saving a lot of secondary learning costs.
- Avoid "noise" interference in the process of information transfer and reduce communication costs.
- The stabilization of basic technology can also reduce the communication cost of design and information transfer, avoiding the situation that business personnel raise business issues while technical personnel answer technical issues. At the same time in the R & D communication, you can unify the technical terms and version of the terminology to reduce the time wasted due to different information terminology and repeated confirmation.
- Lowering personal "barriers" to improve human effectiveness
- The stability of the basic technology can ensure that when the project handover and personnel mobility, the maximum effort to maintain the stability of the project code, will not be due to the introduction of certain technical points and the effect of personnel forced binding. A department under the R & D familiar with the technical assets, only need to understand the different business, you can seamlessly switch any project at any time, or even multi-tasking.
"Technology asset" building
Technical assets stand for no more than two categories from a coding R&D perspective, corresponding at the coding level to bipartite libraries and at the architectural level to technical pedestals.
These two correspond to the generic and support domains I talked about in the domain-driven section. In fact, regardless of whether or not a domain driver is used, a unified bipartite library and base is a necessity for a team, and must be there is the first element;
Secondly, the construction of granularity, as to what granularity, depending on the size of the team and project requirements, but not overly ambitious, a specific business system to do business-oriented enterprises or departments but to build a general "data center" tool is overly ambitious, system-level development, and even server groups do not have! scale, a stable and unified two-party library, based on the SDK package to build the project is enough, do not do it for the sake of doing.
The last is the implementation of the strength, since the effort to build, we must "cut through the mess", a drum to replace the whole amount of reconfiguration or gradual reconfiguration and replacement, do not use "schedule", "progress", "wait for new projects to start using" and other reasons to let the completed technology assets in an idle state, because technology assets are needed to drive the evolution through the use. Do not use "schedule", "progress", "wait for a new project to start using" and other reasons to let the completed technology assets in an idle state, because technology assets need to be used to drive the evolution. Building without using is also "doing for the sake of doing".
Construction of a second-party repository
The concept of a bipartite repository
The concept of a bipartite library comes from Ali's developer's manual and is broadly defined as follows:
| name (of a thing) | hidden meaning | Level of affiliation |
| single repository | Interdependencies of modules in the current project project are dependencies in this project. For example, in a multi-module project, one module depends on one or more other modules in the same project. | project level |
| bipartite pool | In-house dependency libraries, which generally refers to other projects within the company that release public jar packages. | Corporate or departmental level |
| tripartite pool | Open source libraries from organizations outside the company, dependencies from third parties such as apache, google, etc. released jar packages. | Internet Open Source Library |
By definition, the concept of bipartite repositories is similar to what I have previously described in thedomain-drivenThe generic domains mentioned in the article overlap.
Principles and ideas for the development of a bipartite library
First of all, it is necessary to establish a perfect and stable intranet repository to store the approved three-party library dependency packages and self-developed library packages, R & D internal are based on this warehouse.
Back-end Java system, for example, the most classic manifestation of the two-party library is spring-starter, the construction of technical assets is mainly to build a stable intranet maven warehouse, maven intranet warehouse mainly contains three parts:
- Original tripartite library information: common dependencies in the public network, as the most basic material for development
- The second open content of the existing tripartite library: according to the internal need to transform the package based on the tripartite library, to form their own internal use of the norms and standards
- Source code development content: self-developed components, packages, tools.
Original Tripartite Library
For the three-party library, there is no other operation, just need to establish a perfect public maven to intranet maven channel can be, for the three-party library, need to do is to ensure that the update strategy, can update the internal maven library in a timely manner in the dependency packages, to ensure that in the development of the need to use the three-party library do not need to look for laborious; In addition in the channel synchronization, to be a certain amount of security filtering, for the Security vulnerabilities that have occurred, serious problems with the dependencies, to establish a sound and timely interception and update strategy, from the beginning of the project to reduce the cost of modifying security issues.
II. Contents of the second opening
The content of the second opening is mainly based on the secondary development of the three-party library or other open-source projects, including: content integration, functionality expansion, content transformation, repair of known issues; for example, based on the characteristics of their own departmental projects, the integration of commonly used dependencies, the construction of the back-end project scaffolding. According to their own business requirements, the flowable process processing encapsulation overlay and so on.
It should be noted that, because outside the official mixed with personal will of the code, more or less will increase the complexity of some information, so for the two open libraries, the need to support the perfect documentation and instructions for use, documentation and instructions for use is part of the development of two-party libraries.
Source Code Development
Based on the results of enterprise or team self-research, to ensure its security and privacy, only allows internal use, is the core competitiveness of the team's technology; here the source code development does not necessarily mean that it is from 0 to 1 of the development results of certain two open components, as long as it is on top of some of the foundation for innovative, unique transformation can also be categorized as such.
The scope of the two-party library involved is generally:
| subassemblies | descriptive |
| Common Object Handling Tools | For example, file upload and download, file manipulation, time and date processing, string processing, cache management tools, thread management tools, collections, array processing tools, protocol communication and other Util class tools. |
| Unified security filtering mechanism | Unified AOP entry, for all kinds of injection, pass-through and other content interception, parameter checksum rules annotations and other security issues processing mechanism |
| Adaptation of various three-way components | Adaptation starter for third-party components of various databases, repositories, message pipelines, and their related operations, e.g., unified compatibility of SQL dialects for Mybatis. |
| Code Scaffolding | Unified project parent, unified centralized control of three-way dependencies in the project |
| Log Monitoring Mechanism | Output mechanism for various types of monitoring logs and system operations |
| …… | …… |
Technical base construction
Here called the technology base is also some "bragging" suspicion, in fact, can also be understood as a "heavy" two-sided library, to be frank, is now a lot of enterprises blowing the self-research XXX platform, XXX engine, is a kind of adaptable multi-scenarios, multi-applications, integration projects, the use of heavy-duty technology components. It is a heavy-duty technical component that can be adapted to multiple scenarios, applications and integration projects.
Principles of technology base construction
Positioning and basic logic of the base
Here the technology base is not a platform or business system, its positioning is still essentially a component, only the scope of application is broader, the system is more complete.
It should be a technical platform that saves development costs, and its underlying logic is for larger, more complex systemsProviding capacity supportWhen you use a library, you can't use it out-of-the-box like a two-party library. In the face of different users or scenarios, the project code needs to be adapted and developed in a certain way. For example, the development of a set of front-end low-code platform to provide "drag and drop" in the form of eliminating repetitive front-end code writing, to simplify the realization of the technical capabilities; or develop a set of lightweight scheduling response, with simple metadata definitions to support most scenarios, the system and the exchange of third-party data docking.
There are two main development principles.
- Be oriented to technical abstraction development, not business-oriented development
- "Standing on the shoulders of giants."
Technical Abstraction Oriented Development
The technology base should be oriented towards abstract content design rather than concrete business design. The concrete implementation is that it is oriented towards data structure and capability logic design rather than specific system functionality design.
The technology base is implemented for effective aggregation at the architectural level, and can be used as the "building blocks" of the architecture, so it has to provide a higher level of abstraction in order to have a wider scope of application. Consistent with its positioning, the goal is to provide capabilities, not to cater to a particular project or product, which must be controlled in the design and evolution.
"Standing on the shoulders of giants."
To put it bluntly, we should try to build on stable versions of open source components as much as possible, and "stand on the shoulders of giants". Be sure to avoid the common R&D problem of hand-rubbing nukes.
First of all, the reason for the construction of a clear technical base is to reduce technical variability and reduce development costs, so be sure not to but everything a lot of investment in production and research capabilities to start from scratch, the original in order to reduce the cost of things, but instead of an increase in costs, is a kind of cart before the horse; second is a more realistic problem, do not overly trust their own capabilities, this general-purpose technical base, more or less to involve the IO, compilation principles and other deeper technical points, the direct use of mature open source projects for upper packaging, or integration of related components is a wise choice.
The need for a technology base
In fact, for most companies and departments, a well-established bipartite repository is sufficient, and there is no need to build a technical base.
Even if the use of mature open-source project two open, it is extremely resource-consuming investment, and it is easy to go into an uncontrollable situation in the development process, and ultimately become a "toy demo" and report PPT material. Energy and resources are also invested in the project, but not much profit, pure research and development staff of their own carnival.
The following factors are to be considered before deciding to build a technology base:
- Whether the volume and size of the project warrants the use of a technology pedestal
- Ability to abstract the generic content of multiple production lines and projects
- Can the use of technology bases reduce costs
If a department or enterprise, the project is mostly monolithic or special area of customized content, and there is no whole establishment of the framework planning, then there is no need to build and use technology assets; in addition, multiple project groups, whether the product is more common between the claims, such as the ETL process, orchestration of the response, heavy page development, large-scale use of algorithmic models, and so on; if the construction and use of the technology base after the construction and use of technology, and can not obviously reduce the If the construction and use of the technology base does not significantly reduce the development cost, but only changes in the development process or development form and looks like a reduction in development costs, then the decision should be made carefully.
The evolution of "technology assets"
Like projects, technology assets move forward iteratively, requiring validation and feedback from the project, which is then continually updated and iterated, and then in turn supports the project.
In terms of construction, the development of technology assets needs to be divided into a stable pool and a development pool. The stable pool stores the released version of the content that can be used with confidence and is well adapted; the second development pool is the "beta" version that needs to be designed and developed by continuously receiving the needs and feedback from different projects and different development tasks;
For example, a project needs to report to the main system after the start of the various subsystems to run, and another project needs to add a new system operation status page, then you need to combine the similar requirements of multiple systems, design and develop a system monitoring starter released for use, due to factors such as the project cycle, you can first step to complete the project, and then the formation of technical components to consider whether to iterate on the replacement or not, and only subsequent to the opening of a new project to use this starter. And only use this starter in the subsequent opening of a new project; or in the process of use, found that the function of a component package there are problems and risks, such as security issues, etc., you can be for the component package for the reinforcement of the transformation, and then release a new version and global statement of replacement.