Principles of Software Engineering

#

“Think carefully before doing” is probably what I really need to keep in mind in the future. I am the kind of person who tries everything to accomplish a thing if I really want to do it; my mom says:” 九头牛都拉不回（Nine bulls cannot pull you back）!” In general, I am too confident about what I am doing, but lack of thoughts of how to do it. It is like I know how beautiful the view across the river is, and I know I need to go there; however, I may forget to come up with a solution to cross the river before I jump into it! This often happens during my exams, especially lab tests: I can come out with the correct direction to sole the problems, and generally know how to do it, and start doing, ignoring some details. It is lucky nothing goes wrong, however, life is not that simple. Some evil profs put tricky in tests, and it is too late for me to find out. I know I can do it but time is almost up, which is the worst feeling!– this is based on Prof Ben’s “More thinking, Less coding”.

As a student who dedicated to be a software engineer, it is important to know the principles of software engineering. This is what I think of the principles.

• Modularity/Decomposition:

This to break a huge projects into smaller parts. For a big projects, the jobs can be divided to designing and coding. And even for coding works, we can still break it down. This makes people focus on what’s he/she is doing, and also makes teasing and debugging easier. However, people still need to know what’s going on in the whole team, so he/she can foresee the process.

Besides easing peoples works, decomposition makes it possible to reuse code. So we can focus on the ideas instead of coding. I thinks this is the general idea of libraries.

• Abstraction:

The abstraction is based on modularity. This is to let others know what we do but how we do it. That can make those who use our codes happier, because they don’t need to know everything. Furthermore, it gives you the advantage because you know how to do it! People should come to you when they need it. Good? Not for money, but for feeling.

• Design for change:

This point is very essential, since IT is one of the fast developing fields. We cannot correctly predict what will happen in the future. The point is we should look forward the best, but do prepare for the worst. Nokia is really a counter example for not doing well in this point. (I may write another post regarding the mobile markets in the future, where interestingly Google bought Motolora.)

There is some thing I want to talk about NOC. I am really interested in this program. Compared to SEP, NOC provides with a chance to get hands dirty. However, I heard MOE makes this program not applicable for us, because in the past, some of companies our senior worked for paid off the bonds! Anyway, I will try to do well in this module, better fill my resume, and I am sure Prof Ben will help me if it is necessary.