Thoughts on "Project Development" and reading "Mythical man-month"-Kaka

Project development has finally ended. According to the project process, I should write a Project Development Summary Report. With the "GB856T--88" Standard documentation, there is a framework to guide me to write something, but how can these frameworks tie up the idea of freedom? So I decided to change the form.

When the project development is nearing the end, it is also the most critical time that someone sends a copy of the mythical man-month. I am lucky to be able to read this book at this time, because there will be a lot of thinking, about projects, about teams, about us ......

......

Perfection and abandonment

One section in the Mythical man-month was intercepted, known as "the hardships and joys of programmers", and has been widely circulated on the Internet. Master Brooks described the hardships and joys of the entire procedural world in a short space. In this project development, there are two obvious manifestations of distress.

First, the pursuit of perfection. "Because computers are doing tricks in this way: If a character or pause in the spoken language is not consistent with the correct form, the magic will not appear (in reality, few human activities require perfection, so humans are not used to it ). In fact, I think the most difficult part of learning programming is to adjust the way of doing things to the pursuit of perfection ."

It seems that I made the right choice again. I am a perfect person, and I have always thought that programmers should have this nature. When writing a program, I even have to think about a variable name until I select a variable that I think can express its meaning. I don't think this is a waste of time: First, it helps to understand and maintain the program. A good program itself is a comment; and second, it reduces the possibility of errors. Due to the short development time, I tried to write a program using the design-> encoding-> compilation method. I often started debugging after writing a module with thousands of lines of code. The results are good, because the design considerations are quite adequate, and they are basically spelling errors. However, I was troubled by one mistake for a long time. Because the member variable name of a structure is the same as the variable name of the function parameter, and this parameter is used in multiple places, when writing, it may also be when copying code, it is easy to forget or add a structure name to the structure name without any syntax errors. After learning this lesson, I checked the entire program and made some modifications. I am pleased with the prototype of a master I have referenced in this program. His next version has made the same changes as my program.

Another "distress comes from setting goals, providing resources, and providing information. Programmers have little control over their work environments and goals ." Later, the chapter mentions that "architects have gained the joy of all creative inventions, and deprived people of their creativity ". "Implementation is also a high-level creative activity. In actual implementation, the opportunities for creation and invention will be greatly reduced because external technical instructions are specified. On the contrary, creative activities will be enhanced due to standardization, as will the entire product ." Programmers must learn to give up a part of the fun, and the same is true for the entire project. This is what I feel most deeply when I read the Mythical man-month.

When designing Network Authentication, I plan to use a simple authentication method, because this is not the focus. Y proposes to use the certificate and its own socket class to implement the authentication communication process. This is a good idea, but the VC writing class cannot be used in Delphi, and BCB cannot. Encapsulation, callback ...... Everyone is confused. There are only two words left: "give up ".

Due to time constraints, the product features also gave up some ideas that are very creative, but not mentioned in the demand. Similar problems are also found in subsequent development. Each person calls and provides interfaces as he prefers. It can be said that the Eight Immortals pass through the sea and are different in their respective ways. The main problem lies in communication.

Good at communication

......

Man-month cannot be a myth because the increase in manpower also increases communication between people.

At the beginning of the project, we communicated through QQ groups. Later, we set up an internal collaboration platform for enterprises, and there were also irregular meetings. This is in line with the three communication channels mentioned by the master-informal channels, meetings, and work manuals. However, the execution results are not very satisfactory. What did the master say? No. We did not take advantage of these methods. We have made good use of the Meeting to solve many minor misunderstandings. When using QQ groups too much, I did not look at them carefully when I logged on to QQ, second, this method is very effective against small misunderstandings, but some systems must be fully understood through documents. However, collaboration platforms are rarely used and there is no habit of carefully reading documents, I have no habit of writing a complete document.

Even in the QQ group communication, the problem is not clearly stated. I often see: "XX: You have a problem there ?" Where? What's the problem? QQ is transmitted over UDP. Ack is not required here. If the other party is not online, you can transfer it through the server, send a post to the Forum, or directly send an email. Then someone replied, "Impossible ?" Everything can happen as long as the conditions are met. Domain names are not easy to fly. What else is impossible? If a problem occurs, first find the cause and find out the possibility.

......

Conclusion

This article is just a bit of my thoughts after I have developed the project and read the Mythical man-month. No one is right or wrong. If you have any correct ideas in this article, please discuss them with you. This article only follows the project process and describes some of the thoughts you have learned during development. This development has taught me too much and will benefit me for life. There are still many ideas, such as team building, overall design, and development model ...... I hope to have more exchanges and learn from each other in the future.

We recommend that you read this book "Mythical man-month. It is not a good medicine. It cannot solve problems in your actual work, but it can bring you a lot of thinking and make you more mature. Software Engineering serves the development of software. standards are not an aim, but a means. The Mythical man-month has no standards, but it provides some reference for how to build a project. It will enhance your self-confidence. When someone refuted your point of view, you can tell him: "Master Brooks said ^-^ ".

Http://kaka.rootcn.com/shadowstar/essay/engineering/thinking.html