个人阅读作业2

这次的阅读作业，由于之前没有没太重视，真正开始看才发现内容真的不少，导致阅读的时候看的也不是很详细吧，也就简单总结一下对这些文章内容的理解与体会吧。

 

1、  No Silver Bullet: Essence and Accidents of Software Engineering

by Frederick P. Brooks, Jr.

这篇文章主要介绍了软件编写的难度。总的来说，编写软件的难度，在于其规格，设计以及对概念结构的测试，而不是在如何具体实现与测试。

具体来说，来自于软件编写的四个特性。

（1）复杂性。软件中各个部分都有它本身的复杂性，且比较难以抽象出来，而整体的复杂性跟远远大于各部分之和，它的整体难度随着其规模的增长呈现非线性增长，大大增加的软件编写的难度。

（2）一致性。软件编写是一个整体工作，而分配给多个人或者一个团队时，虽然各编写人员能够同时编写，加快工作进度，但是编写时必须保证整个项目的一致性，如各个接口之间的统一，这也很大程度上使软件编写找不到很好的降低难度的方法。

（3）易变性。软件编写工作，始终是为了完成一项工作，最后得出一个能够满足要求的软件。而对一个软件需求又总是会随时间以及各种外部原因而改变，同时，因为软件使用过程以及使用设备的不同，也必须对软件进行必要的各种调整，这也使得软件编写完成了也不能算是真正的成功了，也加大了难度。

（4）不可见性。软件编写工作不像一些具体科学一样可以很好的将问题抽象出来，然后建立相应的模型去解决。软件不易抽象具体，很大程度上考验着软件编写人员。

 

文章中当然也提到了一些可能的用来解决软件编写问题的方法，如使用高级编程语言，采用分时的概念，或者使用统一的编程环境等，但这些也只能在一定程度上时软件编写的过程多一些便利，而不是在本质上解决软件编写过程中遇到的各种问题。

作者还介绍了一些将来可能用来解决软件编写问题的方法，如使用其他高级编程语言，采用面向对象编程的思想，人工智能，专家系统，自动化编程，图形编程，程序验证和工作站。这些都是一些不错的发展方向，期待未来在这些方面能有好的进展。

最后作者提到了解决软件编写问题的根本方法，还是要靠好的程序设计员。最关键的还是要看人。

就我来说，编写程序、软件时也因为种种原因，遇到各种令我头疼的问题，问题的来源也不外乎作者提到的那几种。像对这个程序整体的把握不到位，想把各个部分整合起来时又发现各种不一致等等，面对这些问题，也试着想各种方法去解决，不过往往到最后自己花了好长时间想来想去，找个同学问一下却很快解决了。感觉最后关键还是在自己的编程能力啊。

 

2、  There Is a Silver Bullet

by Brad J. Cox

这篇文章，标题就算是与上面一篇交相呼应。作者认为有“银色子弹”。文中主要介绍了面向对象的编程思想，对面向对象的方法、技术作了很详细的介绍与说明。作者也将软件工程与许多其他方面作了比较来类比说明。

对于面向对象的思想，上学期也专门有一门ＯＯ课程，对此也已经有了不少了解。就这学期软件工程的个人项目作业来说，也使用了面向对象的方法，要完成对指定目录的单词查询，通过将程序中的各个对象分开，针对这些对象来编写相应的程序结构，使程序结构清晰了，也很多程度上简化了我编写代码的过程吧。之后的结对编程作业也是，电梯调度程序，将程序按对象分成电梯类，调度类，乘客类等来逐个编写串联起来程序，整个过程能够比较有效地逐步实现完成。

 

3、Big Ball of Mud

   by Brian Foote and Joseph Yoder

文章主要介绍了“大泥球”——杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。

作者详细说明了“大泥球”产生的原因。

（1）有些本来就打算只用一次的代码，草率随意的编写出来后，虽然结构混乱，但用了觉得挺好用的，就干脆继续用下去，知道出现问题时，就直接去改这部分的问题，而不是重新从头设计一个结构良好，规则有序的项目。久而久之，这就成为了一个“大泥球”。

（2）有些尽管已经有清晰结构、明确框架的程序，在面对外界各种不断变化的需求时，也常常不得已慢慢的被破坏，最后甚至失控。

（3）对于一个已经建立的项目，为了使它继续运作下去，对它的部分不断做出改变，导致其结构也就越来越混乱，最后也就成为了一个“大泥球”。

这些原因，看上去也是不得已而为之，也是因为背后也很多不得已的因素。

（1）时间。尽管可能一个项目已经设计好了一个很好的框架结构，但是往往没有足够的时间去实现，也就不得已只能选择一个平庸的架构。

（2）代价。一个好的架构要花费很高的代价，而许多投资开发的人员却往往不乐于在这方面投入很多。

（3）经验。一个好的架构对设计者有很高的要求，设计人员可能因为自己经验不足，难以设计出良好的系统架构。

（4）能力。与经验类似，对设计者的能力要求也是一个重要因素。

