Dark age without using version-controlled - Version Control (1)

zhaozj2021-02-17  47

A common development method I am familiar with is not using the version-controlled development group, and multiple developers are responsible for the development of a software. Everyone has a copy of the entire software on their respective machines, and implements the encoding After each task is completed, the software is integrated into a machine through the text alignment tool to a machine. This article has proposed a typical problem related to several and version controls that appear in software development (but may not be comprehensive), which also need to be solved by version control, which is from the actual development process. Experience and summarize and organize. 1 Software code's consistent software development, maintenance, and upgrades are often a process of collaborating with many people. Different people have modified different parts of the same software, and this behavior sometimes occurs in relation to each other. Since the same software has copies on the machines of their respective developers, the entire code of the software is exposed to each developer, in principle, in principle, he has permission to change any part of the software without restrictions. And when they modified content belong to a common part, or when the part is required to be called by other people (the relationship between the software modules determine this situation often occurs), this modification is a cross-case. At this time, there is a possibility of inconsistencies of the code. For example, the modifier has also modified its call interface while changing a public function. If other people have not known this, and the original version of the original version is still called on the respective machines, there is an error when integration. . Another more serious situation is that the modifier decides to discard the original function and other new functions, but he does not delete the original function, even if the final integration may not be aware, if will This consistency error correction delays to the test phase, which will increase the difficulty of debugging, thereby reducing development efficiency. In order to always ensure the consistency of the code, a solution is that the modifier is required to inform the same group after each modification, or integrate the software at any time. But this will increase the burden of developers on the one hand, and on the other hand, the development efficiency of the software is also reduced. 2 Redundant problems of software content There is a copy on the machine's machine, and the same developer will reserve the software version at this machine at different periods, that is, there may be more than one machine. version. This is similar to a redundancy of one information. For different versions, the difference may sometimes be not very big. If it is unnecessary, the storage space is a secondary problem, then another problem may be more important. Over time, developers may become blurred in different versions of different versions of their machines, and even forget why they distinguish these versions, this will bring trouble to integration. Moreover, if you need to maintain multiple versions simultaneously, the changes to a version may need to be reflected to the rest of the versions, it is difficult to ensure that this process does not have an error. There is also a little, as a developer, sometimes even knowing that some version of the software on your machine may not be used again, he will not delete (shaksly what if you need to get something there), but usually will not no longer To maintain or see it, so long time, this "zombie" will "spread" on multiple machines. 3 The "transactional" of the software process For a version of the software, if the developer wants to add new features to it, or improving the original features, and worrying about the original operation of work. A common way is to retain existing versions and copy a new copy and modify it on a new copy. This is similar to a transaction process that when a series of operations are a transaction, if a deviation occurs in the middle, it is desired to recover the status before executing transactions.

And how do developers handle these two copies after completing the modification? It is a new copy to continue to develop, which will be used as the latest version; or add new changes to the original version, delete new copies. In any case, the following may occur: If the software runs normally, the redundancy mentioned in 2 will appear; when the version before deleting the version, there is a problem in the change, but it has not been resumed; the change is correct, When you join the original version, you may have a human error, causing the software to run an error; even if no one is wrong, this approach will add additional burden to the developer to a certain extent reduced development efficiency. Repeat the above process, there will be multiple similar copies, at which time, how to treat these different versions will be the problem that the developer needs to face. And if the debugging process, it is found that it is necessary to return to the previous version, even on the previous version ..., if you have to keep all the versions. 4 Software development "concurrency" is the same part of multiplayer modification during the development of many people, especially simultaneous modifications, sometimes inevitable. One of the people who have good programmed habits is that the necessary annotations are added to the source program of others to modify, modify, modify the reasons, and modify the date. However, the actual situation is that when modified content is very scattered or modified, the annotation is difficult to write, or the code is annotated to separate the crushing affects normal reading, or the notes cannot be described in detail. Moreover, this practice also increases the burden of developers: he needs to consider how to write comments while considering code logic; and the consistency of comments and code is also what he needs to pay attention to at any time, can't be negliged. Therefore, I think this measures are in actual development, and it is not necessary. It is unnecessary. In fact, the code itself (not the comment) is the most description, and the revised record should be placed outside of the code. somewhere. Moreover, regardless of whether it is simultaneous modification, it is necessary to consider the consistency problems mentioned, and it is necessary to perform manual differences and integration in time to form a unified new version. 5 Software code security Because the code is completely exposed to all developers, anyone can increase, delete, change. In addition to the inconsistency that will cause 1 mentioned, it is also hidden from a safe point of view, which is also the case for a long-term development of a self-owned property. Even in general project development, different personnel have different division of labor, allowing others to arbitrarily modify the code for module (equivalent to all personnel), which is always prone to problems. This is especially true for a common module, all people can modify, once modified, the wavefront is affected. 6 Software Integration In the integration of software, the general relatively reliable practice is to use text comparison tool assist completion. This measure has the following disadvantages: reliability, people in integration will affect the reliability of software, sometimes this error is difficult to detect, may compile no problem, but find problems during testing. This potential error found that the later it is, the more difficult to correct it. Efficiency, for pure manual integration, even if the person skilled, it takes time to complete, and some integration is just a two-segment code, this process can be fully mechanized. This can save time to make developers can focus on subsequent development tasks.

转载请注明原文地址:https://www.9cbs.com/read-29162.html

New Post(0)