Aiti Tribe Stories (21): How difficult is it to take over a project midway? Teach you how to be a good takeover man!

[51CTO.com original article] Ha Han Langzi, who has been tortured by countless unfinished projects, has been engaged in JavaEE development. He has stepped on countless pitfalls and has also taken on several other people's projects. Newcomers or newly employed programmers will face a problem: how to quickly take over familiar projects? In this issue of Aiti Story Collection, Ha Han Langzi will teach you how to be a happy takeover expert.

[[195176]]

JavaEE Development

Taking over the project halfway was criticized

As a programmer, I like to browse knowledge sharing platforms like Zhihu to broaden my horizons. I often find people asking similar questions, such as how to quickly take over and become familiar with a project (from a code perspective)? How can a novice quickly get started with a project?

Through the title, Han Langzi could feel the eagerness for knowledge in the questioner's eyes. He read the comments under the question and found that no one gave any solutions, but instead just complained.

Selected comments:

A: Either endure it or get lost +10086, you have to smile even though you have a thousand alpacas in your mind.

B: I joined such a project right after graduation, and now I am planning to make the most of my experience.

C: Too many... Professional butt-sweepers, they will survive until the end of the year and then run away. Whoever wants to wipe it can do it.

D: I used to be a coward. My boss assigned me tasks and I accepted them silently many times. Yesterday, I really exploded. Why do people bully me every time because I am so easy to talk to? I really felt like a rabbit will bite when it gets angry. I rushed to the boss's office to debate. Usually, my boss thinks I don't argue much, but yesterday I was at the level of a debate contest, with solid arguments.

Leader: Considering your ability, we specially gave you a benchmark project to do maintenance, but you are not grateful at all.

Programmer: The project handover documents are missing, the project business code is confusing, and the project has not yet determined its boundaries, which has led to the current expansion of demand. Is this project also a benchmark?

Leader: These are not problems. If you can handle these problems well, it will just demonstrate your abilities. This is such a great training opportunity.

Programmer: You are talking nonsense. As far as I know, you did not say that in the regular meeting (usually the project leaders attend, and programmers are not eligible to attend). You said that it is the responsibility to handle this project well, and if you don’t handle it well, it means you are incompetent.

The leader said seriously: Even if I give you a pile of shit, you have to eat it happily, otherwise you can leave, there are people who can write code everywhere in the street.

. . . . . .

Seeing everyone complaining like this, Han Langzi felt sad. Because he had also experienced such a period. At that time, he was still a young man and followed whatever his boss said. But later he found that he had to give in to the weak. Besides, even if he gave in, his boss didn't like him. He always worked hard but got little. Even when he left, his year-end bonus was ripped off.

How to take over a legacy project

Life is about growing through experience, so I want to share my experience of taking over a project and be a happy taker. So how should we take over a legacy project?

1. Preparation before taking over

Before taking over, you should first understand the current status of the project. You can consult the leader in charge of the project. Of course, if the leader fools you and tells you that this project is a benchmark, or how good this project is, then you should think more about whether it is a pit. At this time, you need the leader to provide the project's bug modification sheet or requirement change sheet, so that you can roughly and objectively show the problems of the project. If there are many things modified in the bug sheet, or the requirements change frequently, then it is not recommended to take over the project, otherwise you will be uncomfortable in the end. You should handle the unfinished project well, and if you don't handle it well, it means that you are incompetent, and other colleagues will squeeze you without any pain. If the project's bug sheets and requirement change sheets are not very frequent, this project can still be taken over.

2. The first thing to do after taking over

Start using the project immediately, run through the project process first, and then understand the design purpose of the project, because these contents are like a lighthouse, which can show you the way in the general direction, and help you connect the code fragments, sort out the code of a functional point from the data layer, service layer, to the controller layer, so as to quickly locate the relevant position, and be familiar with the configuration files related to the project between each layer, such as the scheduled task configuration file, encryption and decryption configuration file, etc., so as to form a whole. We must remember that the more complex the project, the more important its purpose and design are.

3. Disassemble the project and write your own project documentation.

Projects are often difficult because you don't understand them. When you look at a lot of things, you will feel psychologically stressed. You must move forward despite the pressure, understand the project by modules, and understand the business through the code. A system must have frequently used modules and infrequently used modules. This can be understood from the user manual for customers. If the project lacks specific design specifications, you need to see how the relevant functional codes are written, and understand the business process by understanding the code and using the project.

At the same time, you need to learn how to write documents, mainly to make yourself understand the project better. Because you have taken over the project, it means that you will be responsible for any problems that arise in the project. Even if the problems arise due to project design or development, you will be responsible for them. Because writing text is not like speaking, it takes more time. In the process of typing, we will spend time organizing language and thinking, which will allow us to discover more problems in the project.

4. Enter maintenance status

Once we understand the project's business and related codes, we can start dealing with practical problems in the project even if we have officially taken over the project. At the same time, we should develop the habit of looking at the production logs after get off work every day to see if there are any potential problems in the project, such as excessive memory overhead, deadlocks, etc.

• Check the logs, mainly the error logs, to determine whether the bug is urgent or non-urgent. If it is urgent, fix it immediately. At the same time, write an email to the relevant leaders. (Otherwise, even if you solve the problem, the leader will think you have no workload)
• Check the server's CPU, memory, and other overhead. This doesn't have to be done every day.
• Write some SQL scripts to detect whether there is data duplication and junk data in the database table. Mainly to prevent SQL injection and other problems.

【Written at the end】

Only after going through all the above steps can we become a professional project taker and then grow happily. No matter what pitfalls or bugs were left for you in the previous project, we should of course choose to forgive him!

If you are also willing to share your story, please join the 51CTO developer QQ exchange group 312724475 and contact the group owner Xiaoguan. We look forward to your wonderful story!

[51CTO original article, please indicate the original author and source as 51CTO.com when reprinting on partner sites]