Autumn army in the sand field-walk out of the software Workshop: how to become a regular army for the development of million people)

A few months ago, the office next to the company moved into another company, as if it was also a software company, and as if it was a newly established company, programmers work overtime every day, look very young, hair very oily, dressed in big vests and underpants, there are all male and female, often standing in the channel smoking in groups, or simply sitting together in a pile of meetings, there is no way to eat in the canteen, there are box meals, at noon and evening, I often get off work in the evening. I saw someone holding a lunch box coming out of the office from time to time and throwing the lunch box into the garbage box. I don't know how late they will work.

Recently, they found that some of them are working normally. They seldom get together to smoke for a meeting. There are only a single person on the phone in the channel, with a very low voice and a common look. Occasionally, when they see a meeting in the outside channel, they are also nervous, solemn, tired, wooden, or silent.

I think of a sentence: Boy, slowly, slowly.

New products, new dreams, and people all hope to use the accumulated knowledge for many years as a product in the industry. However, this is a new team.

I remembered when I first debuted. I am still glad that I can go through the entire process of product planning, implementation, sales, and scale sales. I have seen how a product grows, what problems will be encountered during the growth process and how to overcome them. Many programmers do not have the opportunity to join a company that has been running for a long time. The team is ready-made and the products are ready-made. They just do maintenance and development on their own, there is not a complete product lifecycle. So once a new product is developed, I am very confused, don't know how to start, and I am very excited. I have been maintaining other people's code in the past. Many ills cannot be undone or redone, now I can show my skills. I want to add all my ideas here, so I can't leave any regrets or repeat the same mistakes. So I threw myself into all my painstaking efforts, even sleeping, and feeling surging every day. But the time was not long. For more than two months, all kinds of problems came. New technologies, new teams, and new products are all new. A lot of cross-cutting problems make it difficult to solve the problem, and the Team is also excited, cool, and tired. Everyone wants to end the process as soon as possible, however, development is only in the middle, and it is the time to tackle the crucial challenge.

When I first debuted, I joined a newly established R & D center for four months. I was the sixth person. The product is still under planning, the team is still under construction, and the technology is still learning and exploring.

At that time, the technical director did two things that I now think are right: 1. He asked everyone to read the source code of the previous generation of products and sort out the functions of the previous generation of products, and the customer business processes mapped by the functions of the previous generation of products are obtained. It also needs to point out the vulnerabilities and contradictions in the business processes of the previous generation of products. 2. He asked everyone to learn new technologies by transforming the source code.

He not only asked everyone to sort out their businesses, but also drew a detailed flowchart to sort out detailed data structures. Then, we will arrange a centralized meeting for you to talk about. When talking about the process, we will go to the software interface to explain what fields are processed for data access, how are tables associated? What tables are retrieved from? What are the unreasonable table structure design.

I did not explain it this time. I have no definite answer to this question. I will continue to explain it next time, not just once. I found that many teams lack the courage to keep root of themselves. This is the first time when I talk about things that I didn't fully understand. The leaders just arranged to study the things, but they didn't have the following content. I went down and looked at it. I thought I had found the answer, but I didn't have the chance to verify it again. So the most important thing I should do is to let it go. We know that programming is often the most detailed difference, which is the most prone to problems and rarely tested. programmers who maintain code often do not know what this is, once a problem occurs, it is difficult to understand.

The Technical Director also asked us to transform the source code. But this is also a goal, that is, to change all controls into a unified experience style. If there is no dB control, you can look for it. Once found, we can extract this part of code and then form our own control package. We strive not to install the entire Control Suite package for a small control. If you cannot find it, you can develop your own controls.

I think this method is the best way to learn new technologies. This is how I direct my subordinates.

To learn new technologies, read official examples, such as Java pet shops or. NET pet shops. But I later understood that I cannot learn this. Because it is a stranger to new technologies, and such code is the first to become the master, the style of programming in the future will often be the same as those in these examples. In fact, we do not need to write business applications in this architecture style or show so many code modes. As a cat or a tiger, we are tired and cannot reverse our thinking. We don't need such code that looks pretty good.

To learn new technologies, the second method is to find an open-source online system. For example, some new technologies have become Forum systems or management systems. But this method also has a drawback: The Code he writes has his own style, and he is still in the trial period. He may write this thing to learn this technology, rather than developing this management system. We were a blank piece of white paper about the new technology, and he was taken to the ditch.

The third way to learn new technology is to read the source code of the new technology. It is a pity that you are not familiar with the new technology, and the source code of the new technology itself is even more complicated. You can't see the progress in the dark, and you want to give up.

Therefore, to learn new technologies, it is best to learn third-party foreign open source code based on new technologies. They understand new technologies quickly and deeply. They do not apply new technologies to try new technologies or to show new technologies. They are used to complete a practical product. In order to extract a widget, we read almost all the source code of the control package and figured out the structure of the source code. Otherwise, we cannot determine what we missed or whether there will be bugs.

However, looking back, the method is correct, but the timing is wrong.

We are new teams, new products, and new technologies. Many of our products are not yet clear, but we have applied the controls we obtained after learning new technologies to our formal products and serve as the basic applications. This has brought almost a catastrophic blow to future development. In the end, I spent a lot of effort to reconstruct and stabilize the infrastructure. Otherwise, the infrastructure will collapse and the above applications will be unmanageable.

