第四次作业(1,2题)

题目:

1、敏捷开发是在什么样的背景下产生的?其主要特点有哪些?什么时候选择敏捷开发更恰当,为什么?

2、Code smell 是如何产生的?有哪些典型的 code smell?代码重构(Code refactoring)有哪些优点?有哪些代码重构的方法?

1.答:敏捷软件开发产生的背景:

(1)软件开发的新挑战

a:快速的市场进入时间,要求高生产率

b:快速变化的需求

c:快速发展的技术

(2)传统的软件开发方法

a:强调过程和文档

b:对变化的适应能力偏弱

敏捷软件开发的特点:

a.敏捷宣言表明的是一些优先级,不必当做圣旨或则教条来争论

b:致力于降低变化的成本

c:价值导向

d:充分发挥人的积极性

e:基于增量和迭代的开发方法

敏捷的试用范围:

产品可靠性要求 不高,容忍经常出错
需求变化 经常变化
团队人员数量 不多
人员经验 有资深程序员带队
公司文化 鼓励变化,行业充满变数
实际的例子 写一个微博网站
用错方式的后果 用敏捷的方法卡法登月火箭控制程序,前N批宇航员都挂了

从敏捷开发软件的适应范围中,可以得出敏捷开发在产品要求不高,容忍经常出错;需求经常变化;团队人数不多;有资深程序员带队的情况下选择敏捷开发软件更适合。

2.答:Code Smell产生的背景:Code Smell中文译名一般为“代码异味”,或“代码味道”,它是提示代码中某个地方存在错误的一个暗示,开发人员可以通过这种smell(异味)在代码中追捕到问题。代码味道是由我们开发人员根据自己的一些工作经验积累来判断的,有人觉得代码注释可以体现代码结构和质量,还有些人又认为代码注释是用来解释过于复杂代码的一种说明机制。显然,Javadocs? 很有用,但是多少内嵌注释才足以维护代码?如果代码已经编写得足够好,它还需要自己解释吗?从这些我们可以看出代码味道是一种主观评估的机制,在很多情况下面,尽管一些看其来糟透了的代码可能是他人曾经编写最好的代码。在我们工作中,是否有很多这样的声音,”是的,初看起来有点乱,但是它的扩展性不错”。因此,我们需要客观评估代码质量的方法,某种可以决定性地告诉我们正在查看的代码是否存在风险的东西。

典型的Code Smell:

  1. Duplicated Code。代码重复几乎是最常见的异味了。他也是Refactoring 的主要目标之一。代码重复往往来自于copy-and-paste 的编程风格。与他相对应OAOO 是一个好系统的重要标志
  2. Long method。它是传统结构化的“遗毒”。一个方法应当具有自我独立的意图,不要把几个意图放在一起,特别注意大类和长方法。
  3. Large Class。大类就是你把太多的责任交给了一个类。这里的规则是One Class One。
  4. Shotgun Surgery。这正好和上面相反。对系统一个地方的改变涉及到其他许多地方的相关改变。这些变化率和变化内容相似的状态和行为通常应当放在同一个类中。
  5. Feature Envy。对象的目的就是封装状态以及与这些状态紧密相关的行为。如果一个类的方法频繁用get 方法存取其他类的状态进行计算,那么你要考虑把行为移到涉及状态数目最多的那个类。
  6. Data Clumps。某些数据通常像孩子一样成群玩耍:一起出现在很多类的成员变量中,一起出现在许多方法的参数中……,这些数据或许应该自己独立形成对象。
  7. Switch Statement。基于常量的开关语句是OO 的大敌,你应当把他变为子类、state 或strategy。
  8. Parallel Inheritance Hierarchies。并行的继承层次是shotgun surgery 的特殊情况。因为当你改变一个层次中的某一个类时,你必须同时改变另外一个层次的并行子类。
  9. Lazy Class。一个干活不多的类。类的维护需要额外的开销,如果一个类承担了太少的责任,应当消除它。
  10. Speculative Generality。一个类实现了从未用到的功能和通用性。通常这样的类或方法唯一的用户是test case。不要犹豫,删除它。
  11. Message Chain。消息链发生于当一个客户向一个对象要求另一个对象,然后客户又向这另一对象要求另一个对象,再向这另一个对象要求另一个对象,如此如此。这时,你需要隐藏分派。
  12. Middle Man。对象的基本特性之一就是封装,而你经常会通过分派去实现封装。但是这一步不能走得太远,如果你发现一个类接口的一大半方法都在做分派,你可能需要移去这个中间人。
  13. Data Class。对象包括状态和行为。如果一个类只有状态没有行为,那么肯定有什么地方出问题了。
  14. Refused Bequest。超类传下来很多行为和状态,而子类只是用了其中的很小一部分。这通常意味着你的类层次有问题。
  15. Comments。经常觉得要写很多注释表示你的代码难以理解。如果这种感觉太多,表示你需要Refactoring。

