分类：软工

2_4 软件演化和配置管理

2_4 软件演化和配置管理

代码大规模修改和维护

重构:
重写

出现问题维护:
好的代码:修改一个地方就搞定
不好的代码(各种复制):ctrl+shif+f,全局查找修改

有效维护:
好的代码质量
好的文档
好的版本管理

代码开发成本集中在交付后

原因:

代码的维护成本远远大于开发成本.
1.首先是代码和文档的脱节问题.
2.其次是即使你的文档写得很好，可是维护人员会看你的文档吗？而代码是无论维护人员喜不喜欢看，都必须去看。
3.面向对象的三个要素是角色、职责和协作。所有的设计模式都是解决职责问题。。首先有职责，才有设计模式。
4.对于大多的软件项目或移动开发领域，需要做到快速迭代。快速交付一个可用的产品比什么都重要。不要祈求需求不发生变化（有一个笑话：任何需求都发生三次以上，需求发生两次变化的需求分析人员死在用户更改需求的路上）。
代码就是设计。
http://blog.csdn.net/superhoy/article/details/7466339
git

看https://github.com/HIT-CSDN-Technology/resource(在下参与维护,欢迎提交pull request)

2_2 敏捷过程和方法

2_2 敏捷过程和方法

敏捷开发

  • 你是否认为，没有足够的技术水平就无法使用敏捷开发方法?
  • “敏捷过程模型是增量方法和迭代方法的复合”。你是否认同这个观点?

敏捷开发需要一定水平.敏捷开发需要快速迭代,在这种需求随时变化的情况下,如果水平不够,技术可能成为迭代和项目开发的瓶颈,乃至导致项目失败.并且在结对编程中双方水平差距太大可能影响高水平一方发挥.

迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

敏捷开发是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发.在scrum中,每个sprint中干的事就是增量.

开发方式选择

针对下列软件项目场景，探讨它们最适合采用哪种过程模型

  1. 已被广泛使用的某个产品，要开发新版本，包含了一组新功能，规定了紧 迫的最后期限并已对外公开:需求清晰,使用瀑布模型
  2. 要开发某个突破性的产品，规模很大，所需的开发技术先进，风险较大， 且市场上尚未有类似产品，用户尚未对其形成完整的预期;团队人员充足:螺旋模型
  3. 要开发的系统以某科学家团队的研究成果为基础，目标是在下一年度发布:基于原型开发
  4. 要开发的系统类似于团队之前已经做过的某个项目，只是规模更大、复杂度更高一些，需求已经由用户写成文档:RAD或者增量,文档驱动型
  5. 一组身经百战的团队人员要开发一个互联网服务，同类产品在不断更新中， 互联网用户在使用过程中随时 出反馈:敏捷模型

2_3 软件项目管理

2_3 软件项目管理

处理案例

  • 一个平均技术水平低下的研发团队而使得项目进展存在较多隐患。
  • 一个无奈的弱势项目经理缺乏经验几乎无法处理全部问题;
  • 一个鲁莽但是经验丰富的技术人员，粗鲁的忽视了开发进度和客户需求，进 行单方面技术改进的要求;
  • 公司因为项目款项回收速度慢而指责团队开发进度。
  1. 找个高水平程序员带队;或者经常进行code review保证;文档保证;额外培训
  2. 换人
  3. 要么妥协,要么走人,软件开发以需求为最重要的
  4. 告知团队具体情况

软件项目估算

为什么程序员的估计时间不靠谱

一个我曾经共事过的很有经验的项目经理曾宣称说，他会拿程序员估计出的时间乘以π值，然后再提高一个数量级，这样得出的才是正确的开发所需要的时间。1天时间经过变换后是3.14周。他经过惨痛的教训才认识到程序员预估的时间都是不靠谱的。为了能更精确的对程序员估计的时间进行换算，我创建了一个时间换算表，重点说明究竟是什么地方出了问题。

