Modern software engineering students are dreaming of springgreen

"What the code can't do is just a unique innovation of the project ". The dream code has finally finished reading the dream code. In fact, the whole book is about the uncertain nature of the Turing Machine-in the software development process, many processes do not know when it will end or even whether it can be made, as a result, the entire software project cannot be stopped. Isn't it a "downtime problem "? It's a joke. The problem isn't that simple, or Scott Rosenberg's book won't sell well. What I'm most interested in is how to read the English version of this book within 10 hours, because I just finished half of the Chinese version in 10 hours, and I only know about it. I have to say that I am not very used to the writing style of the author. Writing plain text in narrative style will inevitably cause a lot of inconvenience to information extraction, to put it bluntly, there are too many "nonsense" in the article, so that you can't really find what you are talking about in class, such as "feature driven. However, Scott Rosenberg is really a god man. He can show such a very rational thing in such a humorous way without losing his profound cultural heritage, so that the full text will go smoothly, it shows your talents in project management and code writing. There is also a reason to get the support of so many readers. Mengjie Code describes the four-year development process of this software based on the main clue of the process of developing the PIM software called Chandler developed by Alibaba F. This dream is not very beautiful, it is actually painful. Typical Problems in the software development process can be found in the changler development process. However, this book mainly aims to explain how to effectively cope with changes to the project goals caused by the surge in expectations due to the development of productivity. Such changes are usually unpredictable, it seems that you are playing an unfair game with you. You are in the bright corner, but he is in the dark-passive is always you. 1. Believe that if a software project has no pursuit, it can be mediocre, so it is difficult to encounter various difficulties in the development process of Chandler. This is not the scope of the author's consideration. If the author wishes to develop a software program, it must have a "killer" feature, such as the Lotus 1-2-3 mentioned in the article, this is the source of target changes in software development. Software must be different from other software features, rather than simply copying, we do not want to make copies. I think capur, the main character in the development process of Chandler, firmly believes that "the soul of Agenda" is a seemingly unfinished feature. He hopes that Pim can freely integrate personal data, this "arbitrary" will make people unable to touch the edge. However, it was capur's belief that he had been able to move forward with changler for six years at the FGM (caspur seems to have withdrawn funds from changler f at the beginning of this year, but Chandler seems to be still moving forward ). 2. A lot of questions one by one seem simple, but they are hard to solve. For example, the question of "code reuse" is whether to reuse the results of others, or start from scratch, which is a bit like the choice of hampir. As mentioned in this article, "code reuse" is actually very difficult, because no two identical leaves are available, and no function is completely the same. Even if there is applicable code, how to find it in the vast library is also a problem. In fact, "code reuse" is a little different from the belief in software. Repeating others' achievements is still self-innovation. However, the article still gives the answer: "What the code can't do, it is just a distinctive innovation of the project ". The most common problem encountered during software development is that the project progress lags far behind the plan ". The Chandler plan is 3 ~ A version is released in four months, but it takes more than six months for each version. There are many reasons for this. First, it is very difficult to reasonably measure the development progress, that is, the plan itself is too harsh. Even checking the progress of software development is a very painful task. The number of codes or the number of defects reduced is used to measure bias. The mbwa method is mentioned in this article, however, this method is difficult to get a general development progress. The second is that the software development plan is often beyond the foreseeable scope, so that software development stays in the design stage, citing a sentence in the text, "using today's tools and processes, with the memory limit of yesterday, we can really do better ". In addition, it is Software defects. during the development process, Chandler seems to have fallen into the quarary of defects. They spent a lot of time repairing Software defects, how to Reduce defects in the software development process is also a big concern. There is also a need to pay attention to the developer's mentality. If the software remains in the design stage for a long time without any programs or even code, it is easy to make people pessimistic and will affect the development of productivity. In this article, I recorded a very interesting but helpless thing. During the release of Chandler 0.2, the publisher begged everyone not to download or even publicize it in the blog, the reason is that Chandler 0.2 is an almost unusable version. But why? "If there is no intermediate version term, it will lead to wandering around the land full of various encoding possibilities ". 3. We need to overcome the difficulties. Of course, the author does not simply list the problems in the development of Chandler, but also puts forward some methods and precautions in the development process. The author attaches great importance to the choice of methods. Different methods should be adopted for situations that do not work. He said, "It is possible to decide what tools and methods are used to achieve or destroy the project ". The first is how to design the project objectives. This is in conflict with the belief of the project. The ideal is to build a very good software, but in many cases it is not enough. If the project is too large, it is easy to bury itself. There is an interesting conversation in this article: "Do you have any suggestions for those who are just starting a large open-source project ?" "Don't make big projects ". In the design process of Chandler, karpur insisted on the idea of "The Soul of Agenda", but the reality was a constant. Later, he only expected to make a "dog food version", but "dog food version" is a luxury. In fact, everyone hopes to see that their efforts have substantial results. Making a "dog food version" is conducive to the achievement of a larger goal. "Make available software as soon as possible" (in the original article, "dog food version" refers to a version for your own use, derived from an advertisement by an American dog food company, the boss of the company uses his own dog food to feed his dog) followed by schedule management, which is unpredictable in software engineering. The first is the difficulty in measuring the progress, and the number of code and defects cannot be reduced. There are many stubborn defects in the software process and it is difficult to solve them quickly at present. In addition, it is difficult to coordinate between people. For example, a new member is added and new member training is required. For example, a project manager is replaced. The article mentions "feature-driven" and "Progress-driven". In the actual management process, the two have both, but the focus is not correct. The author carefully explains whether to use mandatory progress discipline for management: This depends on the situation. Some programmers do not like forced management, so it is best not to use forced discipline. If you want to perform mandatory Progress Management, you must evaluate the progress based on the "bottom-up" method. For example, CMM management in the text. There are also defects. In the current programming mode, code is first compiled, and then defects are corrected. In fact, it is difficult to write code without defects. Intuitively, this is also the case in this article. The higher the cost, the later the defect is corrected during the development process. Therefore, defects should be discovered as soon as possible. The following describes how to reduce defects, such as the "spiral model", "Extreme Programming", and "Zul testing. The author also mentioned the idea of OOD, which should be reasonably abstract and modularized, and encourage the use of code annotations. (In fact, code comments can well vent your emotions ~~) Of course, members of a project naturally need to communicate with each other. There are many communication methods, such as using blogs and wikis, but do not forget some informal communication methods, for example, communicate with each other on the "chiller" side. ------- By Hu weifrom http://springgreen9527.spaces.live.com/default.aspx? _ C11_blogpart_blogpart = blogview & _ c = blogpart & SA = 43775437