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

个人阅读作业2

个人阅读作业2

这一个月参与了软件工程课的第一个团队项目的开发,再加上之前做过的个人项目和结对编程项目,对软件项目的开发也算是有了一些经历和体验。

软件工程的瀑布

瀑布模型:需求及设计阶段严谨的话,开发代价最少(对设计与代码品质要求很高,一旦开发完了后发生障害或设计变更,维护成本高)

软件工程中的瀑布模型,是软件工程中常用的过程模型,看过一些资料后,我的个人理解就是,瀑布模型就是像瀑布一样,从上而下的工作,每个阶段做每个阶段该做的事情,所需的东西完全由上面的阶段处理好,在开始实际的物理代码实现前,先着力做好逻辑模型的设计,确保无误后才进行实际的物理代码的编写。

个人感想:

我们团队可以说是部分采用了瀑布模型来进行编程吧,我们团队是在上一届学长编写的爬虫软件基础上进行改写,增加功能,许多功能之间是相互独立的,但是有些功能的实现相对比较复杂,于是就需要安排多人进行编写。那么首先就要先对逻辑模型做好分析,合理分配任务,在进行实际物理代码的编写,开始编写后,下层的人就要等待上一层的人编写完毕后,把代码交到手里才能进行编写。最后汇总功能,进行UI设计的人员也需要全部功能完成后再进行UI的设计与整合。比如我负责的就是UI的设计,整合时就发现了某个他人编写的功能模块存在问题,无法实现要求的功能,我就得要求他debug并修正功能,这就产生了返工。还好bug并不严重并且修改及时,时间也比较宽松,要是项目的deadline前最后一刻才交到我手上,那时候发现bug就很糟糕了。

结合我自己的经历,我觉得这种瀑布编程模型还是很适合我们团队采用的,我会建议大家好好学习并试用瀑布模型。

 

瀑布模型的特点有:

(1)阶段间具有顺序性和依赖性

必须等前一阶段的工作完成后,才能进行下一阶段的工作。因此,当前阶段的工作依赖于上一阶段的工作。就像让水倒着流回去很困难一样,若在当前阶段发现了问题,可能还需要倒着回去修正前面的代码,修正整个项目的代价会非常大。

(2)推迟实现的观点

瀑布模型尽可能推迟程序的物理实现,这是由于实践表明,对于规模较大的软件项目来说,往往编码开始得越早最终完成开发工作所需要的时间反而越长。前面阶段的工作没做或做得不扎实,过早地考虑进行程序实现,往往导致大量返工,有时甚至发生无法弥补的问题,带来灾难性后果。

瀑布模型在编码之前设置了系统分析与系统设计的各个阶段,分析与设计阶段的基本任务规定,在这两个阶段主要考虑目标系统的逻辑模型,不涉及软件的物理实现。

 (3)质量保证的观点

 在每个阶段的编写时,相关人员都必须准确,保质保量地完成规定的文档,并且在每个阶段完成时都要对所完成的文档进行评审,以便尽早发现问题,改正错误。各个阶段产生的文档是维护软件产品时必不可少的,没有文档的软件几乎是不可能维护的。遵守瀑布模型的文档约束,将使软件维护变得比较容易一些。

银弹

No Silver Bullet - Essence and Accidents of Software Engineering

用银才能杀死狼人,文章以此为喻,讨论如何降低软件开发的成本。作者一开始想从本质上解决问题,软件的本质无非就是数据以及他们的联系,但是在软件开发中具体的设计和实现,测试等却体现出极大的多样性,因此软件开发很难用一个通用法来解决一类问题。

软件开发的成本很大一部分是人力资源。

比如合作编程,若是契约式编程,一个人只负责一个模块,模块有明确地功能定义,输入输出,那么使用其他人的模块就会非常简单轻松。

但如果我们现在要做一个模块的改写,比如上一次结对编程的电梯项目,首先我们使用的是老师提供的接口进行电梯的编写,而弄懂这些接口的使用方法就花了我们比较多的时间,而且我和我的搭档在理解上还出现了比较大的分歧,进行多次探讨后才最终确定。软件开发涉及到人员的合作,而且代码的编写是一种非常个人化的东西,我可能理解我的代码,我接下去写很容易,但是别人若是想法不同,就可能要花很多时间先理解他人的想法,才能进行深层次的改写,这就产生了代价,增加了成本。

因此,软件的成本没有什么通用法来降低,可以通过一而再的规范过程来进行,这是一个十分个人化的过程。

CatB – Cathedral and the Bazaar

你的团队是用什么方式建造软件?

cathedral和bazaar两种软件开发模式,我们团队使用的是Cathedral方式,也许可以翻译成教堂式?我们的源代码在开发过程中是不公开的,开发过程中也只由我们一个团队所管控源代码。另外一种the Bazaar模式,集市模式,是在开发过程中就公开源码,他人可以浏览并提出自己的见解。

个人觉得采用集市式开发模式是一种非常不错的软件开发模式,但是首先你得有一个自己的圈子。

 

Agile Method – by Martin Fowler

你的团队在开发中用了那些敏捷的思想和做法?

简单的说,敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。           

其实很惭愧,我个人的编程风格就是边写边改,只有一个功能上的大方向,没有什么明确的设计和计划,测试时出现bug经常要改很久。我相信许多初学者会犯和我一样的错误。IT行业为了改变这一情况,引入了工程化方法,要求软件开发遵守严格的规则,写出详尽的文档以保证模块的正确性等等。但是软件开发应该有足够的灵活性,这种死板繁琐的方式也是受到了许多抨击。敏捷性开发方法就是一个比较折中的解决方法,主要思想是不把编程人员和计划制定人员分的太开,面向人,以人为本,适应用户需求的变化进行开发,不把人看作是一个部件,给程序员更多的权利,让他们了解用户的需求,以便明确自己的任务。

       我个人认为,我们团队还是应用了一些敏捷的思想和做法的。

       比如,

  1. 在开发的后期,也接受需求改变。比如某个dev想给某个模块增加功能,就算这个模块已经编写完毕,我们还是认真地讨论了这个问题,然后否决了他。
  2. Dev们经常面对面的交流,模块之间信息传递非常有效率。
  3. 团队PM经常检查dev的完成状况,并且经常召集大家开会来交流情况。
  4. 每隔一段时间,团队会进行效率的分析和思考,寻求进一步提升效率的方法。

感想

要当好一个程序员,看来最重要的能力还是团队协作。当然自己的能力也是很重要的,不能让你的队友觉得你是个干不了活的累赘,看着自己团队做出来的作品,小小成就感还是有那么一些的。

从这段时间的编程来看,我还有许许多多的不足之处。这些文章虽然没有在具体的代码层面上给我帮助,但是它们在大体方向上提出的那些思想和讨论给了我很多启发。我大一大二主要是学习了教材上的编程,而在这里,我看到了真正的软件工作人员是怎么进行编程的。以后,我要

  1. 首先我得想办法融入一个IT的圈子。
  2. 多读书

个人阅读作业2