双倍赤裸裸的真理——评《软件工艺》

如果说有什么书能够代表我的思想，那么无过于《软件工艺》这本书了。做过这么多年软件开发，没有一本讲软件工程的书（无论是 CMM、RUP、还是 XP）能够令我信服。我们总是在软件工程的圈子里划地为牢，迷信一个又一个伟大的软件过程，从 CMM/CMMI 到 RUP 再到 XP，浪费了如此多的精力却收获寥寥。这时候一本《软件工艺》的小书进入了我的视野。其实买这本书只是因为我有藏书癖，而且这本书的翻译是出自我所信任的透明。但是我并没有对这本书抱很大的期望，也没有打算马上读它。

今天这本书到手了，因为时间有限只翻了翻前言部分，我已经被惊呆了！因为所有的话几乎都是我想要说的话。我在论坛如此多次地反对 CMM、质疑 RUP 和 XP、提倡重视代码（请见“家传秘方”帖），所要说的不过就是《软件工艺》这本书所告诉我们的事实。赤裸裸的事实，虽然会让某些脑中有贵恙的学者专家们感到不舒服，但是确实是不容否认的事实。以前我说《人件》告诉我们的是赤裸裸的真理，现在我要说《软件工艺》告诉我们的是双倍赤裸裸的真理（很抱歉我这里语言的贫乏）。

建议大家有空了都去读读这本书。不是为透明做广告，而是这本书确实是所有软件从业者在职业生涯之初就应该读的书。这样的书还有：
《人月神话》
《人件》
《解析极限编程》

我以前说过，有些书是能够让你获得智慧的书，这样的书应该尽量早读。当然不是每个人都有慧根的，那些泥足深陷于软件工程的张半仙、李半仙之流自然不在此列。

读这本书不需要耗费你太多的资源，它需要耗费的资源大约与你读一本《多情剑客无情剑》差不多。对，你没听错，你完全可以把它当作一本小说来读的。希望这个周末你就能找到它并且度过一个愉快的周末。

我是学机械的，工程和工艺其实都是来自于工程专业领域。以我对工程和工艺的理解，我不太赞同dlee你的观点。
   工程是从整体上来看待问题的，而工艺是从细节上看待问题的。其实这两者缺一不可，我不想看着各位都走向极端。
   拿这个一个大制度，缺始终无法做出合格的零件，这样的工程是可悲的（可是中国的软件工程的确如dlee所说浮躁得很，就喜欢做出制度）；而有一群细致的师傅确无法搭建一台像样的汽车，这样的工艺是遗憾的（在构筑大应用的时候，工程的概念和作用就体现出来了。）
    当然，就中国目前的情况，就大多数项目系统的情况，要先抓工艺，工艺抓好了，才可能有好的工程，而盲目地应用工程，只会导致效率的严重降低，人发挥的严重制约。不过当工艺发展到一定地步，就需要工程去提高系统的价值了。
   说到这，我又倾向于dlee，不过，始终希望大家不要走向两个极端。

《人件》和《人月神话》粗略地看过一些，不过听dlee这么一说，还真的好好坐下来看看，思考思考了

我不太喜欢这种类型的书，讲老实话，这本书缺少底蕴，类似于消遣（流行？小资？）一类的东东，在gigix翻这本书之前（时候）我已经和他聊过了。

关于这个作者也是可疑的很，他后面还有一本书Questioning Extreme Programming，简直完全推翻了了这本书中的绝大多数论点。但不是因为质疑XP，而是因为质疑XP（事实上他不太有资格，因为从QEP可以看到他对XP并不是十分了解）的同时把软件工艺的观点也反了。

我也是学机械的，不是我不想强调工艺，工艺有它的作用。正如凤舞凰扬大大所说的，工艺注重的是细节，步骤性很强。但就软件而言，是系统级的，首先要求我们从整体来看待问题，这些可以看看weinberg的《系统思维导论》，我想象dlee大大这样的层级，想想就明白了。
不过我还没有看过那本随手可以拿来看看的《软件工艺》（我想这是gigix的话吧），不会这上面说的工艺与机械中的工艺有所不同吧。不过这本书还是在我的下次的购书计划中的

工程，工艺。

如果从字面的意思出发，就如凤舞凰扬所说的他们面向的范畴不同，强调工程和强调工艺两者应该是没有冲突的。

传统行业这两部分分的比较开，一个高级技术工人和一个设计师的一般是没有交集的，当我们强调设计很重要时，没有人会因此怀疑一个高级焊工的重要性。

然而在软件行业中这两者是有交集的，人们往往同时充当设计师和实际开发者等多种角色。或者这是纯粹脑力劳动的特点，使得人员的分工不再那么绝对，从而带来新的冲突。

可能我对这本书有些过誉了，确实是我的不严肃。我会在读完这本书再写一些感想。这本书我只准备为它分配一天时间（一个周日），因为比起《重构》、《测试驱动开发》这样一类书来说对我工作的帮助毕竟是很小的，可能通篇都是些我早已知道的事情。
XP 不管怎么说已经比 CMM 的过程好多了。我质疑 XP 不是完全反对 XP，而是发现 XP 在我们这种资源严重受限的环境下仍然无法有效地开展（主要还是开发人员的能力达不到，但是这种能力的提高是很缓慢的事情，我们又必须要依靠这些开发人员完成我们的工作）。

不过我现在对于工艺和过程的优先级来说肯定是把工艺放在过程之前的。道理谁都明白，没能力做出来的东西即使采用再好的过程仍然做不出来。所以一个软件公司最值得尊敬的是那些技艺精湛的老程序员（铁匠铺里的老师傅）。凤舞凰扬因为软件工程的书看的比较多，把这些人的能力矮化了，实际上这些人已经达到合格的系统架构师的层次，而不是只会对某个细节精益求精的人了。这样的人就应该一直做技术层面的工作，而不是学而优则仕地去做管理。当然收入分配也应该适当向这些人倾斜。我见过一些 PM 完全脱离了开发（甚至还有连需求都不认真做的），只会跟在屁股后面催进度，变成了真正的监工。这些人由于自身开发经验的缺乏，完全无法准确地估算工作量，控制项目的进度和质量。我并不认为这样的人对公司是有很大贡献的。从软件工艺的角度来建立一个公司员工能力和贡献大小的衡量体系是非常合理的，也是让员工更容易接受的一种方式（干的多干的好拿的也多，你有意见吗？）。

to albert_qhd：
刚送走了印度模式，现在又出来了日本模式。只能冷笑两声了，看看谁笑到最后，我可是一个极有耐心的人。:wink:
至少从职位上来说，我现在已经不是程序员了。potian、gigix、o6z 等朋友也都不是程序员。我现在仍然在编程，并且从来不认为自称是一个程序员会辱没我的身份。

我也不认为程序员辱没身份，工作就要发现工作中的乐趣
软件工程、软件工艺一个用规范来约束，一个用道德来规范。就像依法依国和依德治国，我不认为两者那个有错，关键在于社会的发展程度。

在中国很多公司文档一踏湖涂，代码一塌糊涂的情况下，单纯强调软件工艺时机未到

to albert_qhd：
你真的觉得日本那种开发方式能够让我们的程序员享受到乐趣吗？这种方式让我想到了《知识经济》中所说的头脑国家和躯干国家。这种开发方式和制造国外名牌服装有什么实质上的差别吗？

我们的程序员的素质还可以的，现在已经可以实行《软件工艺》中提倡的一些做法了。