Walk out of the software workshop (19th)

19. One man's battle

This morning, a netizen sent me a message: he is an old product version maintenance developer. When he applied for this company, the product was sold.4Years later. The original developers are already here4The loss keeps dropping in the middle of the year. Here he is, the task is to maintain this software, and this is maintained by him.Code, YesBugChangeBug.

Although this software is sold4But I really don't know how to stick to it.4Year. When he took over, he was stillBugHundreds of outputs. The Code has no documentation, no comments, and no table structure descriptions. The code is inexplicable. A piece of code is often inserted. It is obvious that the customer has reported an error. It is targeted to solve the error temporarily, but it is to fix the error, the code is not described. So he did not dare to do anything about it, but he had to modify his demands and he had to stick to his head. He does not know whether the Code he modified will cause other problems. He can only make sure that there are no problems. The boss is still playing products very mature everywhere, and he is scared every day, afraid that this set of code does not know the day when the crash, the error is not enough, it can only be oneselfKDrop. He can imagine the boss's anger: You can't make any decisions about such stable products.

He hopes that I can help him develop his ideas.

I thought about the opportunity to develop new products or projects.ProgramThe clerk was lucky because there was no historical burden and he painted white paper. Nowadays, most software companies use a set of already-existing code to modify and customize the code to create new projects. There is little chance to write the first line of code from the beginning of a new project.

There are many situations in which the existing code can be modified to adapt to the new project of the new customer. Most of them do not have documents, and there is no comment for modification customization. The customer makes a call to talk about a requirement. When the technology is met, the customer is allowed to modify it. After the modification, the customer is covered with no requirement management or version management at all. Such code is not a specific set of customized code for a specific customer, but should be updated to other customers. It is very likely that this customer has made an error when using other features. It is a common phenomenon to press the hoist to initiate a crash.

I asked him: Do you have comments on the code you have changed?

He replied: No. You can remember all the changes you made. Even if you forget, you can remember the code you wrote. So there is no write.

I asked him: What should I do if he leaves later?

He replied: it is also a bad product. What other people can do, so he cannot manage it. He should let this bad code die as soon as possible, saving others from harm.

I asked him: What is the purpose of your help?

He replied: during my work period, it should not crash.

I'm speechless.

I have had in-depth discussions with many developers about the maintenance of old systems.

Many developers believe that an old system must be well maintained and have the following key factors: responsibility, documentation, detailed requirement analysis before design, requirement management, andOoProgramming, special testers are required. If you don't have this, simply reinvent it. If you don't want it, run it quickly. Otherwise, it's easy to be a zombie.

But in reality, it is often the only person who maintains the old system. This is a conflict. The development of a software often1-2The sales, implementation, and upgrade cycle are long.4-8Year. However, every boss seems to think that the software has been developed and the repair and supplement operations are all small functions, so an old system maintenance personnelOK. I don't know how to draw pictures on white paper, but it's hard to get an eye on Jackie Chan in other people's paintings.

When I was managing and operating enterprises, I found that the problems encountered were similar to those faced by maintaining the old system. There is a lack of resources. There is a conflict of interests between departments, and the quality of people cannot be raised. Employees and bosses play games of cats and mice with each other, constantly balancing salaries and labor. The customer's impression of the forces behind the history of some companies cannot be changed, nor can it be overturned, but the company still needs to develop and improve, it is necessary to focus on the target and continue to move forward as a leader with sand, dry, thirst, and hunger like a camel, and to clear all kinds of obstacles. If they cannot eradicate them, they should find a way to balance and mitigate them, sometimes concession, sometimes detour, sometimes strong, and then suddenly make decisions, the company continues to operate.

Therefore, to maintain the old system, we must continue to inherit the burden, analyze problems carefully, clarify our ideas, and make continuous improvements, just like the operating companies, so that we can gradually move from a vicious circle to a virtuous circle, in order to turn a set of bad code into sustainable maintenance code.

