Summary of Software Engineering m1/m2 and summary of reading work

I. Summary of software engineering m1/m2

When we write down this summary, our software project is not yet complete. Although he tried to apply for a deferred reply, it failed in the end. This means that the normal release of our project is in a delicate state. It may or may not be possible. Just do your best.

The development of the whole semester, I in software engineering experience the deepest is the cost problem and technical debt. Previously written items often do not have a particularly strict deadline, a lot of personal with the Hing and write things, do not write. or homework, up to 1000 lines, how can be finished. and software engineering This course of the team project, 7 people, a complete website, especially for us this 4 group of co-operation of the big guy, and the previous writing things is not a concept at all. Therefore, the need for team management, design needs, everyone's efforts.

Let's talk about cost first. Our project has made a very "bold" decision from the outset, and we are determined to rewrite the project in its entirety. Reason we think very well: Seniors code pit More, analysis code takes a lot of time, technology stack too old and so on. Now it seems that the decision is somewhat dictionary. There was no such a struggle, and we did not feel that the cost of rewriting was high, and that we were extremely confident in the strength of our own team. If I were to make this decision now, I would certainly not be as thoughtless as I was, though I might still be inclined to refactor the whole project with a new technology stack. Migration scenarios, how to coordinate with other groups, development capabilities, team organization capabilities, and so on, should be taken into account in all aspects. At the time, when only a few points were considered, it was decided to rewrite the whole project. It was not until later that it was slowly understood that some of the costs and costs of something were quite high.

In addition, in addition to development costs, I also personally experienced the cost of software modification and technical debt. Our second phase almost reconstructs all the code, and the original HTML and some Python code are mostly migrated to the JS/JSX code, in other words, our M2 phase has almost all the functionality rewritten again. The result is a solution to a problem left over from the first phase: the convergence of four groups. In the initial design, we were not aware of the complexities of inter-group connectivity early on. In the M1 phase, when we really encountered the problem of convergence, and was stuck in the problem, only to find the seriousness of the problem. Despite the efforts of the team, tenacious completion of the first phase of development, but also for the second stage left a big problem: we have to complete the second phase of inter-group convergence. As an architect, it was only when the design was redesigned that it was quite costly to fix the errors that were originally made at the design stage. To share the backend with the app group, we need to migrate the entire Django template-based site into a single-page, Reactjs-based application, while the majority of the previous search and data sections are changed to SOLR. In order to fully connect with the other groups. This scheme is a relatively minor change for four groups, with the first two groups simply inserting the results into SOLR, but the front end, the app and the front end of the web, needs to be dramatically changed to fit a unified backend. Among them, the most changes in the Web-site.

In fact, it is not without a simple bridging scheme: for example, the development of a small program, the second set of databases to insert the model into our database. In this way, development costs can be much smaller. But the full size of the code to become a big mud ball, especially the chaotic HTML and JS, are telling me that if this is written down, then, will become more and more unable to maintain. Perhaps in the so-called feelings or some unclear emotions, in the end, we decided to adopt a bold and perfect solution. It may be expensive, but the scalability and maintainability of the architecture are good, and the technology stack is new and beautiful. This way, the next time you take over, you don't have to worry about how to perfectly connect, how to extend the existing functionality. And, we hope, within a few years, this architecture will adapt well to new needs and technical hotspots: distribution, cloud, front-end mode changes, and so on.

Finally, I want to summarize the team. The M2 stage is a huge test for the team. M2 stage due to serious lack of time, the pressure on the team is very large. Some teams even give up on a collective. Or there are only one or two people remaining tenacious to support the team. Our team's ability to easily re-form pages into single-page applications is also very much related to the characteristics of our team. All of our teams are very reliable, and this is not only an attitude, but also a competency. Team members are highly capable and able to meet the challenges of new technologies. In addition, each team member is in charge, the task assigned to do their best to complete. So the team is able to accept some new technology. The experience of this soft work made me realize that what kind of team to do. If the ability of the team itself is limited, then the problem of team competence should be taken into account when designing the project initially.

