Learning development, only see software engineering works is not enough
I have seen two articles on IEEE Software recently, which knows what kind of knowledge of development software, and how to learn.
[1] It is mentioned in [1] If you want to understand and learn how to develop software through reading software engineering, I am afraid that this kind of work is more willing to pay attention to some lightweight content, such as project management, software development process improvement, Progress and cost estimates, etc., and software development itself is the most difficult understanding of the entire software engineering life cycle, and it is also a least abstract, and even completely ignored.
Then, a series of technical issues are listed, and it is pointed out that the development and maintenance work can be made easier to develop these technical issues before and after the design and coding. I think the most exciting part is the "considering" section section, the author believes that all developers must master the two knowledge before design - problem-domain excertise and solvention-domain excertise. The importance of business knowledge is not to say more, and now I don't know how many articles advise those developers who are nearly 30 years old don't drink technologies. If you want to make big money, you must be familiar with your business. I don't dare to share it, I can understand and describe there is still a big gap between any techniques, any technology has its own limitations. For example, "Ding Ding Cow" This allusions, the more clear the structure of the cattle, the faster the dismembers, the smaller the loss of the knife. However, if the knife back blade is unclear, how to solve cattle, even if you know it. Of course, the knife is very low, which is very low. It is easy to master. It is not comparable to the complexity of software development technology. There are many people who are ignored, denying software development technology. Sex.
So, why don't I teach these knowledge? [2] The explanation given is that first, business knowledge is independent of software, it exceeds software engineering; secondly, you can design language manual, system documentation And the technical knowledge found on the library manual is often too specific, involving too many details, and more technical knowledge is only existing in the experience of one programmer, has not been summarized as a professor. In this paper, in addition to these two types of knowledge, Problem-Solution Integration Expertise should not be ignored. Otherwise, don't you become a "paper talk"! I don't know how to use knowledge, how can I use it?
The textbook is not taught, what is it from? "How to learn how human beings" is one of the problems of psychology research, generally speaking, there are two ways of learning - imitation and exploiting. Since we can't teach, we have only touched the stone over the river.
The practitioner is using his or her intelligence to find and then build linkages between the problem domain and the solution domain. As observers have noted, programming is an endless struggle with How? Why? What? Whether? And When? Typing takes place when enough Questions Are Tentative Answered To Permit The Programmer To Put A Structure In Place. [2]
So what do teachers can do? The author puts forward four suggestions, where the last point is:
Fourth, teach by doing. Software engineering is not book learning. Teach with problems and projects where students (and teachers) labor to build and modify nontrivial, even real, systems in working groups. Know what to learn and how to learn, "everyone Do you feel that this world is beautiful ?! "
[1]. James A. Wittaker and Steven Atkin, Software Engineering IS Not Enough, IEEE Software Vol. 19, No. 4 [2]. Nicholas ZVEGINTZOV, DOW WE KNOW ENOUGH TO EACH SOFTWARE ENGINEERING ?, IEEE Software Vol. 20, NO. 5
