软件工艺读书笔记

第一次读到这样另类的书，刚开始读这本书的时候感觉笔者是一个非常讨厌使用软件工程的方法来开发软件的人。这种给我的感觉一直贯穿到我读完整本书，这本书是我用一个晚上的时间一口气读完的，理解上可能只限于表层，但就针对这表层的一点理解下面我来谈一下我的认识。

软件工艺这本书的笔者一直强调一个问题，那就是工匠在一个项目中的地位。工匠这个词听起来是一个很老的词了，在过去其他行业当中工匠是一个怎样的人群我就不说了，肯定是在某一领域做得很好的人，下面我解释一下软件工艺当中所提到的工匠究竟是怎样的一类人，软件工艺中提到的工匠其实就是具有非常丰富的开发经验，并且在多年的开发过程当中做出的产品受到客户的好评，具有一定信誉度的人，他们能够为用户提交坚固的、高质量的应用程序。一个优秀的工匠决定着一个项目的成败。这表明人的因素在项目的开发当中起着非常重要的作用。在没有学习软件工程之前我也一直认为人在软件开发当中有着很重要的地位，在学完软件工程之后让我认识到原来软件也可以像工程学一样有这流水线似地开发模式，人不是开发过程的主导，软件工程的主导是开发过程的控制，一个比较固定的过程，只要人做一些机械化的工作就可以完成项目。现在看完软件工艺这本书让我的思想出现了激烈的斗争，到底软件开发当中应该用软件工艺的思想还是软件工程的思想。在当前的大环境下软件工程的思想还是占有绝对的统治地位，但软件工艺的思想也有他的支撑阵营，例如开源社区的工作者。

首先我觉得笔者的思维很超前，在当前软件工程为主导的大环境下敢于反驳，仅这一点就是很多人做不到的，以前好像有位名人说过“尽信书不如无书”，但是真正能够对课本知识做出质疑的人又有几个，起码我还没有做到过。尤其像软件工程在当前的大环境下大家都在用或者学习这种软件的开发方式，并且这种开发方式在许多方面的确取得了很好的效果。这已经成为了业界对于软件开发的标准了，大家都对他深信不疑。这时软件工艺的倡导者大胆的站出来指出这种开发方式的弊端，尤其是我所读这本书的笔者将软件工程批判的体无完肤，他们敢于这样做的精神就很值得我们来学习，且不说软件工艺这种开发思想的正确性，就这种敢于推翻标准的勇气就是推动行业不断向前发展的动力。

软件工程是将工程学的思想引入到了软件开发的过程当中，软件工程含蓄的告诉我们：只要定义一个有组织、有纪律、可计量的开发过程，任何人都可以完成软件开发。在这里软件工程忽视了开发过程当中最为重要的一个因素“人”。我们知道软件开发过程当中需求是不断变化的，这一切的变化都是由人的因素而引发的，而这一因素是不可能确定化的，工程学却要求一个确定化的生产过程，这一点与软件开发的真实过程相背离，软件工艺的笔者正是抓住了软件工程这一致命的弱点来驳倒他，从而建立自己的开发体系。

软件工艺到底比软件工程优在哪些地方呢？

下面我简要的分析几点，一方面，软件工程重点关注的是软件开发的过程，而忽视参与到开发过程当中的人，这使得在开发过程当中使用大量的菜鸟来开发系统，这群人由于缺乏技能、知识和经验，由他们所开发的系统含有大量的缺陷，在排查缺陷方面由于缺乏经验，所以发现缺陷和改正缺陷的速度会很慢。软件工艺所倡导的是由几个有经验的工匠带领自己的学徒所组成的小团队来开发，这样有几个优秀的开发者所组成的团队他们在开发过程当中就会犯很少的错误，并且在查错和改错方面也比菜鸟要效率高很多。另一方面，软件工程的开发团队一般来说比较大，这是由于软件工程的思想认为在这个确定的开发过程当中不需要熟练地开发者，所以使用大量的菜鸟，这就是所谓的人海战术。在这样的一个大型开发团队当中要让开发者之间交流可以想象是多么困难的一件事，一个没有交流的开发过程简直就是软件开发的噩梦。而软件工艺所关注的重点对象是人，所以在软件工艺的开发过程当中需要的只是几个优秀的开发者，而这几个优秀的开发者可以及时的交流，进行头脑风暴，他们开发的效率比许多菜鸟聚在一起要高得多，并且优秀开发者所开发系统坚固性和质量肯定要更高。

下面要写的东西比较凌乱，就跟记笔记一样总结出这本书的一些精华内容，当然也会有我自己的一些看法。

什么是软件开发？

软件开发的全部意义在于解决未知的因素。获取明确和隐含的知识，并将这些知识具体化到软件之中这就是软件开发的整个过程。这里所说的获取明确和隐含的知识其实就是软件需求的获取，软件工艺所要求的开发团队当中的工匠就是一个有着丰富领域知识的人，他能够更好的把握软件的需求，这样也就把握了软件开发的全部意义，所以说一个优秀的开发者，也就是工匠他关系到整个项目的成败。