Therefore, I try my best to restrict the use of new technologies. That is to say, it will not make new products, new teams, and new technologies appear at the same time, causing too much risk. And never use new technologies as the basic technology.

We also made a mistake, that is, when we officially developed the basic framework, we first developed it. We all know the importance of a basic system framework. However, we use the new technology we have just learned to develop the basic framework that our business modules will depend on in depth in the future. I think of a company's strategic development of Large-Scale Products: using the new technology Java, everyone is still a new team and new products. All programmers have closed the development process, someone proposed a basic framework that has never been verified by commercial applications, and implemented a small demo. As soon as you read this demo, we decided to apply this basic framework to the entire product line.

I think their pain is similar to me. Therefore, if I am faced with new products, new teams, and old technologies, I will not let everyone develop the basic framework as soon as they get started.

Last year, I was faced with an old team, old technology, but a new generation of product development.

The specific situation is that, after several years of development, our existing products gradually become aging, so we decided to develop a new generation of products. The previous generation of products have a C/S structure and are suitable for single customers. This time, we need to develop a B/S structure and it is suitable for group customers.

Let the development team of the previous generation continue to maintain the previous generation of products. Let the new generation of development be implemented by the new development team. Therefore, we recruited a new team (at that time, the company had a different interest conflict group for developing new products, and we had not reached an agreement yet. The recruitment of a new team was designed to prepare for the development of a new generation of products, there are also other purposes, which often lead to two extremes in the creation process of this new team: either several people are in charge of it, or no matter what ). At the beginning, we did not design and develop a new generation of systems. Instead, we developed one or two other IT projects for our customers. Therefore, we have been engaged in the customer industry, and it takes nearly eight months for everyone to work together. This is an old team.

However, this team does not have a deep understanding of the customers and existing products. Although I have explained the business to the team many times, I have also asked you to analyze and learn the existing products and read the existing product manuals, according to the new business model, we also organized everyone to analyze the business design features and write the functional design manuals. However, the understanding is indeed not satisfactory, and most people still seem to understand. Unfortunately, under the boss's plan, the new generation of system development must be started.

If you do not understand the application code to be written on the basic framework at this time, the basic framework will become a form, I think this basic framework is useless in the future application code, and it is not suitable for use. It is not as seed as a screw to a nut.

Therefore, I first arranged for the team to develop system management tools. This is a development job that does not have specific services and is common and is also part of the basic framework. However, because system management tools involve the new organizational structure mode and the new permission control mode, this is not familiar to everyone. In addition, the encoding architecture style is not the same as that of their previous development. As a result, the development process is always challenging. You need to review the code in real time and answer questions in real time.

After the development is completed, we held a summary meeting. Everyone summed up their experiences in this development and discussed how to solve such problems later. The Division of Labor and Personnel Work together for each person to confirm again, the purpose of the functions and functions is once again explained to everyone, and the benefits and intentions of the new encoding architecture style are explained again. Everyone said: if we make these points clear before development, then development will not encounter so many problems. I said: I did this before development, but we don't understand it. After this experience, you will understand.

What should I do next?

I said: re-develop the system management tool. It takes 10 working days.

Everyone gave a sigh of relief. Why re-development?

I told you about my experiences. I said: system management tools are a part of the basic framework and are commonly used tools by users in the future, however, this tool was developed in an unfamiliar stage. How can we deliver such important basic functions to our customers? Especially in the future, this tool will be combined with the system. The data structure of this tool cannot support many connections in the future. You have seen a lot of regrets. We cannot step together to be a lame man.

You asked: Can we still use the previous code?

I said: you need it. I do not agree that you should try your best to use the past code or recode all. If you want to transform a code with a disability into a good code, I say it is impossible. Many defects in the past will hold you down. In order to keep the code in the past, you will compromise the past and bring in the silk defects. Every feature has a small tail, so the defects of all developed features are a big problem. So you can copy the data as needed.

Indeed, programmers who have understood clearly the functions and purpose of the functions developed quickly. After all, they all wrote a system management tool, which is also an old technology and team. Complete the work in half a month.

I asked: how much code did you use for the last system management tool?

They replied that less than 20%. I understood the idea and wrote it quickly. There was no difficult technology at all. I originally wanted to copy the old Code and found that the old code is associated and cannot be extracted completely. It is better to write a new one.

I said: Okay. In the next step, we will implement the simplest and more marginal business subsystem in our system. During development, we found out what public functions are needed and extracted them to form a part of our basic framework.

This simple business subsystem was developed, and I held a summary meeting.

Everyone spoke enthusiastically this time: I have finally discovered the association between system management tools and business subsystems. They have a lot of code to share. As this development business is simple, and after the development of the last system management tool, the development methods and code methods have been familiar with it, and they have a deep understanding of system management tools, so this time when I was developing a business system, I also reconstructed the code of the previous system management tool and found many parts that can be shared. I found that after these basic codes are summarized, it seems that the system management tool is also a special service subsystem developed based on these public codes, all subsystems depend on this basic code framework. In the past, the style of the system management tool was inconsistent with that of the business subsystem. This restructuring was all unified.

I smiled happily. It seems that my past knot can finally be solved.