I gave him eight suggestions for writing code:

1. Check the input data. You can see a lot of code that is inserted in the crosstab chart. This is because of the input vulnerability, which finally leads to subsequent data processing errors. Therefore, the previous programmer did not intercept the source, and he blocked the vulnerability in the last outbreak. NowWindowsThe program is triggered by message events. I still cannot tell where the process will go. He has blocked this port, and other unexpected triggers. Can he block it? Therefore, verify the input data and write the detailed verification in the first step of the Save button. In addition, this code should be written as a function, rather than a large amount of flow, saving the Code complexity and causing the program to crash quickly.

Ii. Add more requirements in the future and write them as functions. LargeIf .. elseJudge, and separate the code segment into another function.

3. Add functions later and try not to trigger linkage. That is to say, it is best to save a single table. Even for documents in the master-slave structure, if the customer does not strongly disagree, it is also made to save the master table first and then input the Details table. In addition, you must enter a separate window for the detail table, which simplifies the functions and code. For example, if you query a document, do not use the master abstract above. The details are linked below. This affects performance. Because the speed may be slow, the user will click multiple times in a row, and the trigger event will be messy, and all the inexplicable errors will occur. Double-click the master abstract to display details in a separate window.

4. You will write code later to separate the functional code for special and normal services. It's as if you are walking. If someone gives you a nap, you will feel uncomfortable.

5. Existing functions: Hide unused functions in a humble position. There will be fewer and fewer users. At that time, the server will be hidden and will not be triggered.

