"软件工程"与"软件工艺"，孰是孰非

      近来"软件工程"与"软件工艺"是非曲直之争颇为激烈，"软件工程"支持者大骂"软件工艺"离经背道，"软件工艺"支持者口口声声要放弃"软件工程"。自《Software Craftsmanship》的中译本《软件工艺》出版后，在国内软件界也掀起了一阵涟漪。本文阐述本人的一家之见，希望有助于平息不必要之争论。
      计算机界的泰山北斗Fred Brooks在其1986年的著名论文《No Silver Bullet - Essence and Accident in Software Engineering》（《没有银弹-软件工程中的根本和次要问题》）中，论述了软件工程试图解决两种类型的问题，一种是由软件开发内在本质所固有的复杂性、一致性、可变性及不可见性所决定的问题，故称为根本问题（essence），这些根本问题决定了不存在一种单纯的技术或管理上的进步，能在短时间内（10年）显著提升软件开发的效率和质量。近20年过去了，Brooks的这个论断似乎是正确的。另一种问题是诸如解决软件构建等的次要问题（accident），之所以是次要问题，是由于解决这些问题只能提升整个软件开发过程的很小一部分效率。可见，和很多人一样，Brooks眼中的"软件工程"的含义十分宽广，软件开发中几乎一切的技术及管理问题都可以纳入"软件工程"的范畴。这个承载着软件开发方法的方方面面的软件工程，我姑且称之为"广义软件工程"。
      Pete McBreen在《Software Craftsmanship》（国内有人在"craftsmanship"的翻译问题上争论得不可开交，有人说翻译成"工艺"不好， software engineering和software craftsmanship其实都是隐喻，一个代名词而已，在这个问题上争论不休大可不必，关键是中译本内容应尽量反映原文意思）一书中提倡以"软件工艺"这个新的隐喻代替"软件工程"隐喻，因为"软件工程"隐喻会导致人们钟情于"'有组织、可计量'的软件开发过程"，迷信那些高成本的所谓标准软件开发过程，使软件开发方法僵硬化、信条化，而"软件工艺"隐喻会引导人们重新重视人的因素，强调个体经验、技艺的重要性。在我看来，Pete McBreen在书中多处批判的软件工程，套用Fred Brooks的语汇，就是只专注于那些确定的、可计量的次要问题，而忽略软件开发本身所固有的复杂的、一致的、可变的、不可见的根本问题的软件工程，我姑且称之为"狭义软件工程"。而软件工艺最关注的问题实际就是软件工程中的根本问题，正因为其内在的复杂性、一致性、可变性和不可见性，人们甚至还不能对这些问题进行清晰的描述和分析，也就更无法确定化、可计量化， "狭义软件工程"对于这些"模糊不清"的问题要么视而不见，要么觉得无足轻重，而实际这些根本问题才是决定软件开发项目成败的关键。
      因而，软件工艺所批判的是厚此而薄彼、舍本而逐末的"狭义软件工程"，而不是Fred Brooks以及很多人眼中的"广义软件工程"，因为"广义软件工程"承认软件开发的不确定性、模糊性，并承认这些不确定性和模糊性是软件开发本身的固有属性，因而不存在一种包治百病的灵丹妙药（即Fred Brooks所说的"银弹"）。软件工艺希望以另一种隐喻以避免软件工程隐喻所带来的一些危害，它提出了一条不同的思路，提供了一套不同的方法，在"广义软件工程"的大舞台上，应该有它的用武之地。
      "软件工程"与"软件工艺"之间门派之争的问题在于，人们对"软件工程"本身的含义、范围有不同的理解，争来争去孰知争的不是同一样东西，此软件工程不是彼软件工程也！
      语言是思想的镜子，它只能局部地反映思想，并把思想的一部分放大了、一部分缩小了、一部分歪曲了，甚至会反过来欺骗了思想本身。看来在软件工程的根本问题当中，人类语言的局限性也许占了一席之地。