个人阅读作业2

个人阅读作业2

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

软件工程的瀑布

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

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

个人感想：

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

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

 

瀑布模型的特点有：

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

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

(2)推迟实现的观点

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

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

 (3)质量保证的观点

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

银弹

No Silver Bullet - Essence and Accidents of Software Engineering

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

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

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

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

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

big ball of mud

你的项目有一个大泥球么? 有什么解决办法？

目前由于我们项目实现的功能还相对比较简单，代码量都不算很大，因此我个人觉得我们的项目中还算不上存在着大泥球，但是我觉得那种又长又臭的面条式程序还是存在的。我们是从上一届学长处得到的源码，个人认为从面向对象的角度来看，这份代码并不理想，有的类只有10行不到的代码，而有的类有500行左右的代码。其中一个类，我个人认为如果在这个基础上直接添加内容，非常容易产生“大泥球”。

比如在结对项目的电梯编写时，我们写出的电梯调度算法就可以算是一个“大泥球”，考虑了各种情况，各种分支，由于代码编写经验不足，那段代码有许多的复制黏贴的部分，这就导致了很大的冗余。要解决“大泥球”的问题，应该首先从代码优化的方面来考虑，在不改变功能的基础上，尽可能的优化代码结构，减少重复部分和冗余。举个例子，我们写的第一版电梯的调度算法，向下的情况和向上的情况中的代码几乎就是一样的，只是改了几个参数，说白了就是向上向下改一遍而已。但是由于这段代码太长，导致看起来就非常复杂，而且在想修改算法时，改完一段还得改另一段，工作量大不说，还得特别小心，一旦一个地方改错了，debug时很难发现是错在这种地方。后来，我们就把这两段代码合并，并做了一些优化，直接改少量的变量就可以完成这段代码的修改，而不用修改这段代码本身。

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. 多读书