Author: sodimethyl the source of this article: http://blog.csdn.net/sodmenote: This article can be copied and reproduced without the consent of the author, but any reference to this article should be retained by the author of the first three lines of the article, the source and. thank you. note: every day, in the project, we need to constantly communicate with our teammates about design methods and coding methods. In the Forum, we often see endless debates on a technical point. Some people say, "the more the truth is, the more clear the truth is. However, you need to understand whether you want to find out the rationality of a truth, or to succeed a product and bring a team to success? This is an article about how to deal with the debate. The core idea of the team is: the purpose of all our arguments, its starting point, it is not just to prove the right and wrong ideas or technologies. Our purpose should be how it is more beneficial to the project. This "benefit" is manifested in the efficient publishing and stable operation, quick modification and maintenance. In most cases, there are not many practical advantages for products. What we need, it is because team members have developed some good thinking habits, good coding habits, and good design habits in the process of continuous practice. In more cases, we need to rely on the self-learning and growth of team members, which is not solved by one or two arguments. We should be more pragmatic and let the team members grow up in specific practices, instead of relying too much on arguments to help them grow. "Stop the debate and immediately implement the debate". Improving and improving the practice is the most pragmatic way for us to deal with the debate. Introducing the text ---- we have a habit of saying "yes" or "no", that is, most people like to compete with each other in the discussion of a certain technical point. For example: Common win platforms and * nix platforms, C/C ++, Java or Delphi, various design patterns, and various third-party Libraries, not all. Everyone wants to prove that what they use is good. What others use is bad. Er, is this meaningful? What is the purpose of our technology? Is it to show off? Even if you show off and win, what are the benefits to yourself and others? Even if there is a benefit, you just get addicted, but the disadvantage is that it makes you less pragmatic and forgets the purpose of technology. As a person in the product, we have only one purpose for technology and consortium, that is, to make full use of our own technologies and skills to contribute to the product, always focus on the unique goal of "Fast and good products. You are proud to compete with others outside, but in your own projects, because of the overly complex architecture, this allows the project to spend a lot of time resources in maintenance and modification. Even if you win in the debate, you are also a complete loser in your project. Your own projects and products, to the small, are the foundation of your company. To the big, it is also the foundation that you can base on in the industry, everything, and performance, do not assume that you have mastered some book knowledge, some soft engineering theories, and become familiar with everyone. If you are a senior person in the industry, you will be worshipped everywhere, if your project isn't working, how can you blow it up? The bubble will be cracked soon. So, stop arguing, right away. Now, start to do your daily work in a pragmatic manner and start with the details of every small part to make your work more efficient, the quality of work is better. Everything starts from the actual situation of projects and teams to choose technical solutions. If you don't want others to say anything good, you must use the solutions that people say. You are you, your project is your project. It is like falling in love. Those people who give you advice will never better understand your sweetheart and your true feelings, most of the ideas they have come up with are just an idea. From this point of view, the role of the domestic technical community has been quite distorted in my opinion. To discuss the problem, either it is too small to be a problem, and Google will be available, or they are constantly talking about the "truth". Every day, they are so happy in the jar that many may not know, he may not have used his own theories in his project practice. I am a thorough and pragmatic School, a good developer idea, and an advanced development theory. Here, if I do not conform to the team and project reality, I cannot play its due role, I will also firmly drop cancel, because, in my opinion, for a project, we are the most valuable and irrecoverable loss, that is, time. On the one hand, we want our team members, everyone, to go down to the bottom-layer details of C ++ and to the design model. On the other hand, we have to face a reality, in the vast majority of teams, people who can do this are always a small part. Most team members are only in a development field that they are familiar, it's just a good programmer. Therefore, we choose a pragmatic approach. When there is a debate over the architecture, pattern, or even code details, do not go into too much. When you find that the debate cannot produce good results, the decision should be put to the people who really want to do this, and let them make their own choices. If we cannot determine which solution is better or worse, our approach is, first of all, you have to make the person who is doing this feel good. Only when he feels good will he be more active, and he will think more about improvement later. The project is divided into three phases: the first step is to publish the book as quickly as possible to produce results; the second step is to ensure fast and efficient operation; the third step is to maintain as fast as possible, modify and release a new version. "Fast" determines your position in the market competition. As long as you are always thinking about "fast development and easy operation", you will naturally come to a conclusion about many things, how to do and how to choose.