估计时间 程序员的思考 程序员忽略的事情 真正所
需时间
30秒 只需要对代码进行很小的改动就搞定了。我清楚的知道程序应该在哪里做修改、怎么修改。只需要30秒时间。 启动电脑的时间，启动开发环境的时间，获取源代码的时间。编译、测试、提交代码和文档修改的时间。 1小时
5分钟 一个小问题，我只需要上谷歌上查查它正确的语法就能搞定。 你不可能第一次就能精确的查找到正确的信息，就算是找到了，在使用它之前你也需要对它做一些调整。还有编译、测试的时间等。 2小时
1小时 我知道该怎么做，但是这需要写一些代码，所以要花一些时间。 1小时时间太紧张，没有给任何未预料到的事情留下余地。总有一些你预料不到的事情。 2小时
4小时 这需要写一些代码，但我基本知道该怎么做。我知道我们的标准框架里的Wizzabanga模块能做这个事情，但我需要去查查文档看如何正确的调用它。 这可能是唯一一个符合现实的估计。在任务不是很大、能够处理的情况下，它给未预料到的问题留下了足够的时间。 4小时
8小时 我首先要重构Balunga类，把它拆分成两个，然后在Wizzabanga模块里加入调用代码，最后在界面上添加一个新的表单域。 系统的很多地方都对Balunga类有依赖关系。大概有40多个文件需要调整。界面上新添加的属性的同时数据库里也要新增字段。8小时是十分理想的状况的时间。程序员在估计时间时总忽略了还有很多其它事情要做。 12-16小时
2天 这需要写很多的代码。我需要在数据库中添加一些新表，用一个界面来显示它们，然后还要写存取它们的逻辑代码。 对大多数程序员来说，2天时间能完成多少东西都是很难说的。肯定会有一些东西被遗忘。并不是指一些小的东西，一些主要功能上的重要东西也有可能在你估计时被遗漏。 5天
1周 哇塞…这可是个大任务。我还不知道如何实现它，我不是告诉你我不知道如何做。一周时间应该足够了，但愿，希望能够，但我不会要求更多的时间，不然的话他们会说我能力不行。 这样一个任务对于大多数程序员来说都很难理解消化。这个任务应该发回给架构师，让他把任务拆分成更小的模块，对各模块应该如何执行给出一些指导。架构师应该能找到实现它的一些简单的方法——或者认识到这个任务的工作量比他预期的要多。 2-20天
预估时间本身就很难。每个程序员的估计都会跟真正需要的时间有些差距。估计时间短了说明有些事情被忽略了(编译，测试，提交代码)。估计时间超了说明任务太大，难以理解。

对于资历较浅的程序员，这种估计误差是混乱的，他们经常会轻视一些任务，同时又对一些稍微有难度的任务过分高估。我认为，对一个有经验的程序员，一个任务的时间应该在半小时到24小时之间，超出24小时的任务都需要拆分。程序员在脑中想一想可能会认为要60小时，但实际上即使是很有经验的程序员也需要将任务分成可控的模块再来分析做决定。

还有一个很重要的需要认识到的一点是，编程上的经验并不等同于时间估计上的经验。一个从没有做过工期估计的程序员不会擅长估计时间。如果不去拿真正需要的时间和估计出的时间进行比较，你不可能从其它反馈信息之得到正确估计时间的经验。

每个程序员都会用到评估技巧。为了提高你的这项技能，你可以在你从事的每个任务上进行锻炼。在任务开始时先预估开发所需时间，拿它跟你最终真正用掉的时间进行对比。这样，你不仅在对任务细节的理解上有提高，同时也提高了你对时间预估的技能。

http://www.vaikan.com/why-programmers-are-bad-at-estimating-times/

