阅读作业（2）

对于读过的几篇论文/博客，个人感觉最有趣的是A Generation Lost in the Bazzar，最受益的是The New Methodology & Managing the development of large software systems，最无聊的是No Silver Bullet.

无论是日渐淘汰的瀑布模型，还是近几年新兴的敏捷方法，不管其流行与否，都值得计算机专业的学生去接触，作为软件工程方法学的启蒙。无论今后从事理论研究还是工程实践，团队集体coding是免不了的吧！既然有合作，那就一定有技巧，就能够跟软件工程沾边，这也是我最初选上软工的原因。

对于两大软件开发方法：“瀑布模型”与“敏捷模型”，我对两者的直观感受是：

1. 瀑布模型：强调开发过程的规范性，它一改code&fix的原始局面，通过一系列标准化的流程对团队的开发过程进行规范。它是一个框架，使用该模型指导软件开发的团队必须遵守之。它定义了严格的文档规范与迭代过程，在适用于小项目或者崭新的项目时显得过于僵化臃肿，因此，“瀑布模型”适合规范化的系统软件的开发（一如Winstion在NASA做的事情）
2. 敏捷模型：在我看来，敏捷模型的诞生是因为the nature of software development：

a) 需求的不可预见性->敏捷方法的适应性

b) 软件是由程序员开发的->敏捷方法的面向人而不是面向过程

Martin Fowler在the new methodology中将敏捷方法与瀑布模型等工程性方法区分开来，认为敏捷方法更能够应对客户需求的变化，同时它更“强调开发组的技能”而不是各种繁文缛节式的过程。

A Generation Lost in the Bazzar讲了一个很有趣的事实：开源浪潮下软件开发的乱象——软件质量参差不齐，软件之间依赖关系混乱，过度重用导致的过度设计……这些，是我之前所不曾想到的，我从最近才开始使用开源系统（CentOS），对开源界的Big Bazaar知之甚少。记得刚开始使用Linux，对安装一个软件需要先安装其依赖感到很神奇：为什么我在windows下没用碰到过这样的情况？想必这应该是开源界的规矩，同时也应该是其优势所在，然而，依赖的乱象却让开源界走向碎片化。对于这篇文章，我的理解还比较浅显，估计等到自己深入Linux多时后再回读，该会有更深刻的见解。

至于Frederick Brooks说教般的No Silver Bullet，我只想说，我当初是怎样用大半个下午坚持读完它的…..一方面叹其之枯燥，一方面感其之陈旧，FB将OOP视为Hopes for silver bullet，可能是我等未用过C写过软件的学生所感触不到的吧….不过另一方面，我不解他老人家为何想到Artificial Intelligence与Expert System，这两个看上去与软工风马牛不相及的事务，也许，在那个年代，也曾经被视为软件开发的下一个转折点吧。

 

项目收获

下面结合阅读材料谈谈我的项目收获。

经历了半个学习的学习，我对软工最大的感触是：1+1<2，一份完整工作，如果分配到每个成员去做，效率可能不如自己完成。从感觉良好的个人项目，到时间紧迫的结对编程，再到sprint到让人疲乏的学霸。。。。我只想说，PM比DEV难当！！！！PM就像天天扯着嗓子向作家催稿的编辑，费口舌之余自己还得完成手头分配的coding任务。除此之外，感想如下：

Big Ball of Mud

以我之见，代码的重复性（duplication）应该算得上是软件系统中的一个大泥球，一旦一处更改，殃及全局，在我们项目中，也有这样的情况，比如下图所示的标签列表：

这是在几乎所有web页面中都会出现的组件，在我们的alpha版本里，我们采用了最简单的方式：复制粘贴来为每一个页面生成这样的列表，那么，但是，潜在的问题也十分严重，一旦此列表需要重新编码，那么所有页面中的模块将推到重来。为了解决这个Big Mud，我们打算在beta版本中，将其编码为asp.net的内置控件，实现模块化的使用。

 

关于“大集市中的迷失”

一坨脓包似的权宜代码，被一群盲目的根本不知IT架构为何物的所谓IT“专业人士”永无休止地复制着，粘贴着。

值得庆幸的是，在我们的项目里，还没有出现包依赖混乱的情况，虽然我们的解决方案分为多个子工程，但工程之间的依赖关系十分明确，从DAL到BLL，再到最终的界面（View）。

同时，虽然我们也采用了第三方的开源类库（jquery，FlexPaper，tiny_mce等）但它们都是备受业界好评的知名解决方案，其源代码不存在如上所述的“权宜”情况。但是，必须承认的是，在在线文档阅读模块中，我们采用的一段FlexPaper Demo中的代码可能会存在潜在的性能与安全上的问题。

 

软件构建的方式

我们的团队，在PM的带领下，从一开始就采取了较优的设计方案，即数据层（Data Access Layer），业务逻辑层（Business Logic Layer）与展示层（View Layer）三层分开，三位成员各司其职，相互配合。这样，我们就能够在构建界面的同时并行进行业务逻辑的编码。较为优秀的软件构建方式使得我们的开发工作有条不紊地进行

 

Agile Method在项目中的使用

到目前为止，我们项目中所使用的敏捷方法，还仅仅局限在MSF版本的Scrum/Sprint方法上，我个人感觉，TFS提供的支持，对PM最大的帮助在于：能够对当前团队的任务进度有着直观的了解，这样，他就能够根据大家的任务完成情况，适当reshuffle，或者加快进度，或者减慢进度。这种模式，与传统的code&fix相比，避免了由于进度松散造成的任务积压。在我看来，可控的进度，对于PM乃至整个项目而言，都至关重要。