原载：http://blog.csdn.net/netcasper/article/details/326890

学开发，只看软件工程著作是不够的

近日看了两篇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

原载：http://blog.csdn.net/netcasper/article/details/259791

团队协作能力

曾经有这样的感受，与某些人合作非常舒服，而与另外一些人在一起就像是噩梦。我相信，这不仅体现了一种态度，更是一种能力，也许就是传说中的“团队协作能力”吧。尽管团队协作能力非常重要，但大多数人对它的理解十分有限，我就为此困惑过、苦恼过。

隐约觉得，团队协作能力并不是一种可以轻松掌握的能力，仅仅有协作的愿望更是不够的。说起来有些尴尬，如此重要的一种能力，我们竟然说不出它到底指什么，更不知如何衡量、如何学习，有种听天由命的感觉。

一个人的力量是有限的，只有大家携起手来，才能取得更大的成就，而团队协作能力则能够确保众人的合力大于单个人的力量。对于如此重要的一种能力，决不能这样听之任之，一定要不断地学习、锻炼。

XP十分强调metaphor的作用，一个准确、形象的metaphor可以让人迅速理解、掌握问题的本质。

足球是我最喜欢的运动，喜欢看，也喜欢踢（虽然已经很久没踢过了）。足球场上四种角色——前锋、中场、后卫和门将，一共11个人组成了一支球队。通常一名球员只以一种角色出现，但是他不仅要与角色相同的同伴协作，更要与其它角色的队友一起为争取比赛的胜利而努力。每名球员不仅要清楚自身角色的职责，还要明白其它角色在战术上存在的意义和相应的作用，因为他必须通过与其它角色交互来获得比赛的胜利。他不仅要在抽象的概念上明白一支球队是如何通过分工协作来完成整场比赛的，还要掌握具体的技术细节以完成相应的战术要求。在此基础上，如果球员提高个人技战术能力，成为对球队拥有显著影响力的球星，就可以增强整个团队的实力。更加完美的是，球员们还能感受到球队整体打法存在的问题，并通过不断地尝试形成新的风格。当年，伴随着全攻全守、防守反击这样的新式打法横扫足坛的，必然是一支伟大球队的诞生。

我想，团队也应该和球队一样，要想成为具有生产力的团队，其成员必须既理解整个系统运作的抽象模型，也有能力完成自身角色所赋予的职责，这两种能力加在一起就是“团队协作能力”。一名伟大的成员则不仅可以通过不断增强个人能力来增强团队按照模型运作的能力，还会随着实力和经验的积累推动系统运作模型的演化。

知道了什么是“团队协作能力”，如何学习、训练就是自然而然的事情了。两手抓，两手都要硬。之所以将对系统抽象运作模型的理解提升到如此的高度，是因为成员交互过程中很多的矛盾、冲突来源于系统固有的缺陷，不随成员的变化而变化。对于这样的矛盾，我们应本着对事不对人的态度来处理、解决。