[Personal blog Job Week7] Software engineering team Project thoughts and Reflections

After reading the recommended reading material, I thought a lot of things. Finally decided to take the experience of the team project as the main line, describing my thoughts and experience on software engineering.

Phoenix Nirvana, Shower fire Rebirth

If I were to profile the experience of the team project over the past few weeks, then the sentence would be the most appropriate statement I could think of. From the initial ambition, to the middle of the misery, to the present like the joy of rebirth, our whole team has gone through too much.

Re-build the wheel

Wheels, in the software industry, often refer to libraries, frameworks, or reusable code that are designed to handle common functions. The re-creation of the wheel means that, in the case of already available "wheels", they re-implement their own "wheels." Some people often say that it is a silly act to reinvent the wheel. Already have the ready code to solve the problem, can work, why do we have to re-build the wheel? Others believe that the re-creation of the wheel often leads to an improvement. For example, when the design of an existing library does not meet the actual requirements, the re-building of the wheel may produce more advanced and high-quality wheels. So it is worth encouraging to re-build the wheels.

At the beginning of our project, as the architect of the team, I thought for a long time. We have the complete code left over from the previous session. With a little bit of patching and deployment, that code can do a lot of work. Although the interface is very ugly, part of the function is afraid there are many problems, but after all, is 8,000 lines of code, a few years of lessons accumulated things. With them, our work can be a lot easier. But there's also a problem with this ease : There's a certain number of bugs left in the code, and the test's little partner says the problem is not small. The previous document also mentions that they found that a lot of features were not implemented, there were some interfaces and so on, and they were tuned for a long time. Documents are not aligned, the original developers are not in the project, the use of the technology is relatively old-fashioned. And this code after years of development, mend repair finishing, like reading material in the big mud ball, who is hard to say what the state of the code now look like. In such a case, should we re-build the wheel and overturn it again?

Even now, I still cannot measure, the choice was right or not. But after going through the process of re-building the wheels, I had a deeper idea of how to build the wheels. The most painful thing about making a wheel is that we need to re-implement the original function and not rely on what. So the cost of making a wheel is so high that it is obvious. Now it seems that our understanding of this is too immature. With a sense of self-confidence, we think that we can use 2000 lines of Python to achieve the original 8000 lines of code, and now in retrospect, it is really feel a bit too conceited. But the complete rewrite also brings unexpected benefits, and we've used the newer technologies to achieve a lot of functionality at a lower cost, and the entire framework is easy to implement new functionality or to re-implement the original functionality. Something that looks very complicated can be easily solved by using a modern framework. Our system currently uses a large number of distributed technologies to improve performance by adding nodes. This is difficult to achieve by refactoring the original code. These fresh technologies also bring a lot of fresh design and vibrant power. We have adopted a framework that contains a lot of modern design ideas. These ideas also penetrate into our designs through these frameworks. We follow some of the design principles they provide, understand many of their design concepts, and try to apply these design philosophies. In this process, I think the overall feeling of our whole project is much better than the original project. Team members are also very motivated and will clap their hands whenever a new feature is achieved or something fresh is used. Because it's a new start, without the historical burden of legacy code, we can use the tools we want without worrying about the history burden.

Summing up, I think the advantage of reinventing the wheel is that there is no historical burden, the idea is more daring to open up, can bring some revolutionary changes to some projects. The use of the original system, you can "stand high, looking far." The tradeoff between the two is something that needs to be considered more carefully and thoughtfully, and the next conclusion is that it will provoke unexpected trouble. As we are now, from the initial choice to abandon the old code, to re-build the wheel, to the present, just realize how far-reaching the original decision impact, the question to be considered how complex. Maybe some things, experience before will know the depth. How to weigh the pros and cons, how to evaluate the plan, maybe the next time we do it, we will be a lot more mature and cautious.

Team management and development methodology

There is no "silver bullet" in software engineering. I quite agree with this view. From the previous pair programming, to the current agile development. All methods have a range of applications. Pair programming, for example, has certain requirements for both the character and the relationship of the pair. Two a person to pinch the kind of meeting, or not knot on the efficiency of high. The agile development We adopt now has a strong requirement for the decomposition, distribution, coordination of personnel and the relationship between roles. And that's not necessarily easy for a team to achieve. For example, between PM and programmer, is a very tangled set of relationships. Normally, PM is responsible for coordinating work, project macro direction, tracking progress, etc., but if the programmer is relatively strong, then PM's work is often difficult to carry out. PM can not grasp the basic direction of the project, and programmers are loosely developed without organization. In addition to PM and programmers, the relationship between roles such as testing, UI, and so on, can be a bottleneck for the entire project.