6. In fact, many times, you think the program is very bad and the jar is broken because the code layout of the programmers may be different from that of you. You like two spaces. If you like three spaces, you will feel uncomfortable. People like{At the end, you like to open a new line. You can use the code formatting tool to re-arrange the version. I have seen a lot of complaints about the maintenance staff of the Old Code.M,N,S,Button1And so on, but in fact you read and understand the code, these do not make you understand the ambiguity or do not understand, but you are not happy. If you understand this unpleasant situation, you will be calm, and the code modification will be smoother. The more angry you get with the old code, the more messy your work will be. (Here, I believe many programmers will smile. The real root cause is that the failure to maintain the old system is just an excuse, and may wish the boss to think that his work is very complicated and his salary increase ). What is really harmful is global variables and large-flow code. Therefore, writing code should strictly avoid these two bad factors.

VII. Modify the requirement orBugIn this case, you need to modify the changes in a centralized manner according to the module, instead of selecting the correct ones first. If it is not easy to change, you can change the changes at the end. You can modify the configuration according to the module. You will consider all these requirements andBugInstead of the window filling.

8. I used to communicate with many maintenance developers. They all think that a software has no documentation and no comments, so it cannot be maintained. But it is true that many software does not have any design documents, even help instructions, and the code is not annotated. These software come from their own hands. That is to say, they complain that there is no document, no comments, no code comments, and no idea who is waiting for them to do so. I asked them what documents they really need to maintain a software better and better, from a set of bad code to a set of good gradual code? They said they wanted to explain the table structure and detailed functional design books. The table structure is easy to say. You can sort it out and the detailed design instruction is not easy to come out.

I have also maintained other people's code, and I have not provided any documentation or even operation help, not to mention the detailed design instruction and table structure. Of course, the Code has no comments. I have not sorted out the table structure description. Thanks to this person, he liked the database and wrote a lot of views and stored procedures. There is a link between tables in the view and a Chinese name for the important fields in each table. In this way, I do not need to explain the table structure. Because the table structure description not only needs to describe the Chinese meaning of fields in each table, but also the relationship between tables, which is the same as the view expression. Therefore, I suggest developers write code, write more views, and write more stored procedures. Some old code,SQLAll statements are written and executed in the code without a view. For such maintenance of the old systemSQL copyMake the view, and maintain it.

For detailed functional design books, it is actually intended for programmers to find out the details of business processes. It is difficult to understand the meaning of Code directly, and there are no other documents for reference, so you can only guess the meaning of the Code. In particular, many maintenance personnel and many functional details are designed to deal with some special requirements and abnormal businesses. They are all written by previous programmers, but the former programmers have already gone, the maintenance personnel do not even know the detailed functions in the software. When a new implementer or support engineer returns a question, he wants to ask the programmer what is going on with a specific function. The programmer is familiar with this function. Well, what else is this function available? I don't know.

To solve this problem, what I have done before is to help the Organization implementers write functional instructions. Because the implementers need to provide training instructions to the customers, and there is no help description, they can only talk about it with a single mouth. The implementers need the help of function operation instructions most. However, the implementers think that this help is a part of the software, and it is the software developed by the Development Department. The Development Department understands the functions most, so the help documentation should be written by the Development Department. The Development Department believes that the responsibility of the Development Department is to write code. You do not have any operation instructions on your own training. Therefore, the help documentation should be compiled by the Implementation Department. No one wrote the help document.

In the final analysis, the help description is to be written after all, mainly because of who wrote the question. Who is the most motivated to write? Implementers are the most motivated because they are closely related to their work. Programmers obviously have no motivation. In addition, the implementers are familiar with the quality of the first-line customers, understand the customer's specific operation ideas and understanding ideas, and write help files to help the customer understand. In this way, the help files can truly serve the customer. Many of the help documentation has never been written by any purely document personnel who have never met customers, conducted training, provided customer support services, or even tested software, we can imagine how much help the help documentation can help customers.

When writing help instructions, I asked the implementer to give each button a key point.GridThe data source and meaning of each field in must be described. The data source and meaning of fields in each report must be described, the data source, data entry requirements, and data meaning of each field in detailed input. This write does not matter, and many hidden special processing functions are found. Many features are unknown to many people, because many detailed functions are customized for a customer. Only the implementers responsible for implementing the customer will know. As a result, the implementation of mutual ventilation between personnel, just to make up a lot of functional details to help explain. There are some features that do not know which customers are asking for or why they want to do so, leaving a blank space for developers to see how the code is handled. In this way, a detailed help description finally came out of the pressure. Since then, developers have quickly understood the requirements, and of course they have understood the meanings of the code that they thought was messy in the past. They are in a lot better mood and it is much easier to modify the code. It turns out that everything is done by yourself. I don't want to look forward to software engineering, I don't want to complain, I don't want to increase manpower, I want to solve my own problems from the reality, I find that many solutions are simple and effective, and I don't need to be a team at all.UMLYesOo.

In addition, I gave him some suggestions on demand control.

There are many requirements. There are features (especially special business needs of each customer), exceptions and errors, performance, compatibility, usability, special permissions, and aesthetics.

There are also many sources of demand, including direct calls from the customer's computer room, direct calls from the customer's business department, implementation staff, support staff, marketing staff, and sales staff, some bosses and customers make a ticket or have a meeting to call developers directly.

The requirements have different priorities. Some customers are tough. You must satisfy them as soon as possible. Otherwise, he will call your boss.

This is precisely the demand phone number for all aspects of the people who come from various levels of views in all directions, so programmers will be bored and need to develop. In addition, many of them use a single phone call to think that programmers can develop. However, after the development of programmers, the customer may not be the one he or she wants most, and then modify it.

Therefore, a high demand is actually an illusion.

First, classify the requirementsExcelTable. The requirement management table contains the following items: customer name, requirement author, submission date, demand closure time, function module name, current customer version number, Requirement Description, and requirement classification (requirement,Bug). I used this method when I didn't need a management system at first. In the past, when I was not using it, I was so busy. I asked him to organize all the current tasks and send me an email. However, after sorting, it must not exceed10Thing. Some tasks are waiting for the customer to provide information, some are debugging and tracking errors, and some are ambiguous requirements. I will give him an analysis. There are only two things that he is doing now, and they can all be done independently. They do not need the cooperation of others. Is he busy? He is busy, or he deliberately says busy. It does not work. This is the case if the account is not clear or not clear.

With this form, you need to submit a copy to the boss on a regular basis (maybe one week, maybe January. This indicates your workload. Let him see that you have been working very hard and have done so many jobs. In addition, it can also be seen that you are responsible for your work carefully.

Some programmers do not use this form or report it to the boss. In many cases, programmers do not have to do so many jobs. If they can push, push, and mix, they can drag and drop. I am afraid that I will not be able to mix up one day, so I feel a lot of psychological pressure. I always feel tired when I don't work every day. This fatigue is self-seeking. Some programmers may think of themselves.

Second, unclear requirement descriptions are the culprit of Repeated modifications. ForBugYou must have an error message on the entire screen. Do not intercept a small part of the error message box. For a report requirement, the table format should be provided, and the source of each item of data should be given. If there is a formula relationship, a clear formula should be given. For the input document requirements, the document format must be provided. Requirements for each input item include optional values, default values, non-null values, uniqueness, and constraint input, the number must have a decimal point, and the date must be accurate to the date or to the minute.

For the current situation of this user, I also suggest that he start version management.

CVS,VSSAnd so on. This is a battle of a person. Even versions have no concept. At first, it was a very formal tool. Most of them felt too troublesome and returned to the original state. They also had a bad impression on version management, it seems tedious and useless. So we have one sentence: one pipe is dead, and the other is messy. The reason is the lack Intermediate transition solution.

Therefore, we recommend that you first raise the awareness of the version and follow the version management method. As a result, you naturally accept the formal version management tools. The version management tool can be split or merged.BugRelease patches without releasing unfinished new functions. You can release a custom version for a customer, or you can trace back historical versions to compare historical differences,Source codeHigh security.

Several transitional suggestions are particularly useful:

1. Back up the code to another machine before making major or uncertain changes. The backup directory must be up to date.

2. Release a stable version before making major changes. Many programmers do not have the version concept and are constantly modifying it every day. As a result, each of the products provided to the customer are semi-finished products, and the half-pull operator has not been modified, and the customer has not implemented blocking. The customer accidentally used the function and made an error, so he could never use the function. It is not complete yet. However, it is too late to enter the wrong data. In the future, it will be a problem to flatten the report, and special data processing will be required. You have to solve your own fault.

3. Even for trivial changes, you need to back up the source code every day or the next day. Do not be afraid that there are too many codes. The current hard disk is very large, and backup and copy is5Minutes. Do not worry about daily backup. We often encounter this customer asking for a change, and the customer does not want the change. A feature has been changed and changed back, but the source code in the past has not been backed up and you forgot how to write it. At this time, you will think of the benefits of code backup. Especially now there are a lot of free software for file synchronization or automatic file backup, which can be done on a regular basis. Powerful functions, and some differential backup functions

4. There are a lot of text comparison software, suchWinmergeAnd so on. You can compare the differences between the two files. This function is the same as the source code difference in the version management tool.

5. If a new version is released each time, the list of closed requirements from the date of the previous version is extracted into a file, which is included after the new version. In this way, even if no one has written the update instruction document, the problem and requirements solved by this version can be traced. Many programmers do not need to manage tables. Version release requires the writing of update instruction documents, which can be omitted or even incorrect. Many programmers have had these scenarios: I remember to change them. I did not touch the code at all. Shouted: Why did my code disappear? I remember I changed it.

I have provided a complete set of instructions on how to maintain the old system from the perspectives of Requirement Description, workload management, legacy system code reconstruction techniques, backup management, version management, and update instructions, but I hope to share it with you and help you.

There is a way, you are not alone in the battle.

Everything is possible.

Believe in yourself.