代码重构(Code refactoring)的优点:

1·持续偏纠和改进软件设计

2·使代码更易为人所理解

3·帮助发现隐藏的代码缺陷

4·从长远来看,有助于提高编程效率

重构的方法

1. 提取类/抽离方法

正如上面提到的,像“臃肿的类”(一个类提供了本该有几个类提供的功能)这种代码异味应该将原有类中的方法和属性移动到适当数目的新类中去。旧类中对应新类的方法和属性应该被移除。另外,有时候一些类过于臃肿是因为它包含了被其他类使用本应该是其他类的成员方法的成员方法。这些方法也应该被迁移到合适的类中。

2.提取方法

像上面提到的“过长的方法”这种代码异味可以通过从旧方法中提取代码到一个或多个新方法中消除。

3.分离条件

许多时候,一个方法很长是因为包含好几个分支语句(if-else)。这些分支条件可以被提取和移动到几个单独的方法中。这确实能大大改善代码可读性和可理解性。

4.引入参数对象/保留全局对象

在我做代码审查时发现另外一个很常见的情况 - 好几个参数被传入方法。问题主要与需要从已有方法中增加或者移除一个方法参数有关。在这种场景,建议将相关方法参数组成一个对象(引入参数对象),让方法传递这些对象而不是每个单独的参数。

5.用符号常量替换魔法数字

对于有意义的并且到处被使用的字面常量,应该为它们分配一个命名常量。这能大大增强代码可读性和可理解性。

6.重命名方法

正如上面提到的,模糊不清的方法名会影响代码的可使用性。这些模糊不清的名称应该重命名为有意义的可能与业务术语有关的名称,来帮助开发者通过业务上下文更好地理解代码。这很需要技巧并且要求开发者与业务专家一起协作来理清代码需要满足的业务需求。有趣的是,这种重构方法看起来似乎非常容易理解,但是常常被许多开发者忽视,虽然在Eclipse这种IDE的refactor菜单项中经常出现这一项。

时间: 2024-10-06 01:03:53

第四次作业(1,2题)的相关文章

PHP第四天作业:可变变量的首次应用