计算模式的变迁历史

  • 1965-1985:以大型机为核心的集中式处理模式(mainframe);
  • 1986-1990:以PC/文件服务器为核心的文件共享计算模式;
  • 1990-1996:以C/S结构为主流的分布式计算模式;
  • 1996-:以Web为核心、B/S结构为主流的分布式计算模式;
  • 2005-:以各类移动设备为核心的普适计算模式(无所不在的计算，无所不在 的通讯);
  • 2008-:以云计算为核心的集中式共享模式(虚拟化);

2_1 软件过程模型

2_1 软件过程模型

阅读《敏捷软件开发宣言》

  • 理解其中蕴含的各项思想;
  • 分析这些敏捷思想在传统过程模型中为何无法做到?
  • 这些思想对软件开发带来的优势是什么?

内容:

  • 不强调文档，转向强调可运行的软件片段
  • 开发者与客户之间频繁沟通
  • 快速开发，快速反馈，快速修改，增量交付
  • 连续不断的短周期迭代
  • 不看重形式和工具，看重“人”和内容，保 持简洁。

思想:
以人为本,快速开发

传统模型:
强调过程,文档,结构

优势:

用两个词吧，一个是拥抱变化，一个是进度可视。
1.任何软件类系统或项目，即使你前期花在需求上的时间足够长，你也很难在需求阶段真正的分析和挖掘出所有的需求。有些需求注定会在设计实现或用户使用过程中才逐渐出现。要承认软件开发中存在这种不确定性。而瀑布模型将这种识别变化延迟到最好的测试或用户使用阶段才发现，极大的增加了返工或变更成本。敏捷思想里面通过短周期迭代，尽可能早的交付可用的迭代版本来拥抱和适应变化。
2.任何一个软件项目，需求或设计做完我们并不清楚进度是否真正完成了60%或者更多，任何不是经过测试通过的功能我们都很难把握真正的完成进度情况。因此在敏捷里面换了一种思路，如讲这个项目拆分为100个粒度差不多的功能点，如果有60个功能点全部完成并通过验证和测试，我们就比较有把握说整体进度完成了60%。这种可视化的评估进度模式在传统模式中难以做到。

查阅资料，了解“结对编程”

并根据你的直觉阐述它的优势。你认为结对编程中的两个人该如何配合、如何分工?

结对编程技术是指两位程序员坐在同一工作台前开发软件。与两位程序员各自独立工作相比，结对编程能编写出质量更高的代码。

驾驶员(Driver):控制键盘输入的人。

写设计文档，进行编码和单元测试等XP开发流程。

领航员(Navigator):起到领航、 醒的作用。

审阅驾驶员的文档、驾驶员对编码等开发流程的执行;考虑单元测试的覆盖 程度;是否需要和如何重构;帮助驾驶员解决具体的技术问题。

驾驶员和领航员不断轮换角色，不宜连续工作超过一小时。领航员要 控制时间。
主动参与:任何一个任务都首先是两个人的责任，也是所有人的责任; 没有“我的代码”、“你的代码”或“她的代码”，只有“我们的代 码”。
只有水平上的差距，没有级别上的差异:尽管可能大家的级别资历不 同，但不管在分析、设计或编码上，双方都拥有平等的决策权利

模型分析

  • 针对各类软件过程模型，通过对比分析，找出这些过程模型之间的异同，并分析各自的优缺点;
  • 分别用若干个简短的词来描述每一种软件过程模型的核心特征

模型:

  • 瀑布模型:将全部需求以整体方式向前推进，无迭代;——基本模型
  • 增量模型:将需求分成多份，串行推进，无迭代;——串行的瀑布
  • RAD模型:将需求分成多份，并行推进，无迭代; ——并行的瀑布
  • 原型模型:迭代; ——基本模型
  • 螺旋模型:按瀑布阶段划分，各阶段分别迭代(原型+风险分析); ——原型+瀑布
  • 敏捷模型:将需求分成尽量小的碎片，以碎片为单位进行高速迭代。 ——增量+迭代