现如今很多项目最主要的困难是什么呢？

设计和实现都已经有了自动化的过程，不在是什么难题，现如今最困难的是需求分析阶段和需求分析阶段与软件设计之间的交流上。分析一下原因很简单，因为需求在软件开发过程当中是最不确定的阶段，不确定的东西最难获取了，上面也说了软件开发的全部意义在于解决未知的问题，也就是不确定的问题，如果这一问题能够很好的解决掉，那么软件开发也就没什么难得了。

软件开发分工好不好？

这里我首先给出答案，不好。同一件任务被切分成的小步骤越多，人与人之间传递信息所耗费的时间总量就越多。因此，在不需要交流的工作中，流水式的生产线能够运转得很好，但在需要大量交流的脑力劳动中，这种方式就一败涂地。软件工艺所强调的是开发人员参与到整个软件开发的过程当中，而且他的团队比较小，所以交流几乎不会浪费多少时间。这里有一点要求软件开发人员参与到整个开发过程似乎有点困难，这一点我个人也觉得很难办到，但是软件工艺对于团队和项目的大小有一定的约束条件，在这种约束条件下开发人员是很容易参与到整个软件开发过程的。

软件工艺对于团队和项目的大小的约束条件

在说明这个问题之前我先说一下软件工程和软件工艺所适应的应用范围。软件工程在当前的大环境下被各种各样的项目所采用，因为大家都认为这是一种行之有效的开发方法，但是软件工程的方法只在超大型项目的开发当中发挥了重要的作用，在一些较小的项目当中并没有我们所想象的那么成功。软件工艺正是看到软件工程的应用局限性所提出来的。软件工艺对于团队的要求是少而精，项目的大小适用于中小型的项目。正是由于软件工艺的团队都是优秀的开发者，所以他们可以在项目不是很大的情况下参与到整个的开发过程当中。

软件工艺如何辨识优秀开发者

在传统的软件工程中最常见的辨识开发人员等级的方法就是看你有没有一些认证或者从业执照之类的，软件工艺却完全否定了这一点，他认为任何执照都只是假象，因为这些颁发执照和证书的机构他们对被办法的对象并不了解，认证机构并不担保任何事情，所以他们的证书或执照都只是一中假象，软件工艺对于优秀者的发觉是通过同行认可和推荐的方式产生的。为什么这样的方式得到的开发这就一定是优秀的呢？这是因为软件工艺要求所有的推荐都是以私人的身份提出，因此没有人会轻率地做出推荐。在这样的同行推荐之下，相关的每个人都会努力提高自己的能力和信誉，力争成为更好的开发者。

软件工艺的工匠

在设计一件能够满足广大用户的产品时，最有效的办法就是针对单独的一个人进行设计，努力让这个人满意。这看上去似乎违反了直觉，但事实的确如此。软件工匠就是利用这种思想向“足够好”[1]的软件开发方式挑战。

优秀的软件应该签上开发者的名字，因为只有这样才能向用户传达一种信息：我们愿意为自己的作品负责。

让软件工匠因为自己的作品而获得荣誉，这样工匠就会在软件工艺模式下建立自己的声望，这声望也是以后其他客户选择工匠的一个标准。

好的开发者比管理者更有价值，软件工艺强调管理者应该将优秀的开发者作为知识工人来对待。他们应该以管理优秀开发者为荣。

软件工艺与软件工程的差异

1. 软件工艺带来的是协作式的开发，与软件工程相比，软件工艺的差异就在于：开发者将更好地理解对方，并能够帮助对方作出必要的权衡。

2. 软件工艺强调记忆的传授与学习。

软件工艺总结

软件工艺最主要强调的是人在整个项目中的重要作用，软件工艺对于团队的要求非常严格，团队首先人数很少，最多不会超过15人，一般的团队都是3人左右，但是对于团队中个人的能力要求很高，另外团队的健康度也有很高的要求，团队还要比较稳定，这样团队中的队员才能培养出默契来。

最后根据当前的实际情况谈一下软件工艺

软件工艺这本书给我们提出了很好的开发模式，但是当前大环境下很多项目开发都是采用的软件工程思想这是为什么呢？我分析主要原因是软件工艺对于团队的要求太高，而优秀工匠太少，所以很多公司很难组织起这样一支高效的团队。现在软件工艺的思想只在一些开源社区可以看到一些影子，因为在那些开源社区聚集了许多真正的工匠。这一点让我仿佛看到了ISO网络7层结构模型的影子。虽然模型做得很好，但就是由于实现难度太大而被放弃。

 

---

[1]开发的软件含有许多错误，但是拥有丰富的特性，用户可以为了丰富的特性而忍受错误