Why do we worry about influencing the enthusiasm of programmers when considering code management? Can an elite team completely solve the problem of code quality? What kind of code management problems will the war culture introduce? The following are my thoughts on these issues.
Code is for programmers, just like a sandfield is for generals. It is widely hoped that the Code is fully controlled and can be freely hired and attacked. However, this behavior hides great risks for code in a team. Especially in a team that advocates the martial arts culture, while encouraging everyone to take on more responsibilities, we should also pay attention to the restrictions and constraints on the field of code. In a large development team, module-level code permission management is still insufficient. You need to introduce code file permission management. However, management is generally restricted by some understanding.
Code Management ProblemsCode Management is not a technical issue, but a management issue.
Code Management seems simple. All configuration management is in place. But this is just a form. The details of code management vary widely. It is still common to regard configuration management as an idea to keep code history.
In fact, code management also has some management problems, such as code permission management, review mechanism, periodic review and corresponding audit mechanism.
It is not difficult to implement code management from the technical perspective, but it is difficult to implement the corresponding management methods. Technology is a management tool and cannot be replaced by management. But where does the management difficulty come from?
Many companies have experienced workshop-style development in the startup phase, and programmers and managers have a sense of absolute control over code. When the company is scaled up, there will be more demand for standardized management. However, there are always too many reasons for code management to prevent managers from doing well. On the one hand, we emphasize minimizing constraints to protect the enthusiasm of programmers. On the other hand, when problems arise, we emphasize subjective factors such as attitudes and consciousness. Therefore, hiring as many people as possible becomes a solution. At present, no matter the personnel management issues, at least the code management and quality issues cannot be solved.
Human problems are also Management ProblemsIt is our habit to emphasize people's attitudes. Spirit, willingness, attitude, and even character are repeatedly emphasized in our daily work. Also pay attention to the typical work style of people. All of this has played an extreme role in that age of material shortage, and spiritual guidance has played a great role. However, over the past few decades, it has been a matter of criticism.
People's problems cannot be ignored, but should not be viewed as a whole. That is, the collective will cannot be used to erase the individual's will. The advantages and disadvantages of human nature must be met, just as everyone makes mistakes. If a mistake is made, the last tag will be deducted, which is obviously unwise.
In reality, Chinese management emphasizes subjective initiative, system and overall view, and lacks the ability to grasp individual and details. The lack of strength in specific management methods makes it easier for us to think from the perspective of people. A specific problem has been transformed into a spiritual issue. The facts are easy to handle, set a goal, emphasize a careful, serious, rigorous attitude and so on, and publicize several typical examples to exert their influence. Does it remind you of our childhood red flowers. We are so arrogant. We all know that, when we make mistakes, the temporary model is never a permanent model.
Such a management method is an unspeakable realm. Everything is chaotic, vague, and only direction. Everything is developed under the force of some unknown power. Now, everything is under control. If not, it can only be said that it is not time. As a result, we have developed a highly sophisticated technology, but cannot produce amazing milk powder. The technologies we created have hundreds of problems in mass production. All of this comes from the idea of focusing on big data.
Is there a way for management to face up to the details and to face up to specific problems? The key lies in removing unnecessary psychological burdens and establishing procedures and methods. Use the process to constrain and use methods for guidance.
Positive differentiationBack to code management, the biggest psychological obstacle is worrying about affecting the enthusiasm of programmers. There are two problems here: first, whether there is a real connection between enthusiasm and code management constraints. The second question of enthusiasm is really important to become an obstacle to management.
What is enthusiasm for the first question? Will constraints affect enthusiasm? This actually depends on the values in the big environment, rather than the attitude of the individual. Do you want to draw a circle to illustrate your interests, or wait until you encounter problems and make a decision? When you do things, you are more afraid of unclear definitions than you cannot do anything. The so-called Plan cannot keep up with the changes, and the changes catch up with the boss. I did a lot of work and finally found the wrong direction. This is not very sad.
Of course, it is not a good thing to constrain more, especially when it enters the state of micro-management. It is really terrible. It is still a misunderstanding in the process definition.
The process definition is designed to minimize the possibility of human errors. There are pre-implementation expectations, scope and methods, and check after implementation. Rewards and Punishments are manual and cannot be used as process definitions.
Let's talk about the problems caused by the war culture. Enthusiasm is obviously very encouraged in the war culture. How can we protect enthusiasm? What can we do to ensure it can bring good results? Each programmer is responsible for a part of the functions, such as a platform, and actively manages his/her own territory. However, if it is to manage others' territory, it remains to be discussed. Although mechanisms to encourage internal competition have always been available, they are also very helpful. As a matter of fact, promoting internal development of some complex products can introduce unnecessary risks. The condition for judgment is whether the thinking and design of others can be well understood. A bit of misjudgment or information disclosure may lead to new problems. Such enthusiasm requires encouragement and more guidance and constraints.
The second question is that enthusiasm is very important, but is it really important that it cannot be constrained by management methods? Obviously not, after the psychological burden mentioned above is still behind this idea, I think there is no "moderate" method. As long as you ask whether the company's future is important or motivated, the answer is clear.
Is there something alarmist? We all know that when the Code has a taste (the reference in the Code Daquan), it is equivalent to opening a broken window. Without decisive correction measures, it will surely disappear into the tragedy of the warm boiled frog in the future. More risks are being introduced for seemingly easy and convenient behaviors!
Convenience and orderWe all love freedom, but when freedom hurts others, we are constrained. While enjoying convenience, we must take responsibility for maintaining this environment. A Overtaking may result in congestion for half a day. It is better to speed up in order. Therefore, it is convenient to establish on an orderly basis.
The problem is that if no one queues us and no one tells us how to queue up (obviously there are different queuing methods in hospitals, banks, and school canteens), disorder will become an inevitable event. Out of order means a problem, not a risk. The damage can be huge or small.
Originally, code management has permissions, but it is often defined between large modules, and the purpose is usually to keep them confidential. In a department, permissions are usually unclear. Internal programmers can still modify what they think is unreasonable. This is the problem.
Importance of Process ConstructionFor a R & D team, the best way to make everyone feel free is to define constraints. The standard process serves as the basis to form a benign impetus. The faster the company develops, the easier it is to ignore the infrastructure. When everyone is busy with demands and fixing bugs, basic problems will gradually attract risks and then detonate at a certain time. It seems that the more you do, the more you will be wrong. When the development process begins to accommodate a historical design or behavior, it indicates that the basic problem has emerged.
Everyone is aware of refactoring when writing code. In terms of management, there is no need to refactor it! Small steps and slow process reconstruction are also a practice of scrum.
The process provides a clear box and method. Different management methods are used at different stages, which is also a strategy to deal with specific problems. If we look at it all with human problems, we are somewhat deceiving ourselves. Why are foreign excellent practices always changing in China? China is so smart that it will always look at and solve problems in its own understanding and habits. In this process, it is impossible to actually face the specific details, so the results will have their own shape and no reality.
(We always limit the programmer's time to coding, making demands, solving bugs, and other seemingly directly supporting business. On the contrary, the improvement of basic productivity depends on the individual discovery and creation of programmers. However, if programmers are already busy working on specific projects, how can they spend more time optimizing them. Think about the differences between the East and the West. Think about why Westerners have achieved greater achievements in basic disciplines ?)
It's also wrong to do more! Of course, right is relative to wrong, but at least we need to understand our problems.
This is a weakness in our process construction methods! Finding a solution to practical problems is the way out.
Code Responsibility SystemWith a high-level understanding, we can only talk about code management.
Make sure that the Code belongs to the company first. As the boss often says, the Code belongs to the group, but not to the individual. Code Management Based on this is a required management action. The specific responsibility lies in who is fully responsible for the code? Including Who can modify the code and who can review and agree before submitting the code. The granularity should be fine-grained to files or directories.
Code is not a public asset. Even open-source projects often have a review mechanism. The review here does not only refer to peer review, but must be reviewed by the code owner before the code can be submitted, so that your modifications can be acknowledged.
The code owner must be familiar with the code design, expansion, and related history. In this way, key content can be centrally managed and immune. Documentation can help you do better, but in reality the documentation is usually insufficient. What if the code owner is lost? Why is there only one code owner?
Other programmers can still learn to modify this part of code, but simply follow this process when submitting the code. The code owner can be changed, but the process cannot be changed. As the programmer grows, the code that can be responsible increases, and the owner changes, rather than skipping the process.
This is a simple thing that I have been so arrogant about. The conclusion is not my purpose. I would like to emphasize the previous thinking process, because an Understanding determines a series of actions. Only by finding the root cause can we better understand what is happening around us.
Reprinted please indicate the source: http://blog.csdn.net/horkychen
