Is your updated code "robust?

Submitted by meCodeAre you ready?In fact, this is an old saying, and it is never the first time for myself. The reason may be that this phenomenon is very interesting! We can see many of them as oneProgramPersonnel must have detailed qualities.

I will analyze my mistakes again. I need to handle the following: Data table modification> Stored Procedure adjustment> data access layer adjustment> page call Modification . Such requirements should be met frequently and modified in order. The debugging page is used to check whether the modification is correct. Input, execute, and return the expected results. OK. The modification is successful! Update all the modifications to the Code server in sequence again. version comparison before checking in is an essential key step. The reason is that if the code is not changed due to laziness, if someone mistakenly overwrites the code uploaded by someone else, I believe that it will take a long time for someone to come to the door to "Debt Collection". I believe everyone has had this experience as a programmer, but few people enjoy it ......

But can this ensure the quality of the submitted code? What other "traps" can cause us to neglect and thus cause the upload of "unhealthy" code?

(1) over-confidence in your code: This article is easy to understand and is also the culprit that most easily leads to the "problem" code check-in. The reason for this is that it is not only self-confidence, but also lazy, especially when there is a lot of content to deal with, it is easy not to follow the rule, which implies some potential problems. In the general development process, there may not be too much impact, and timely detection and modification can be made. However, if you encounter these potential problems in the later stage of the project, the cost to be compensated can be hard to be measured. Therefore, the individual's attitude must be well-rounded.

(2) code branch correctness: The simpler the function, the less likely it will be to have problems. This may be what countless masters say: "simplicity is king! In the past, it was easy to fall into the trap of Compound Functions and think that "simple functions lack technical skills ......", A superficial understanding. However, I believe many people will think this way. Therefore, for these compound functional functions, our testing is not as simple as 1 + 1 = 2, sometimes people may be overwhelmed, because a slight change may make the execution of one of the channels correct, but it may also have blocked the originally correct path of a condition branch, this may cause potential bugs. What should we do? On the one hand, we need to maintain the functional uniqueness of our functions as much as possible. If there are special needs, we must ensure that all the conditional paths are tested for actual calls to ensure the availability of the entire function.

(3) adaptability to special application situations: This article is somewhat similar to the second one, but slightly different. I believe there will be some unconventional design parts in any system, which will also involve some functional modules that seem "weird, there may be some handler functions that are hard to understand. In this case, we call it a special application scenario. Once such a function is modified, we must be cautious and cautious, at the same time, we must strictly ensure that the comments must be modified. The reason for emphasizing the importance of annotations is that, for many common functions, after adjustment, it is easy to be understood by others. It is good to add annotations, but if there is no annotation, however, for such a special application scenario, it may be another day, Recalling the experience that I had made modifications because I had read-only knowledge of local code and then caused system paralysis, annotations not only help others better understand your code, but also remind you of what you have done at a given moment.

(4) logic correctness of compound functions: The nested branch of the branch has a more composite functional function. If you can, please stay away from this implementation method. If not, therefore, we need to work hard on several things to ensure efficient and correct modification. First, the branches at the outermost layer are divided by line breaks or comments, and then each branch is checked. The logic correctness is emphasized here, the reason is that the nested logic often exceeded the "fast path" of our brain. What is "fast path "? For some common and step-limited functions, we can quickly think about the correctness through the brain, but if there are too many steps or complicated logic, it will obviously increase the burden of thinking, you can distribute the pressure in the form of white paper or charts, but it seems that most people will not do this, and they will experience the pain of being brave many times ...... At this time, please hold down your patience and divide them layer by layer. Try to use the fast path to judge the correctness of the logic. On the surface, it may waste some time, but from the actual effect, what you get is high efficiency and high quality.

(5) blocked exceptions: We all like to add try-catch Exception Handling. Many project teams also emphasize that such exception handling must be added, but most of the time, we only get the added exceptions (or the catch mode that rarely distinguishes exceptions), so we can write a maximum of logs, and then it will be gone. As a result, the user did not respond after the operation, and the program was certainly not correctly executed, but it seemed that there was no error. Later, it was found that there was an exception, however, after being captured by us, we didn't process it. So although the function didn't return the correct result, the returned result didn't cause the system to crash, so we had the previous scene, these problems are not easy to find, but they also remind you that if you want to handle exceptions, You need to subscribe, record, and handle them. Otherwise, you will leave a chance for the bug.

I have always wanted to write something to remind myself about code updates. If there are some omissions, please make a lot of bricks ~