The reading material says, " someone is responsible for quality ". After a round of team project development, I very much agree with this view. And, I think, there are two levels of responsibility here: first, there is a specific person responsible for dealing with this matter. Second, this person has the ability to handle good this matter. The first layer is relatively obvious, a task must be assigned to a fixed person, otherwise, if the task is not claimed, it is naturally difficult to expect it to be well done. Like a tree that no one talks to, although the last can grow up, but compared to the garden workers carefully cared for seedlings, the shape of its appearance and so will have some degree of disparity. The second tier is an understanding that I have come across after a team project. The so-called responsibility is not to say that someone is assigned to someone. This person must be able to be responsible for . For example, you assign a primary school student to a task such as completing an advanced math exercise. Although a specific person is assigned to handle it, it is clear that it is not at all able to be responsible for it. Even if he had finally made it, it was hard to change it again and again, and it was still difficult to fix it. This is the meaning of ability to be responsible .

This is the most painful lesson our team has ever faced. Although we are required to open daily meeting every day, sometimes encountered problems, several people also often strung dormitory discussion, but did not explicitly designate the person in charge. So, there is a wave of loose records, not formal words, but has not been integrated. Specially responsible for the maintenance of the students are very serious about the content of the person, the quality is not enough will never go. As a result, the daily document was dragged down, causing serious consequences. Now, if I had been able to designate a specific person and have enough people to take charge of the matter, it might not have happened in the end. We have been working on our team projects in a market-style way, most of which are on our own initiative. Most of the people in the team are very active, and most of the tasks have clear people to really take charge. So it's going very well. However, the problems faced by the market-style approach, we naturally inevitably encountered. Moreover, we did not even notice that this became a problem in time. The cathedral-style development was designed for everything, and the development was completed in a methodical manner. The market style is more like a noisy bazaar, and each person chooses his or her own task to be interested in. We have successfully adopted a market-style model to complete several high-quality works. A first draft, a person reviewing iteration updates, a person re-examining the typesetting, and so on, everyone is deeply involved in the whole process out of the complex emotions of personal responsibility, honor and interest. Although there is no very clear arrangement, but everyone has taken the initiative to undertake a certain part of the task. We built a church in the market. However, this build is conditional , as the author of the cathedral and the bazaar sums it up:

1) The project must first of all be of interest to you, but it will ultimately be useful to other people.

2) Use the user as a partner.

3) as soon as possible and constantly make improvements, listen to the views of users.

4) A robust structure is far more important than an ingenious design. In other words, the structure is the first, the function is the second bit.

5) Maintain the simplicity of the project. When the design is perfect, it is not impossible to add more things, but can no longer reduce the things.

Previous successes have led us to fail to identify some of the essential things that are described above, which leads to the subsequent problems. I think the main thing is the first: the project must first be interested in you and ultimately useful to others. Previously built a series of documents, from the team for the text has a persistent pursuit of youth efforts, but also from the team's own development and design needs, therefore, everyone involved in a more in-depth. In particular, some of the documents that each member can use, such as design documentation, requirements analysis, and so on. However, we do not recognize the role of the meeting minutes of the ' Daily Council ' and therefore no one is interested in it. We all feel that this thing seems not so important, not giving too much attention. Now, in retrospect, I think this is indeed a violation of the first condition above: The project must first of all be interested in itself. What no one wants to pay attention to is naturally difficult to do in a market-style way. So, at this time, the bazaar did not play any role, and the market-style we had always relied on became the culprit of low quality.

After so many, I think we still need to stick to the market-style model We have always relied on, and it is the cornerstone of our success. But on top of that, we have to find another way to deal with situations that do not apply to it. In my opinion, a development model suitable for our team is like this: for each task or demand, we should try to use the market-style idea to complete it first. But at the same time, we should set a warning period . If there is still no improvement over this time, then the market pattern is no longer applicable to this task or requirement. We should synthesize the views of all parties and choose a particular person who is competent enough to complete the task. Let him be responsible for this, in order to produce enough quality. Thus avoiding the tragic result of a direct crash after market-style failure .

Conclusion

A few weeks of team project development, we go from the climax to the trough, and then we step up again. The ups and downs of the process, let us more fully aware of what is right, and what is the problem. The road ahead of our team is still difficult, but I think we have found the right model. In the next round of development, we are able to apply these experiences and insights, and run small steps to reach a higher level.

[Personal blog Job Week7] Software engineering team Project thoughts and Reflections