Generally speaking, a client product will be released on different platforms and provide services for users. In the process of technical solution design, the API architecture provided by systems on multiple platforms is different, and the process and mechanism for realizing specific capabilities are also different. Some open source capabilities are also implemented in different styles. Technical scheme setting will exist multi – end scheme is not aligned.
Based on the same function point, it is determined that all relevant technical points need to be realized. If multi-end technical solutions are not aligned, the following five direct or indirect effects will exist.
-
Technical implementation is not unified: Because different platform features, ability is also different, such as the early only to a single platform for technical proposal, technical scheme of the design process, consider only the single side ability and the status quo, that treat other platform to realize the current solution will exist shall not apply to the case, then either for the current scheme of refactorings, Or implement a solution based on the characteristics of the platform, in which case the solution is not uniform.
-
High cost of collaboration: for the same function, different technical solutions will lead to different ways of implementation, and the r&d personnel may not be in the same team. Related documents need to be written multiple times, and related roles in the development process need to be explained at each end. Different dependency relationships will also lead to different development rhythms.
-
Different delivery rhythms: from functional requirements to specific development and testing, due to different technical schemes, different cost of demand assessment, different coordination, different implementation, different testing schemes, different final delivery rhythms and different input resources. Of course, there will also be inconsistent delivery rhythm if the scheme is the same. From the perspective of the same resource input, the probability of inconsistent delivery rhythm will be higher if the multi-end technical scheme is different.
-
Server-side docking high cost: in general, an APP will products in the same business docking a service, and if the client’s technical solution is not unified, is equivalent to a service at this moment, in different editions of the adaptation to a functional differentiation, mainly embodied in three aspects, 1) the same function of the communication protocol is different, different analytical and logical processing; 2) If the same function supports different versions, the server needs to adapt different versions of the same function. 3) Different platforms with the same function need customized RESEARCH and development and joint adjustment. Because of different technical schemes, when there is an impact on the realization of the server side, the server side is equivalent to realizing two sets of logic, requiring separate research and development and joint adjustment.
-
High maintenance cost: For the same function, different technical solutions. When the online problem is of the same type, different teams may locate the problem, and the promotion of function upgrade is coordinated by multiple teams. Because the logic behind the same thing is not aligned, the cost of communication between team members will also increase. At the same time, for team turnover, the archaeological cost of business details will also be increased, and the reuse cost of personnel will be lower.
And when the technical scheme multi-end alignment, the above impact, should have a relatively large improvement, objectively speaking to achieve all the logic of the code unified, it is not realistic requirements. At least the technical solution of the whole function module should be unified, the implementation process should be unified, the corresponding implementation process interface definition is similar, can be differentiated expansion, communication protocol is the same, also can be differentiated expansion. To sum up, the unification of multi-terminal technical solutions does not require consistency in internal implementation details, but should be the same, similar, differentiated, extensible and customized as far as possible for the related capabilities of external collaboration.
Similarly, data uploading, business configuration, cloud control and other server-side related data processing should also be aligned with multi-terminal solutions, and the logic of the server can also be reused to achieve the purpose of improving efficiency.
Other reference
-
[Thinking about the process of architecture Optimization] Quality over efficiency
-
Avoid random trial and error
-
[Thinking on the process of architecture optimization] Continuous technological innovation
-
[Thinking about the process of architecture Optimization] the value of specifications in R&D work
-
Summary of componentization benefits of R&D process
-
[Thinking about the process of architecture optimization] It is better to determine things by people than by people
-
Five key points of CR
-
Three dimensions of technical solution evaluation
-
The meaning of communication
-
[Thinking on the process of architecture optimization] Platform ecology is given priority
-
[Thinking on the process of architecture optimization] The sorting principle of technical requirements
-
The basic principles of active communication
-
[Thinking about the process of architecture optimization] The difference between architecture optimization and function iteration
-
[Thinking about the process of architecture optimization] Assume that the data is not believable
-
[Thinking about the process of architecture optimization] The value of the review
\
\