学开发，只看软件工程著作是不够的近日看了两篇IEEE Software上的文章，讲述开发软件究竟需要哪些知识，以及怎样学习。
[1]中提到，如果你希望通过阅读软件工程著作了解和学习如何开发软件的话，恐怕难以如愿，因为这类著作更愿意关注一些轻量级的内容，如项目管理、软件开发过程改进、进度和成本估计等等，而软件开发本身由于是整个软件工程生命周期中最难以理解、也是理解得最少的一部分，所以只能抽象地讲讲，甚至被完全忽略。
然后，文中列出了一系列技术问题，并指出，只有在设计和编码的前前后后解决了这些技术问题，才能使开发和维护工作更轻松。我觉得其中最精彩的部分是"Considerations before design"一节，作者认为在设计前所有开发人员必须掌握两方面的知识——problem-domain expertise and solution-domain expertise。业务知识的重要性就不用多说了，现在网上不知多少文章劝告那些将近30岁的开发人员不要一味钻研技术，要想赚大钱必须对业务特别熟悉。对此我不敢苟同，能够理解和能够描述之间还是有很大差距的，何况任何技术都有它自己的局限性。比如“庖丁解牛”这个典故，它说明的是对牛的结构越清楚，肢解的速度越快，对刀的损耗也越小。然而，如果连刀背刀刃都分不清楚，又如何来解牛呢，即使对牛再了解。当然，刀作为一种解牛的工具其复杂度是很低的，很容易掌握，它与软件开发技术的复杂度是不能比的，可偏偏就有很多人在无视、否认软件开发技术的复杂性。
那么，为什么软件工程教科书都不教这些知识呢?[2]给出的解释是，首先，业务知识与软件无关，它超出了软件工程学的范畴；其次，能在程序设计语言手册、系统文档、以及库手册上找到的技术知识往往过于具体、涉及过多的细节，而更多的技术知识甚至只存在于一个个程序员的经验当中，还没有被总结出来作为一种可以教授的知识。文中还提到，除了这两类知识外，problem-solution integration expertise也是不应忽视的。否则，岂不成了“纸上谈兵”！根本不知如何运用的知识又怎么能算知识呢？
课本不教，大家是从哪里学来的呢？“人类是如何学习的”是心理学研究的问题之一，一般来讲，有两种学习的方式，从书本上学和从实践中学。既然没法教，我们也只好摸着石头过河了。
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 tentatively answered to permit the programmer to put a structure in place. [2]那么，老师们又能做点什么呢？ 作者提出了四点建议，其中最后一点是：
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.知道了学什么，以及如何学，“大家有没有感到这个世界美好了许多啊？！”
[1]. James A. Wittaker and Steven Atkin, Software Engineering Is Not Enough, IEEE Software Vol. 19, No. 4
[2]. Nicholas Zvegintzov, Do We Know Enough to Each Software Engineering?, IEEE Software Vol. 20, No. 5