Second, reading homework

Question Blog Link: http://www.cnblogs.com/fzyz999/p/4831068.html

Please explain what questions are now clear, please clarify how to read, practice, or discuss to find out.

1. Is software engineering the right direction for more accurate and reliable software? The goal of software engineering is to make it possible to accomplish the target in a reasonable amount of time and with sufficient quality through the engineering method. But the recent re-prevalence of functional languages has also made people wonder whether there are other ways to build the right software? Some of the current pure functional languages can even use some tools to prove machine-aided. If we can describe the behavior and characteristics of the software in a formalized way, then the machine can be aided to prove that the software is correct. SeL4, for example, is the micro-kernel that proves its correctness in this way. The procedure obtained in this way is more reliable than a simple test. So is this a mainstream direction for future development? Will software development gradually shift from handicraft to a more industrialized model? Can we not only create "good enough" software, but also create exactly the right program?

Not clear. It feels like a big problem. After the software engineering study, the feeling will be more things, understand more knowledge, but the future of the development of the direction, or can not give their own views. Perhaps the answer to this question will be clear as the study progresses further and the understanding of things becomes more profound.

2. How much does code review mean in the personal software development process? The code itself is written by ourselves, and many of the logic errors that exist in our design are not likely to be discovered by review. After all, we once thought that the logic was right. Individual review can only deal with hand errors or momentary negligence, but for some fundamental design problems, may not be able to. So if we go directly to the unit testing phase, directly through debugging errors to locate the logic problem in the code, is it more cost-effective than the review?

The TA gave an answer in the comments and I think the answer is reasonable. It's important to revisit your code over time. After the software engineering also has this experience, the project at the beginning of a lot of things will not be used, the latter slowly used to mature, understand too much, and then look at the code before, do feel that the code before it is some bad. As a result, code review also makes sense in the personal software development process.

3. In view of the recent outbreak of information security issues, we can from the perspective of software engineering to propose some countermeasures? For example, in the design, review and other stages of the existence of some methods can greatly improve the security of software?

If security is a necessary requirement, then we should use security as a requirement when we first design it. The design and analysis phases need to be designed accordingly. In addition, the teacher in the comment area of the answer is also worthy of reference. Especially after the recent Xcode ghost outbreak, we should do our best to download the appropriate tool software from the official website.

4. In the Law on construction, we focus on some of the problems faced by a general development team. So is there a difference, or even the exact opposite, of a team that is clearly different from a traditional business software team like the open source community? Are there any differences in quality control, bug fixes, user experience, and so on in open source projects?

The problem is still not understood. Although individuals are passionate about open source, they have not been involved in the development of large open source software communities. There is a lack of understanding of the open source Community model, so the question remains unanswered.

5. User requirements are often changing. How do we grasp the scope of the software to be extended? Or, what kind of design is reasonable? How does it lead to over-design? How to grasp the degree of extensibility?

For a change in demand, we should probably adopt a rapid prototyping approach. Make the software quick, then let the user discover the problems and requirements, and then, depending on the user's recommendations, decide which parts are scalable and where they don't need to be expanded.

May I ask your request/design/implementation/test/release/maintenance in the project?
Stage (altogether 6 stages) learned what "knowledge points", each stage as long as a knowledge point can be explained.

Requirements Phase: Demand analysis needs to fully analyze what features are focused, which functions can be cut off, what the user really needs.

Design phase: The design phase is particularly important! The design phase is especially important! The design phase is especially important! It's important to say three times. In particular, the interface design, architecture design and so on, once the error will be faced with great changes.

Implementation phase: The implementation phase is focused on controlling progress. If the progress control is not good, the last item may crash or skip the ticket.

Testing phase: The focus of the testing phase is on automation. Automatic testing and so on are important.

Release phase: Products released during the release phase must undergo rigorous testing, otherwise the user experience will be very bad.

Maintenance phase: The maintenance phase is extremely dependent on testing and must be rigorously tested to ensure that the code is not degraded after maintenance.

Summary of Software Engineering m1/m2 and summary of reading work