首页 > 代码库 > 个人阅读作业2

个人阅读作业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

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

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

 

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 乔梁

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

 

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

 

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

个人阅读作业2