文道，武道

这次的博客的作业分为阅读和联系自身实践两个部分，在这里我想把他们分别叫做“文道”和“武道”。大约是和文字以及实际的操练相对应的。（当然文道和武道最初是出自孔老先生的《礼记》的，是形容治国方略的张弛有道，宽严相济，这里使用纯粹是因为思想遨游）。喜爱国学的人大约都知道范仲淹和王阳明吧，两个人是古代士人的典范，因为他们既是文臣又是武将，我们计算机专业的从业人员其实也应该有这种文武相济的思想，业界所说的“软硬结合”估计就是对这一思想的专业化的表述吧，在这次博客的作业里我又一次接受了这种思想的洗礼。

 

文道：

（1）银弹：

第一次接触“silver bullet”的时候感觉略微激动，因为与它有关的异域的民间故事让我想到了《暮光之城》里的狼人，但是电影里的狼人是正派的，而软件工程师们要遇到的“狼人”却和民间故事里的狼人一样的骇人，非技术型的经理眼中的简单直白的软件工程，可能成为工程师们眼中的梦魇，用Brooks的话来讲就是“a monster of missed schedules, blown budgets, and flawed products”。会不会有那么一个可以飞快降低软件开发成本的“silver bullet”呢？他能像消灭狼人一样的高效地降低软件开发成本呢？答案是没有银弹。Brooks仿照亚里士多德的分类原则将软件的困难分为固有属性和外部事故。人们的不断努力使得外部事故造成的困难越来越不显著，但是软件系统固有的复杂性、连续性、可变性、不可见性却难以解决，于是最终的结论是没有银弹。（a sad story for most programmers）

 

（2）大泥球：

大泥球是指那些随意堆砌的，杂乱的代码部分。主要的原因在于一次性代码和碎片式增长的代码太多。在读大泥球的时候我发现或许我们的敏捷模式会给大泥球的产生提供很好的温床，因为我们的敏捷模式是适应变化的，对于计划性的要求没有那么强烈，在这样的情况下很容易产生为了实现某一个功能而在原有的代码基础上添加大段代码形成“计划”之外的冲击，而在诸多的功能堆砌之后也没有了想要重构代码使之更规范的想法。

 

（3）大教堂与集市：

所谓的大教堂就是指软件不同版本的源代码都是可见的，但是开发软件的不同的版本的人员是固定的封闭的。就像是教堂里的礼拜一样，是要有固定的特殊的信仰的一类人群才可以做的，不是随意的路人就可以为之的。

所谓的集市顾名思义，是指那些对任何人都没有限制的，完全对外开放的软件项目。就像是集市里面的购物人员一样，既可以是厅堂政要又可以是黎民百姓。

 

（4）瀑布模型：

所谓的瀑布模型按照罗杰老师的介绍是指将软件开发周期设定为几个固定的阶段，每一个阶段的输出会作为下一个阶段的输入，在直觉上可以看做是瀑布的水流逐级下落，于是有了瀑布模型的称号。他的优点是只要固定节点的检测通过那么就可以保关注软件的后续节点即可，前续节点可以不被关心了，但是瀑布模型的一个突出的缺点是不适应用户需求的变化，一个重要的原因在于只有在软件设计的后期才能看到软件的结果，但是需求分析在前期就已经做完了。于是在适应用户需求变更上，瀑布模型的优势不大。

 

（5）敏捷之道：

按照Martin Fowler的归纳，敏捷的两个非常重要的特点在于非预测性和适应性，以及以人为本。它能够对客户的需求的变更产生及时有效的响应；它试图使软件开发工作顺应人的天性而非逆之，它强调软件开发应当是一项愉快的活动。

 

 武道：

1、对于我们的软件开发团队而言，我们采用的是大教堂式的开发方式，我们的项目还在初期，采用这种内部的开发方式，我们认为是有利于我们软件的成长的，就像是一个孩子在没有成年之前，或者说在没有得到足够的教育之前他的父母是不会轻易让他出去适应社会生活的，对于一个软件而言，团队的开发者有这样的心态也纯属正常。

 

2、我们的项目还在初期阶段，于是代码量不是非常大，所以以我现在的眼光去看还没有发现明显的大泥球，要是有的话估计就是“小泥球”了，但是我感觉随着迭代轮数的加深，随着功能的叠加和软降版本的继续推进，包括开发人员职能的调动，以及不同的人员对同一个文件进行更改，大泥球的现象一定会产生，因为我们对于软件开发流程并不是很有经验，对于资深工程师都会有的问题我们不敢拍着胸脯说没有，但是我们为这种情况的出现也做好了准备，毕竟这是一个学习的过程嘛，发现问题比没有问题更正常，也更能让人印象深刻。

 

3、在敏捷开发的过程中我们确实体会到了以人为本的乐趣，据我所知，我们的团队在scrum meeting的形式上应该是最好的了，我们会把所有的人员召集在一起来一个face to face的交谈，而不是借助网络。我们会在早餐或午餐或晚餐或者是宵夜的时间段叫出来所有的成员用心体验这个meeting的过程，大家会相互交流问题，部署下一级的分工，我们会在这个过程中对于我们整体的项目的架构有很好的了解，有问题当面解决，援疑质理，我们认为这种方式的效率非常高。我们团队成员的感情也得到了加深，相互增进了理解，我想这个过程真的是体现出了以人为本的本质---人文关怀和交流沟通。同时我们的开发人员也可以大胆尝试自己的新技术，从而达到增进用户体验的目的，比如我们的phobia助手就是在Google开源了Tensor flow之后我们受到了人工智能的启示而添加的功能，技术人员在这期间也满足了自己的尝试的欲望，我觉得没有比这个过程更加exciting的了，也没有比这个过程更加family-like的了。（只是遗憾的是，我们没有及时以scrum meeting的形式发布到博客上，使得老师们误以为我们没有这个过程，感觉好桑心。。。）

 

 

文武之道：

对于计算机专业的人员来讲，没有实践的理论是学而不思，没有理论的实践是思而不学，孔老夫子曾说这两者都是有殆，有害的。经历了软工的开发过程反过来读这些理论感觉精辟至极，我们团队里的架构师鸣神曾经说过“软件工程理论是将工程化的东西概念化了”。我现在想来，感觉十分有道理。确实，软件工程本身就是基于实践而出现的，他的所有的理论都是为了解决实际问题而提出的，如果没有实践那就不知道问题提出的背景，如果没有实践那就不知道如何将理论应用于解决问题的过程，可见在我们软件工程的学习中实践的地位不可置疑。而将实践的经验概念化成理论则又是对工程实践的最高要求。由此来看我们的软件工程已经十分接近哲学啦~~~