Just pulled out of a project, referred to as X project. This project, or encountered many problems, but also solve part of the problem, or winter ridge harvest, so to sum up.
Although the title says a short-term project summary, but in fact this project is not short, it lasted about three years. So-called short, just a short time I stayed in this project. After I was in the project run more than two years, will end in six months there is a point in time go. And because I went about more than four months after the project entered the maintenance period, I will leave the project,
I went purpose are the following:
1. Simple help it develop and maintain bug (this is not essential, because at the time I joined the project schedule has been controlled, after the addition should be regarded as a normal development output).
2. Understand the project appeared, and now there are still problems, analyze and give recommendations (a lot of problems on the project history, past relatively low quality and customer satisfaction).
3. Contact and understand the team members, give positive incentives if necessary.
4. For me personally, you can also learn some soft skills not available in their original
Without further ado, look below this column encountered in the project, but it may also occur in other projects in question, as well as some personal thoughts:
1. The part of the document obsolescence inaccurate, unmaintained, and no one to see
2. Code review process ineffective, reviewer direct point merge, or mention the comment is ignored. Some merge request (referred to as MR) did not add the appropriate reviewer (such as when maintenance functions written by someone else, the general should be added author function)
3. Copy and paste is serious, and part of the development is not responsible for their own code and paste come.
4. coding style is not uniform, and the team seemingly did not realize the importance of the code style.
The task priorities change frequently, you need to reschedule the task leader every day, the same task can be assigned several times a day to change the person. The development, the daily to do tasks may change 3-4 times.
6. If the developers found a bug, there is no uniform determine the processing flow, often in private communication, found that people either fix them or fix the original author.
7. The project has multiple branches need to maintain large, because of the architecture of the project, after switching branch requires a series of script / command / adjust the configuration (sometimes), but also regular ruining the environment will need to redeploy the entire environment again. Huge cost. After familiar with the business development and code switching large branch become the most time-consuming activities.
8. Since the project used technology is relatively old, some developers are eager to learn, but I do not know what you can learn (lack of guidance and advice), the contradiction that desire and lead developer of the status quo sometimes show frustration and lack of confidence.
Well, the problem list over, following a problem analysis and a list solution I can think of (if any), and these problems can be combined into several themes.
- Documentation Issues
In fact, this problem is easy to say too easy, that is difficult is difficult. This is a circulatory problems, a virtuous circle or a vicious cycle.
The so-called virtuous cycle, that is, the team found what information needs to be repeated to convey or use, this information will be recorded as document and inform the team. In addition, each found the information needs to be updated, are actively update the document. Every time you have any questions go to find the document. Self-solve problems.
A vicious cycle on the contrary, the information will be reused or not documented, or find information updated or outdated documents not update the document. The document does not update the content of the document obsolete inaccurate, no one even look at the document, and so the cycle continues, the final document because of outdated and inaccurate become invalid, the document exists in name only, the team also lost consciousness and habits to see the document.
Simply, each document do not require perfection, but is created when the information can be reused, there is a well-known (within the team) document entrance, as many people have consciously write and update the document.
The hard part is, become, if not long-term update, a lot of documents totally obsolete, needs to be rewritten. And if the document contains the standard things like, medium-term projects than the initial promotion will re-execute much more difficult to adhere to, because we have formed different habits.
Documentation want to solve the problem, prevention is better than cure. Prevention is starting early in the project, so that more people involved into the document creation and updating, and the need to comply with. If at a later stage in the project, just to surgery to change almost the same, we want to put down the work at hand to document change, the need for greater determination and execution, and the impact will be on the progress, implementation remains the same if changed after that over time will become obsolete invalid document, the document will change this time is wasted part.
- code quality
Regardless code review, code style, or copy and paste, these problems point to a goal, that is, code quality. The quality of the code is also a direct impact on the quality of projects.
Code quality is not good cause not happen overnight, nor is a person's responsibility. To solve this problem, the whole team needs to spend some time together.
According to the project at that time, because the time is not much follow-up project, combined with the limited knowledge and personal experience, my goal just want to code quality than in the right direction, can improve how much is how much.
I ended up doing these include the following:
1. Develop code standards and allow the team to accept recognition. Eslint introduced, and added to the CI eslint process, the auxiliary code execution specifications
2. Develop code review standards. And the idea of daily code review will spread to the team, running a code review we recognized standards.
3. To achieve a base class and a node script, automate the manual operation when the new module, the hidden part of the logic is repeated, and a number of standardized methods to realize common functions. This reduces us to understand the difficulty of the code, when found to have better implementation method can also be extended to the entire team.
4. found that some wish to learn, improve or alter colleagues, share experiences and try to motivate them forward. The project used the framework of the old, and they found that something can be learned outside the framework together. The code readability, scalability, how to design the components, design patterns are available, how to optimize the development process and the like.
The last point I did not do a thing, but I did not do, is to blame someone specific. First, this is not an individual problem, but a problem of the entire project. If you blame someone, blame the people who have emotional rebound, will not change with subsequent recommendations, which will only increase the difficulty of the work.
After this process, deeply understand a truth, when we want others to change to a target, do not just tell goal, also inform the method to reach a goal, and ultimately more promising achieve our desired goal. Because sometimes people are not willing to change, but just do not know how to do, under the circumstances I do not know how to do, a lot of people will give up to change, and then an urge to blame is not much sense.
Again, this is an ongoing project quite a long time, we all have to develop projects in their various habits, then do not ask others for bold or strong change, this will only lead to conflict and confrontation is not conducive to promoting things . First, a better way to understand the team, then let the team try to slowly change in the pain of the situation, and give specific methods change.
- task allocation strategy
The above problem of task assignment will not repeat here, but to say the problem could lead to:
1. updated daily task priority and the need to assign the task that day, which can lead to spontaneous development is curbed. As the day to complete the assigned task, the development can not receive more tasks on their own. Because the priority of daily changes cause no one knows if today's bug also need to change tomorrow. If not, it is a waste of time spent on the above.
2. The same bug frequently to change the nominee. We all know that after not immediately able to get the bug to change the code. First study. The study included switching branch, reproduce, read the code, want to program. This process is often better than a short code and rewriting been tested change time. If a bug is assigned to a developer, over a period of time and arrange for someone else, then, though not before a good bug to change, but it spent on research stage almost all the time is wasted. If this is the norm, then the team is basically inefficient predictable.
3. bug assigned to a function of the strange features of the development process. This practice can not kill a stick, there are a variety of situations.
a. When there is no schedule pressures, doing so is a kind of knowledge sharing, can reduce the risk of future maintenance of the project.
b. If the core developers, are more likely to complete functionality, such as various public methods and components, at this time if these things bug is assigned to him, the one is not fair, and secondly causing contribute more, work more , probably against the team to achieve a common motivation methods and components.
c. When there is schedule pressure, if the function is complex enough, received a strange bug in the function of development it takes a lot of time to understand the needs, how to use the function, how to implement the code, and so on. This also leads to a certain extent on the efficiency is not high.
As to solve, not a single person can solve task allocation, which often have clients schedule pressures. He said the following about my personal view:
1. Try to make the task a little longer the priority of the effective time. This customer-facing colleagues have good negotiation skills. Benefit is that when the development is completed assigned tasks that day, have the opportunity to receive more familiar with their own or their own tasks, improve team efficiency and enthusiasm.
2. Do not short change non-essential tasks assigned people to avoid waste developer spent on research, preparation, time on the attempt. Because the code before final submission can do many things. It also depends on the next point, not too casual schedule tasks.
3. If a bug or task, is based on the public, we recommend as a general processing tasks, namely the development of each depending on the workload, try to balance the distribution continues, it simply is less who who handle the task. If the non-public function, only specific pages or function modules, it is recommended to let developers familiar with handling the function.
- development branch switching problem
The point I thought was rather special, is not universal, but then on reflection, that this problem can still get some general inspiration, they still continue to talk about.
In fact, this problem can also be called the development environment. The project we have several large branches, after each major branch switching, need to re-deploy, configure, execute a lot of things, and even if executing the deployment may still fail if the deployment fails and you need to reinstall environment settings, perform another lot of things. If a problem occurs after switching to develop a large branch in order to eliminate this problem and normal development often takes several hours, a morning or afternoon may be so passed.
I toss over time, came up with a way, is a single development environment for each major branch ready, individually configurable, that an environment can only be based on a large branch, to do the task in another large branch directly another open development environment. This practice stupid, but effective, help me to save a lot of time.
Although I was the problem is solved, but a reflection of another problem. I define a word: "development ready", a term I would like to express a state, in this state, I needed to develop the code, run-time environment variables, data are ready, the task can be developed. And this project if you want to switch large branch, want to achieve the state of preparation of the development, costs are not fixed, a few minutes is good luck, bad luck a few hours. I want to say the problem is that projects for new members, old members to switch tasks or working to achieve development costs as low as possible should be prepared, because this cost throughout the project and will be repeated countless times. Worth the high price to reduce this cost. And our project has its own peculiarities, but this cost is not really no longer be able to reduce it? I think the answer is no. We can be more scripts, configuration, integration to command only a compilation or deployment command, so that more manual operations can be done automatically. This can reduce a lot of problems due to manual operation results, but also reduce energy consumption and the number of people to be interrupted.
In this project I do not know exactly how to do. However, in future projects, my goal is to reach a key development ready. That is, after switching branch, to prepare the development of labor costs it is zero or only need to perform a script or command. I believe it can greatly improve development efficiency.
----------------
Long time no write blog, write well and finished procrastination in many days. As it is to record their own do take your time.
Thank you also to watch other people and correction.
2019.11.09