Lessons Learned from Software Engineering
by admin
More than one month since U.A.T of CMPT 275 passed. We almost failed on it. But I have no time to write some experience and lessons learned from that until now, because I was busy with other things after I was back to China.
Oppose with what I thought before, writing a big software is really a kinda art. The most important thing for one to write a good software is the architecture design. And the most important thing for architecture design is requirement analysis. Coding is simple and should not bother a developer so much. Because if you have some technical problem while coding, you can refer the document for the programming language you are using and solve it quickly. But if you find that your design goes all wrong, you must delete almost all your code and do it again. So, a good designer is more important than is good programmer in your team. And things are always that a good designer is a good programmer himself.
And a crucial thing for your team is having a leader. This is always be true in real software developing scenarios, but not as in taking courses. If you have no leader, you will definitely waste much of your time on arguing. Every one thinks that his design is the best. If you have a leader, you can easily determine which architecture you will use and which style of GUI you will draw, and so on. Meanwhile, your leader must be a experienced programmer as well as a experienced designer. He always has a brief view on how could you achieve your goal with the least overhead.
Another import thing is that all of your team members should under each part of your project. Such like the one do GUI must have the knowledge of database, and the one who are implementing background algorithm must know the message observer stuff. Basically they are not related with each other, but I don’t want to hear requests like this again: “can you store the hash map in database table?”.
Besides, all of you should use the same tools, and follow the same coding style. Coding style is very important. We failed in this because there’s no leader forced us to do so. Everybody has his own style, and the only common style for us is that each line ended with a semicolon.
The last thing is about user interface. Never write a dialog-based program like us, unless you are doing a cell-phone program. Dialog-based program is ugly and slow. As Rui said, the program should based on a main-frame which will not be changed often, and many functions can be accessed via menu, what is we lost. Dialog is mainly used when a ‘dialog’ is needed, not everywhere.
Although I will not likely to be a industry programmer, I think it’s useful to have a good skill for software engineering, and maybe it will help me develop systems in the future.
Finally, I will thank my teammates here: Chris(Hopefully not misspell your name here, ), Meng, Ting, Ian, and Jeff!
After 1Y0-259, all those students who are not sure about 70-536 and 1Y0-456, should try for the qualifying exams like 1z0-042 or 642-892 in order to figure out their interests.