个人项目作业week5——敏捷开发方法读后感

  从编写边改的无规划编程,再到有一套繁琐规则的重型方法,敏捷方法可以说是它们在无过程和过于繁琐的过程中达到了一种平衡,使得能以不多的步骤过程获取较满意的结果。 简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

一、核心思想:适应变化和以人为中心

  项目最重要的一项就是需求,可客户的需求总在变,根本不可能完全预见,这就需要迭代式开发,其要点是经常不断地生产出最终系统的工作版本,这些版本逐部地实现系统所需的功能。它们虽然功能不全,但已实现的功能必须忠实于最终 系统的要求,它们必须是经过全面整合和测试的产品。这一点在我观摩了同学跟着实验室老师做的项目之后有很深的感触。项目细节在开发初期并不重要,开发需分为几个阶段,前几个阶段需要把基本框架完成,并且基本功能经过完整的测试后没有问题才能进入下个阶段。这样即使客户临时想要添加或修改什么功能,也就在原有的正确的基础上进行修改就可以了,节省了很多时间,同时也减少了许多项目的不可预见性。

  客户在这样的适应性过程中,客户实际上能够对软件开发过程进行很深入细微的控制。在每一个迭代阶段中,他们都能检查开发进度,也能变更软件开发方向。这导致了与软件开发者更密切的关系,或曰真正的商业伙伴关系。同时实施一个适应性过程特别要求一组高效的开发人员。所以说敏捷开发是面向人的开发过程。

二、“吾日三省吾身”

  还有另一种适应性,即是过程本身随着时间推移变化。随着时间的推移,开发团队会发现什么方式对他们的工作最好,然后改变过程以适应之。自适应的第一步是经常对过程进行总结检讨。一般来说,在每一次迭代结束后, 你可以问自己如下问题:

  •   有哪些做的好的部分
  •   有哪些教训
  •   有哪些可以改进的部分
  •   有哪些没搞清楚的部分

  这些问题会帮助你考虑在下一次迭代中如何对过程进行修正。这样,如果 开始时使用的过程有问题的话,随着项目的进行,该过程会得以逐步的完善, 以使其能更好地适合开发团队。

三、即使无法预期,设计也很重要

   一般的使用中,演进式设计意味着一场灾难。设计以一堆即兴的决定(ad hoc decisions)而组成,每一个决定都使我们的程序越来越难以应对变化。就像Kent说的那样,设计是用来帮助你在很长的一段时间里更容易应对软件的各种修改。而一个贫乏的设计带给我们的是,你难以有效的应对各种变化。随着时间的推移,设计越来越难以满足要求。这不单导致了软件更加难于应对变化,还使得Bug更容易产生,更难以被找到和安全的解决。而规划式设计中,设计人员事先考虑那些重大问题。他们可以用设计工具,比如UML,帮助他们摆脱编码细节而更多的关注抽象层面。因为设计人员们从很高的层面去思考,所以可以避免一系列局部决定导致的混乱局面。程序员可以遵从设计指引的大方向去实现一个良好实施的系统。

  不过不可能对开发阶段即将遇到的所有问题进行预判,从而不可避免的在开发的时候就会发现一些对设计产生的质疑。这时候可以很好地利用重构的方法对于程序进行必要的修改以适应需求变化。

四、Fowler关于设计与极限编程的忠告

一个简单系统的四个标准。排序如下(重要在前):

  •  运行过所有测试
  •  表达所有意图(Reveals all the intention)
  •  无任何重复(No duplication)
  •  最少的类和方法

Fowler对于极限人(XPers)使用模式的忠告是:

  •  为学习模式投入一些时间。
  •  关注在开发过程中的什么时候该使用模式。(别太早)
  •  在一开始关注如何以最简的形式实现模式,然后再加入复杂性。
  •  如果你使用了一个模式,然后你又发现它不值得使用,毫不犹豫的把它搞掉

一般来说图是在开始编码之前开展设计用的。当你这样搞的时候注意:

  •  保持简短。
  •  别尝试表达所有的信息(只关心最重要的)
  •  不要把设计结果当做最终设计,而只是一个草稿

五、持续集成

  在我的概念中,一般合作的项目都是大家都做好之后再统一集成一下成为一个完整的程序。但我现在意识到这是完全错误的。一个程序的每一个部分只有在理想化的基础上,才是完全可分的。可事实上大部分的程序的各个部分还是有一定联系的。那么如何让所有人写出来的程序能顺利的成为一个整体就成了一个值得考虑的话题。

  Fowler在自己的文章中提到了持续集成的重要性。虽然过程很麻烦,不过麻烦也是有意义的。这样做的结果是你总能得到一个稳定的软件,它可能有一些 bug,但可以正常工作。每个人都基于相同的稳定代码进行开发,而且不会离得太远,否则就会不得不花很长时间集成回去。Bug被发现得越快,花在改正上的时间就越短。而且这样也是团队中各组员保持交流的一种方式。没有交流的团队编程是失败的,所有人齐心协力共同完善代码仓库中的项目代码,很大的提高了团队合作效率。

原文地址:https://www.cnblogs.com/sunsoul/p/3371287.html