今天作业第五题: 5.由数字1.2.3.4能组成多少个不重复的 3位数字,要求一个数中不能有重复出现的数字. 这道题一上手的第一时间就是用for循环遍历所有可能性,并且找出符合条件的元素. 那么代码就不详解了,基本都会: for($s1=1;$s1<5;$s1++){ for($s2=1;$s2<5;$s2++){ for($s3=1;$s3<5;$s3++){ if($s1!=$s2&&$s1!=$s3&&$s2!=$s3){ echo $s1,$s2,

04+罗潇潇+罗潇第四次作业

04+罗潇潇+罗潇第四次作业 1.项目整体管理的过程 (1)项目启动,制定章程 (2)制定初步的项目范围说明书. (3)制定项目管理计划 (4)指导和管理项目执行 (5)监督和控制项目 (6)整体变更 (7)项目收尾 2.项目启动就是以书面的.正式的形式肯定项目的成立与存在,同时以书面正式的形式为项目经理进行授权.项目章程应当由项目组织以外的项目发起人发布,若项目为本组织开发也可以由投资人发布. 3.项目章程包括: (1)基于项目干系人的需求和期望提出的要求. (2)项目必须满足的业务要求和产品

软件工程(第四次作业)

第四次作业 题目: 1. 敏捷开发是在什么样的背景下产生的?其主要特点有哪些?什么时候选择敏捷开发更恰当,为什么? 2. Code smell 是如何产生的?有哪些典型的 code smell?代码重构(Code refactoring)有哪些优点?有哪些代码重构的方法? 答:1(1)敏捷开发的背景: 所谓敏捷开发是以用户的需求进化为核心,采用迭代.循序渐进的方法进行软件开发.在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视.可集成和可运行使用的特征.换言

软件工程第四次作业——团队作业

软件工程第四次作业--团队作业 本次作业采用团队作业的方式,我的队友是我的同班同学,他们分别为:(队长)亢健强,贾猛,黄明帅,黄珂锐.我们团队的总体任务是要做一个"乐谱识别与演奏"的软件,拍摄一张乐谱图片,它会使用光学识别转换成音乐. 此次团队作业中我得任务主要是做需求调研,为此我先总结了一下常用的需求调研方法的优缺点,然后结合我们团队的实际情况选出了一种最适合我们的调研方法. 调研方法 优 点 缺 点 实地观察法 调查者在实地通过观察获得直接的.真实可靠的第一手资料 有一定的偶然性,

&lt;第四次作业查阅&gt;hashmap由value找key的算法

问题:不同于第三次作业,第三次作业是按照key的值排序输出,第四次作业则是要求按照频率(hashmap的value值)排序,然后输出key的值,最开始的想法是还是沿用第三次作业的做法,想着查询一下怎么从value反得到key的值,最后发现这种做法不仅麻烦,而且效率特别低,也给了我启示,由于key-value对可能出现多对一的情况,所以由key的value比较容易高效,但是反之的效率就比较低,应该尽量能够避免试图通过value得key. Map中是一个key有且只有一个value. 但是一个val

kuangbin专题四 : 最短路 I 题 Arbitrage

kuangbin专题四 : 最短路 I 题  Arbitrage POJ 2240 Arbitrage is the use of discrepancies in currency exchange rates to transform one unit of a currency into more than one unit of the same currency. For example, suppose that 1 US Dollar buys 0.5 British pound,

第二次作业电梯编程题测试结果

第二次作业电梯编程题测试结果 电梯作业中出现的问题 最终需要输出的是乘客等待时间和(不是电梯运行时间) 部分同学的代码对非按序排序的时间无法处理 代码文件的命名最好不要有中文.空格 不要在代码末尾加 system("pause") 完整代码要求上传到github,博客中若需要贴代码只贴关键代码即可 表格中测试结果负分的含义 仓库无代码文件 No Source Code File -1 对输入的测试用例不能运行 Runtime Error -2 能运行但无法输出结果 No Output

结对作业(软件工程第四次作业)

软件工程第四次作业---代码审查 一.partner 结对伙伴:林路 代码链接:coding 二.代码审查表 功能模块名称 简单的语法分析程序 审查人 王灵杰 审查日期 2018.4.6 代码名称 简单的语法分析程序 代码作者 林路 文件结构 重要性 审查项 结论 头文件和定义文件的名称是否合理? 合理 头文件和定义文件的目录结构是否合理? 合理 版权和版本声明是否完整? 不完整 重要 头文件是否使用了 ifndef/define/endif 预处理块? 没有 头文件中是否只存放"声明"

第四次作业——04树

第四次作业--树 一.学习总结 树的思维结构图 2.对于树学习总结 ⑴.树结构认识:树是一种非线性结构,每个节点有0个或多个后继节点,有且仅有一个前驱节点(根节点除外).在树中,递归方法可以放在考虑的首要位置 ⑵.学习这个结构遇到的困难:递归调用不会很清晰,代码量大,较难记忆. ⑶.树结构可以解决的问题:并查集问题 哈夫曼编码的问题. 二.6-1 二叉树操作集 1.设计思路 void CreateBTree(BTree &BT,string str){ 创建一个树T 定义一个i来计数 创建一个队