（5）可见性。架构往往在人们看不见的地方，很难直观的判断它的好坏，也就因此经常被人们忽略。

（6）复杂性。应用的内在复杂性导致了体系结构的更加混乱复杂。

（7）变化。当前设计的架构主要是针对当前的需求，未来的变化很难预测。

（8）规模。项目的规模也让架构显得过于繁杂。

 

对于“大泥球”问题，以前这方面考略的确实不多，也是因为自己之前没怎么参加编写过什么大的工程项目吧。也就不怎么能体会到一个比较大的程序的架构的重要性。但在这次的团队作业中，还是要尽量避免让我们团队的工程也成为一个“大泥球”吧。看了作者说到的“大泥球”产生的各种原因，我觉得，有些地方我们是要多注意的。因为我们团队做的项目是MOOC的手机客户端，而我们是将具体的工作分配给团队中的各个个人，因此编写过程中的交流协调就显得尤为重要，定时讨论沟通彼此的进展与完成情况，努力做到及时解决出现的问题，避免程序到最后混乱不堪。

 

4、The Cathedral and the Bazaar

   from Wikipedia

这个维基百科链接介绍了一本书——《The Cathedral and the Bazaar》。在这本书中，主要讨论了两种不同的自由软件开发模式。

（1）大教堂模式。源代码在软件发行后公开，但在软件的每个版本开发过程中是由一个专属的团队所控管的。

（2）市集模式。源代码在开发过程中即在互联网上公开，供人检视及开发。

 

就我们团队而言，采用的算是大教堂模式。由我们团队开发负责工程的源代码。

 

5、A Generation Lost in the Bazaar

   by Poul-Henning Kamp

这篇文章中作者首先提到了10多年前，IT行业爆发式增长，而绝大部分——99%都如泡沫般破灭了，因为他们过于相信Raymond在《大教堂与集市》中鼓吹的集市模式，学习计算机编程时满足于表面，都认为“对付过去就行”，严重的缺乏基本功。作者也提到关于代码重用问题，举了不少例子，批判了在编写代码时盲目重用已有代码的行为。作者赞扬认同Brooks提出的观点，“质量，只有在某人对它负责时才有意义，而这个“某人”只能是一个人，不能是几个人——二重奏除外。”

我们的团队工作中，因为我们采用的是大教堂模式开发，没有作者所说的第一个问题。虽然我们团队成员间的代码编写能力也各有差距，就我来说，编写代码的基本功也远远不够扎实。而关于代码重用行为，我们的项目是写一个安卓版的MOOC手机客户端，用作参考的有一个之前学长写的ios版的，两者之间在很多方面还是有不小的差距的，也不会盲目的用学长的代码。

 

6、The Rise of ``Worse is Better''

by Richard Gabriel

文中作者首先介绍了编写代码的两种方法，MIT方法和New Jersey方法，或者说是，“the right thing”和“worse-is-better”，虽然两者的只是稍有不同，相较于前者，“worse-is-better”中实现过程的简单比接口更重要，且简单比正确更好一点，一致性和完整性也可以在一定程度上做出让步。

作者认为，“worse-is-better”是一种更好的编程思想。

（1）能够满足大部分设备，对设备要求低。

（2）在小型机器和大型机器上都能移植。

（3）有利于集成。

 

7、Is Worse Really Better?

by Richard Gabriel

这篇文章与上面一篇是同一个作者，作者在这篇文章中，主要还是进一步说明了“worse-is-better”思想的优越性。能更快速的编写，能被移植到更多的电脑上，能更快地被接受并能不断提高，也更适合程序员。作者还通过C++的例子，更说明了它的优点。

 

8、The New Methodology

by Martin Fowler

这篇文章主要介绍了敏捷型方法以及其“适应性”与“面向人”的特点。

具体介绍我也就不展开了，我主要讲讲我们团队工作中用到的敏捷思想和做法。

（1）SCRUM。我们将整个项目分为为期一周左右的三个迭代阶段，每个阶段都有工作的安排与计划，而在每个阶段中，定期举行会议讨论各自的工作进展与各自工作中遇到的问题。

（2）结对编程。我们基本将一项任务交给两个人搭档完成，共同编写这一部分的代码，完成项目中这一部分的功能。

 

9、Why Software Development Methodologies Suck

   by 乔梁

文章针对一些认为软件开发方法论糟糕的论调，分析解释反驳了他们。首先作者提出来两条常用有效的法则——划小开发周期以及提升反馈效率。文中提到说明了要找合适的开发者以及软件项目开发困难的原因。最后，作者强调了开发团队中学习能力与适应能力的重要性。

 

而从文章下面的评论中，大家也基本同意作者的观点，一个团队中的成员因为各自本身的各种差异，很难将工作安排分配地很好，但应用这些软件开发的方法论，或多或少能使团队更好地协作与运转，从而使软件开发的过程能够更有效率。

 

要求阅读的文章中，关于“瀑布模型”的两篇文章不在这里，（还没有阅读），而软件工程方法论的另一篇文章链接好像有问题，也没阅读。下次找时间再看吧。