---

2017-2018-1 学习总结目录：　1　2　3　5　6　7　9　10　11　12

---

目录

---

• 0. 本周学习内容总结
  • 0.1 Comparable接口与Comparator接口的使用
  • 0.2 泛型方法设计
  • 0.3 团队学习：《构建之法》 ★

• 1. 本周学习中的问题和解决过程
  • 1.1 指数阶复杂度的计算
  • 1.2 线性语句序列

• 2. 代码调试中的问题和解决过程
  • 2.1 根据程序语句分析频度
  • 2.2 递归测试抛出异常StackOverflowError

• 3. 代码托管、本周考试错题总结

• 4. 结对及互评、其他（感悟、思考等，可选）

• 5. 学习进度条、参考资料

---

本周学习内容总结

1. Comparable 接口与 Comparator 接口的使用

• Comparable 接口： 只包含一个方法compareTo，它带有一个对象类型参数，返回一个整数值。（比较：一个对象调用方法，另一个对象作参数）

if (obj1.compareTo(obj2) < 0)System.out.println("obj1 is less than obj2");

API中介绍到：

Compares this object with the specified object for order. Returns a negative integer, zero, or a positive integer as this object is less than, equal to, or greater than the specified object.

如果obj1小于obj2，则返回负整数，相等返回零，其余返回正整数。在 String 类中 compareTo 方法也是如此，因为 String 类实现了 Comparable 接口。

• Comparator 接口：强行对某些数组或集合进行排序，在一个独立的类中实现比较。

• Comparator接口与Comparable接口的区别：首先，存在于不同的包中，Comparator 位于 java.util 包下，Comparable 位于 java.lang 包下。其次，前者在一个独立的类中实现比较（其余类结构不变），而后者将比较代码嵌入自身类中。两种接口各有千秋，只有多练习才能体会到其优势。

2. 泛型方法设计

• 泛型：具有一个或多个类型变量的类。一个类保存、操作并管理直到实例化时才确定类型的对象，尖括号内指定元素对象的类型。
  例如：构造一个保存 Employee 对象的数组列表：
  ArrayList<Employee> staff = new ArrayList<Employee>();
  两边都使用类型参数 Employee 有些繁琐。在Java SE 7 中，可以省去右边的类型参数：
  ArrayList<Employee> staff = new ArrayList<>();
  这样，new ArrayList<>()便赋值给一个类型为ArrayList<Employee>的变量了，这就是所谓的 菱形语法 。

• 泛型方法：泛型方法可以定义在普通类中，也可以定义在泛型类中。

3. 团队学习：《构建之法》

• 合作分工 → 大致内容框架 → 提出问题

  Members	Chapters
  袁逸灏	第1、2、3章
  刘伟康	第4、5、6章
  刘先润	第7、8、9章
  马军	第10、11、12章
  刘诚昊	第13、14、15章
  莫礼钟	第16、17章

第 1 章 概论

• 1.1 软件 = 程序 + 软件工程
  软件工程的核心部分（狭义，广义）、软件工程的地位、软件开发不同阶段的不同表现。

• 1.2 软件工程是什么
  软件工程的定义、软件工程所包含的领域、软件开发的难点、工程的定义、软件工程并不等于计算机科学，两者有着不同的侧重点，软件工程的知识领域，软件工程的目标，初步学会软件工程需要达到的要求。

第 2 章 个人技术和流程

• 2.1 单元测试
  保证覆盖率为100%，好的单元测试的标准，单元测试可以提高软件开发的效率，回归（回归到以前不正常的状态）测试。

• 2.2 效能分析工具：Visual Studio（抽样、代码注入）
  不经分析就盲目优化，也许会事倍功半。

• 2.3 个人开发流程（PSP）
  PSP任务清单（大学生VS工程师），PSP的特点。

• 2.4 实践
  当前程序设计作业简单，无太多扩展、扩展的方面、做项目的时候需要对项目的处理；
  开放 – 封闭原则：允许扩展，不允许修改。

第 3 章 软件工程师的成长

• 3.1 个人能力的衡量与发展
  个人能力在团队中的作用与影响、个人应当承担的责任、个人的成长记方式。

• 3.2 软件工程师的思维误区
  不要总想着在短时间内搞个大新闻，要结合自身实际，求稳，然后再扩展。

• 3.3 软件工程师的职业发展

• 3.4 技能的反面
  注重自己的技术，要避免懂得“技术”但仍然经常犯一些低层次的问题。

第 4 章 两人合作

• 4.1 代码规范（风格、设计）

• 4.2 代码风格规范（简明、易读、无二义）
  缩进（4个空格）、行宽、括号、断行与空白的{}行（每个{和}独占一行）、分行、命名、下划线、大小写、注释（What、Why）。

• 4.3 代码设计规范
  函数、goto、错误处理（参数处理、断言）、处理类。

• 4.4 代码复审（自我、同伴、团队）
  为什么（早发现早修复、互相了解）、步骤、核查表（概要、效能、可读性等）。

• 4.5 结对编程（极致）
  为什么（高投入产出比）、不间断地复审、角色互换。

• 4.6 两人合作的不同阶段和技巧（萌芽、磨合、规范、创造、解体）
  影响他人的方式、正确反馈（多层次）。

第 5 章 团队和流程

• 5.1 非团队和团队
  非团队（独立、乌合之众）、团队（共同目标、合作）。

• 5.2 软件团队的模式（窝蜂模式）
  主治医师、明星、社区（众人拾柴火焰高）、业余剧团（不同角色）、秘密团队（无干扰）、特工团队（高手）、交响乐团（各司其职）、爵士乐（个性化表达）、功能团队（小组交流）、官僚（不提倡）。

• 5.3 开发流程（统一体系）
  写了再改、瀑布模型（分析-->设计-->实现-->销售-->维护）、统一流程、渐进交付（MVP）、TSP原则

第 6 章 敏捷流程

• 6.1 敏捷的流程简介（找出待解决的问题 --> 决定当前目标 -->冲刺（每日例会）--> 改进）

• 6.2 敏捷流程的问题和解法（计划：体现依赖关系-->描述细化到技术层面 --> 跟踪三个时间 --> 总结教训）

• 6.3 敏捷的团队
  自主管理（自己挑选任务）、自我组织（联合负责）、多功能（全面负责）。

• 6.4 敏捷总结
  质量控制、短时间迭代、极致编程、经验教训。

• 6.5 敏捷的问答
  敏捷是一种价值观、总结思想、最佳实践TDD、适用范围、宣言（左项）。

第 7 章 MSF

• 微软解决方案框架（Microsoft Solution Framework，MSF）,是微软公司通过吸取各部门积累的业务经验并随着时代更新的软件开发方法。其主要原则有9点：推动信息共享与沟通、为共同的远景而工作、 充分授权和信任、各司其职，对项目共同负责（不仅要完成本职工作，更要对项目负责）、重视商业价值、保持敏捷，预期变化、投资质量（投资的效率，时期并要求长期）、学习所有的经验（要坚持总结和分享）、与顾客合作（从用户角度出发）。

• 用户调研（User Study），A/B测试，通过态度、行为、定性、定量来规范调研的尺度。
  

第 8 章 需求分析

• 软件需求
  将需求进行分类、清楚软件产品的利益相关者、获取用户需求（用户调研）、竞争性需求分析的框架、功能的定位和优先级、目标估计和决心、找出估计后面的假设、最后分而治之。

• 经验公式： Y = X ± X ÷ N
  工程师的经验公式实际时间花费主要取决于两个因素—对 某件事的估计时间X，以及他做过类似开发工作的次数N。

• 提案，评估和WBS
  NABC model（N--need需求、Approach--做法、Benefit--好处、Competitors--竞争、Delivery--推广方式）
  评估：目标（根据实际的需求来定）、决心（它承诺在特定日期交付预定义的功能，作为特定的质量级别）、估计（单个任务花费的人力、时间）
  WBS – Work Break Down
  分而治之，顶层（产品）→中层（功能）-用户视角→较低级别（功能实现）-团队透视图（PM，test）→最低级别（模块）-开发透视图

第 9 章 项目经理

• 风险管理
  第一步：确认风险、根据不同的来源对风险进行分类；
  第二步：分析和优先级划分；
  第三步：计划和管理风险
  应对风险的方法：进一步研究、接受、 规避、转移、 降低、制定应急计划

• 项目经理（PM），PM负责除产品开发和测试之外的所有事情，包括正确地做产品和正确地做流程。
  PM的作用：收集需求、设计用户界面，编写规范、协调市场、文档、测试、定位、带领团队达成决策
  【注】项目经理是和大家平等工作，并且做具体工作，和其他团员一起形成决议，只管事不管人的，和领导型经理是不一样的。

第 10 章 典型用户和场景

一、典型用户

• 1.典型用户
  定义： 描述了一组用户的典型技巧，能力，需要，工作习惯和工作环境。
  电影用户的角色：也有受欢迎的和不受欢迎之分。
  典型用户的完善：定义了一部分典型用户后继续与其中代表进行沟通，进一步完善需求理解。

• 2.从典型用户到场景
  场景：也可以是故事，用户为达到目标使用系统时经历的所有过程。
  场景的使用：设计者模拟用户，设计一个场景入口，描述用户在这个场景的内外部因素，给场景划分优先级并写场景。

• 3.从场景到任务
  分层：沿着子系统/模块的所属关系把场景划分开。（例如：P221.UI层，逻辑层，数据库）
  任务与场景：不同的任务将会把一个场景编织起来，得到开发任务后，可以创建和分配测试任务。

二、用例(Use Case)

• 1.用例：与典型人物，典型场景的方法类似，同样是很常用的需求分析工具包含这样的一些基本元素：标题，角色，主要成功场景，步骤，拓展场景。
  用例的原则：
  • 1.通过简单的故事来传递信息。
  • 2.保持对全系统的理解。
  • 3.关注用户的价值。
  • 4.逐步构建整个系统，一次完成一个用力。
  • 5.增量开发，逐步构建整个系统。
  • 6.适应团队不断变化的需求。
• 用例的局限性：
  1.比较适合故事/人物/场景交互的系统。但是对于算法，速度，拓展性，安全性以及和系统技术相关等需求则不适用。
  2.故事的粒度没有统一标准与具体项目有关，初学者较难掌握。
  3.既要把UI的细节嵌入每个故事，又要保证其简明性是一个难题。

三、功能说明书（Spec）

• 1.规格说明书
  软件功能说明书：说明软件的外部功能和用户的交互情况。（软件是一个黑盒子，看不到内部）
  软件技术说明书：又称设计文档，说明软件的内部的设计规范。（透明盒子）

• 2.功能说明书
  从用户的角度描述软件产品的功能，输入，输出，界面，功能的边界问题，功能的效率（to user），国际化，本地化，异常情况等，不涉及软件内部的实现细节。

• 3.制定一份Spec
  定义好相关的概念，规范好一些假设；避免一些误解，界定一些边界条件（定性且定量）；描述主流的用户/软件交互步骤；一些好的功能还会有副作用，服务质量的说明。

• 4.Spec的弊端
  枯燥乏味，无法跟上时间的变化。

• 5.技术说明书
  设计文档，用于描述开发者如何趋势线某一功能，或相互联系的一组功能。实现软件功能没有固定的模板，但总存在着一些规律。

四、功能驱动的设计

• 设计过程：
  构造总体模型 --> 构造功能列表 --> 制定开发计划 --> 功能设计阶段5实现具体功能

第 11 章 软件设计与实现

一、分析和设计方法

• 1.四个过程：
  • 1.需求分析：抽象出我们真正关心的属性，实体之间的关系。用户的需求，如何解决？
  • 2.设计与实现阶段：软件如何解决这些需求，现实生活中的实体和属性在软件系统中怎么表现和交换信息？
  • 3.4.测试,发布阶段：真的解决了这些需求吗，软件解决需求的效率如何，用户还有什么新的需求吗？
• 2.常用方法：
  文档、图形为主构造的模型（思维导图，流程图等）、数学语言的描述、用类自然语言 + 代码构造的描述（Literate Programming）、源代码加注释描述。

二、图形建模和分析方法

• 表达实体和实体的关系
  思维导图、实体关系图、ERD.UCD；表达数据的流动、表达控制流、统一的表达方式（UML）。

三、其他设计方法

• 1.形式化的方法：用无歧义的，形式化的语言描述我们要解决的问题，然后用严密的数学推理和交换一步步把软件实现出来，或者证明我们的实现的确完整和正确地解决了问题。
  2.文学化编程：与“写程序，时不时写一些注释”相反,“写文档，时不时写一些代码。”

四、从Spec到实现

• 1.预估开发时间
  2.写一些快速成型代码，看看成效，查找问题。
  3.看到初始效果与了解实现细节后，开始写设计文档，并与同事进行复审。
  4.按照设计文档写代码，解决遇到的问题。
  5.写好代码后先根据设计文档与代码指南进行自我复审，重构代码。
  6.重建或更新单元测试。
  7.得到一个可以测试的版本，交予相关测试人员测试或者公开测试。
  8.修复测试中发现的问题。
  9.根据代码复审的意见修改代码，完善单元测试和其他相关代码，把新的代码签入到数据库中。

• 2. 把修改集集成到代码库中
  根据场景和开发任务来决定集成的次序、互相依赖的任务要一起集成。
  在测试场景时，要保证端对端的测试。
  场景的所有者必须保证场景完全通过测试，然后把场景的状态改为“解决”。

• 3.开发人员的标准工作流程（如下图所示）
  

五、开发阶段的日常管理

• 1.闭门造车（Leave me alone）：集中于某一件事情，将自己投入其中，拒绝其他人的干扰。
  2.每日构建（Daily Bulid）：打好基础，精益求精。
  3.“构建大师”：对于一个导致构建失败的成员，授予这个称号，并让他：
  负责管理构建服务器 --> 调试构建，负责找错，并分析出错的原因 --> 将这个称号和责任交予下一位导致构建失败的成员 --> 构建大师为团队“构建之法基金”存入50元，以供大家团队构建之用。
  4.宽严皆误：制定宽严标准，以及根据团队的情况（势）所反映的情况。成员行为影响个人的尽量宽松，而影响团队的则要严格处理。
  5.小强地狱（Bug Hell）：类似于构建大师的选取：选出那些超过bug数标准的成员，让他们进入小强地狱专职于小强地狱处理bug，直到满足标准出狱，每周公布进出狱名单。

六、实战中的源代码管理

• 软件 = 程序 + 软件工程
  软件的质量 = 程序的质量 + 软件工程的质量

• 代码需要版本管理
  在源代码基础上进行修改后，留下新版本以及对应的负责人记录，记载bug的内容，处理人，处理时间，是否处理完成等内容以备查验。

七、代码完成

• 两个阶段：
  1.task完成了，设想变成了可以运行的现实。
  2.Bug仍等待着工程师去寻找，修正。

第 12 章 用户体验

一、用户体验的要素

• 1.用户的第一印象：5W1H来判断：Who When Where Why How，用以判断用户对产品的设计需求。
  2.从用户的角度考虑问题：从用户的立场上去使用自己的产品。而不是作为一个开发者，一个熟知产品构造的人去体验。
  3.软件服务始终都要记住用户的选择。
  4.短期刺激和长期影响：短期的刺激并不能成为客户长期使用的依据。
  5.不让用户犯简单的错误：设计能让客户尽可能地避免出错。例如航班上的阅读灯与呼叫空乘客按纽。如果把紧急弹射座椅放在常用按钮面板按错的后果。除了文字完全没有区分度的Submit，Cancel按钮。
  6.用户质量和体验：有时候质量要给用户的体验让步，才能让产品更具有吸引力。
  7.情感设计

二、用户体验设计的步骤和目标

• 用户体验设计的一个重要目标就是降低用户的认知阻力，即用户对于软件界面的认知和实际结果的差距。
  如下表：
  

三、评价标准

• 1.尽快提供可感触的反馈。
  2.系统界面符合用户的现实管理。
  3.用户有控制权。
  4.一致性和标准化。
  5.适合各种类型的用户。
  6.帮助用户识别，诊断并修复错误。
  7.有必要的提示和帮助文档。

四、贯穿多种设备的用户体验

第 13 章 软件测试

• 测试方法名称非常多，但只不过是从各个方面描叙了软件测试，并不是说有这么多独立的测试方法，只要分类处理，也就不会很难理解。

• 13.1 基本名词解释与分类
  三个基本名词：
  • Bug：软件的缺陷
  • Test Case：测试用例
  • Test Suite：测试用例集

• Bug又可分解为：症状(Symptom)、程序错误(Fault)、根本原因(Foot Couse)。-
  测试设计有两类方法：黑箱(Black Box)和白箱(White Box)。
  【注】是测试的“设计”方法，而非测试方法。

• 黑箱从软件的行为，而非从内部设计出发来设计测试；白箱则可“看到”软件系统内部。
  按测试的目的分类：功能测试、非功能测试。
  按测试的时机和作用分类：测试“烽火台”，以及其他测试方法。

• 13.2 各种测试方法（该部分书中为举例了解）
  ① 单元测试(Unit Test) 和 代码覆盖率测试(Code Coverage Analysis)
  ② 构建验收测试：验收系统的基本功能。
  ③ 验收测试：拿到一个“可测”的构建以后，按测试计划测试各自负责的模块和功能。
  ④ “探索式”测试：为了某一特定目的而进行的测试，且仅此一次，以后一般不重复测试。
  ⑤ 回归测试
  ⑥ 场景/集成/系统测试：在开发一定阶段对软件进行一个全面系统的测试以保证软件的各个模块都能共同工作。
  ⑦ 伙伴测试
  ⑧ 效能测试：软件在设计负载能否提供令人满意的服务质量。
  ⑨ 压力测试：严格地说不属于效能测试，验证软件在超过设计负载的情况下能否返回正常结果。
  ⑩ 内部/外部公开测试：让特定用户使用正在处于开发阶段的版本，以便收集更多反馈。
  ⑪ 易用性测试
  ⑫ “Bug”大扫荡

• 13.3 实战中的测试观念：
  1.从项目开始测试人员便要开始介入，从源头防止问题的发生。
  2.测试并非一定要根据规格说明书来测，更要从用户的角度出发来测试软件。
  3.测试人员的代码质量一定要特别高，因为测试人员是最后一道防线。
  4.若为了让问题尽快显现，用Debug版本；若为了尽可能测试用户所看到的软件，用Release版本。
  文档：在计划阶段就写出测试总纲与测试计划，它们主要说明产品是什么，要做什么样的测试，时间安排如何，谁负责哪方面，各种资源在哪等。

• 13.4 运用测试工具
  运用工具记录手工测试及自动测试。
  测试效能：除功能方面的测试，还有“服务质量”
  【例子】效能测试： 100个用户的情况下，产品搜索必须3S内返回结果。
  负载测试： 2000个用户的情况下，产品搜索必须5S内返回结果。
  压力测试： 压力高峰期（4000个用户）持续48小时的情况下，产品搜索必须保持稳定而不至于崩溃

第 14 章 质量保障

• 14.1 软件的质量
  软件质量 = 程序质量 + 软件工程质量
  程序质量体现在软件外在功能。例如一个字处理软件能否拷贝/粘贴等
  软件工程质量：软件在功能、成本、时间三方面满足利益相关者的需求。
  软件工程的质量以一套比较成熟的理论CMMI进行衡量。
  质量成本组成部分包括预防、评审、内部故障、外在故障四个方面。

• 14.2 软件质量的保存工作
  软件的质量保障（QA）和软件测试（Test）是有很大区别的，因此——测试的角色要独立出来，所有人都可以参与QA工作，但最后要有一个人对QA这件事负责，最后软件发布时，必须得到此角色的签字保证。尽管有专人负责测试工作，但保证质量仍是所有成员的职责。
  不能盲目信任“专业人士”扮演的角色，即使有专业人士扮演的角色，还得有专人独立地检查验证质量。
  分工不能“画地为牢”，为了避免出现局部最优而全局未必最优，同时也避免由于软件被切碎而导致整体不太行。
  分工不能无明确责任。

第 15 章 稳定和发布阶段

• 15.1 从代码的完成到发布
  软件生命周期的最后阶段往往是最考验团队的，不但考验团队项目管理水平、应变能力，也考验团队的“血型”。
  原计划的软件发布时间快到了，但是软件还存在各种问题，于是有了4种团队血型：
  A型：他们知道优秀的软件公司会发布有已知缺陷的软件。
  B型：他们不相信这一点。
  O型：他们不知道这一点，因此嘴巴惊讶成O型。
  AB型：他们对于自己开发的软件是A型，对于别人开发的软件是B型。
  

  从代码完成到最终发布软件

• 会诊小组：软件团队的各个代表组成会诊小组，处理每个影响产品发布的问题，对于每一个Bug，会诊小组要决定采取何种行动：1.修复 2.设计本来如此 3.不修复 4.推迟
  复杂项目的会诊招数：
  设计变更、搞定所有已知Bug、最后回归测试、砍掉功能（不能因为以前花了成本，就要求以后一定要完成某个任务）、修复Bug的门槛逐渐提高、逐步冻结。

• 15.2 使用不同频率和不同覆盖范围的渐进发布
  产品同时对不同的目标用户用不同的频率发布，以适应不同群体的需求。

• 15.3 发布之后——事后诸葛亮会议
  这个软件生命的周期结束以后，如尸体解剖一样，把给软件的开发流程剖析一下。

问题集锦

1、软件构建的过程中，何为链接参数？

2、在程序理解阶段，为了能够使不同的人接手非自己的代码，打代码的时候应该要注意什么方面？

3、商业模式是否真正地直接能够决定一个软件企业地成败？

4、在软件开发阶段中爱好者怎么才能晋升为先行者？

5、软件工程开发有着较高的难度，但不代表不能进行开发，如何能使我们能够克服软件开发过程中的难题呢？

6、该如何使单元测试给自动化？

7、主治医师模式：在一个团队中如何避免一个学生干活，其余学生跟着打酱油？

8、明星模式：如何使团队的利益最大化，而不是在明星光芒四射时使自身利益最大化？

9、如何在不影响效率的情况下有效记录三个跟踪的时间值：实际剩余时间、预估剩余时间、实际花费时间？

10、如何培养一个人或者一个团队把重要和有效的做法发挥到极致的能力？

11、软件工程和我们的课程程序设计与数据结构有什么不同？构建之法上的哪些内容可以完全应用到我们的课程中？

12、在进行用户调研的过程中，为什么不能调研细微到毫厘，即做调研做过头？

13、一个团队成熟的标记，就是对风险的管理，在《构建之法》中如是说，我们对待风险该采取什么样的态度呢？

14、关于项目经理PM，书中提到一个团队可以有很多PM，如果一个团队中针对一个项目形成了多个决议，这种窘况该如何解决呢？

15、project manager 和 program manager 的区别在于前者管事也管人，后者只管事不管人，所以PM需要有很强的领导力吗？

16、在设计用例时如何既镶嵌UI的细节又保证故事的简明性？

17、用户的体验和产品的质量同样重要，那么他们冲突时应该平衡至什么地步？

18、在设计典型场景时需要保持模拟内容的简明性还是模拟所有可能发生的事件，无论是否与需求有关？

19、成本的主要组成部分是由什么而产生？

20、结构和实现又有什么样的关系？

21、代码覆盖率是什么？它重要在哪？

22、理想的覆盖率分析工具是怎样的？

【返回目录】

本周学习中的问题和解决过程

• 【问题】我在最开始接触泛型时觉得泛型的语法有些麻烦，对于数组来说自身就有定义方式，那么相对于其他类、其他方法，泛型有哪些的好处，又有哪些弊端？

• 解决方案 ：课堂上听完娄老师对泛型的讲解，课后也阅读了相关资料，大致了解了泛型的好处。首先，泛型程序设计意味着编写的代码可以被不同类型的对象多次重用，然而在Java增加泛型之前，ArrayList类也可以聚集任何类型的对象，为什么后来要增加泛型呢？原来是因为 ArrayList 这种方法有两个问题：第一，当获取一个值时必须进行强制转换，例如：

ArrayList files = new ArrayList();
String filename = (String) files.get(0);

第二，这里不便于错误检查，可以向数组列表添加任何对象。
于是，泛型就提供了 类型参数 解决这两个问题，这使得代码具有更好的可读性：

ArrayList<String> files = new ArrayList<>();

【注】省略的类型可以从变量的类型推断得出。
当然，泛型也是有局限性的，例如：不能使用基本类型实例化类型参数，不能用类型参数代替基本类型，这便是我所认为的“麻烦”之处；除此之外，泛型也不能实例化类型变量，不能构造泛型数组，也不能实例化参数化类型的数组，例如：

List<String>[] ls = new ArrayList<String>[10];

但是可以使用通配符创建：

List<?>[] ls = new ArrayList<?>[10];

这是我在书上查到的能看懂的弊端，其他内容还需要大量实践去验证。

【返回目录】

代码调试中的问题和解决过程

• 【问题1】：在实现遍历测试代码时，参考了网上的示例代码，发现有几种方法都是在 Iterator 类实例化对象后使用 hasNext 迭代循环，为什么会这样固定搭配？与 next 方法有何不同？例如：

        Iterator it = c.iterator();for(;it.hasNext();)System.out.println(it.next());

• 解决方案 ：查看了课本之后发现上学期的 接口 内容有所遗忘，Iterator 接口中的两个基本方法是 hasNext 和 next ，hasNext返回一个布尔结果，next返回一个对象。这两个方法都不带任何参数。如果还有等待处理的数据项，hasNext 方法返回真，而next方法返回下一个对象。对于hasNext方法来说，如果仍有元素可以迭代，则返回 true。这相当于：如果 next 返回了元素而不是抛出异常，则返回 true。hasNext有一个索引功能，即判断下一个元素是否存在。 之所以这样搭配，就是为了迭代循环，从而成为遍历一个集合或者泛型对象的常用方法。

• 【问题2】：看了娄老师本周的教学进程之后，学习任务中有一点是：掌握Java中泛型类，泛型方法的设计。那么要如何正确定义一个泛型方法？

• 解决方案 ：首先说说泛型类，一个简单的泛型类如下：

    // 定义一个泛型类，这个T可以出现在这个泛型类的任意位置,泛型的数量也可以为任意多个static class Pair<T> {private T value;public Pair(T value) {this.value = value;}public T getValue() {return value;}public void setValue(T value) {this.value = value;}}

测试类获取并替换参数值，再获取：

public static void main(String[] args){Pair<String> pair = new Pair<>("Hello"); //实例化泛型对象PairString str = pair.getValue();System.out.println(str);pair.setValue("World");str = pair.getValue();System.out.println(str);}

在掌握了定义一个简单的泛型类之后，我从网上找到一个泛型方法的示例（仅选取一段）：

        public class Generic<T>{private T key;public Generic(T key) {this.key = key;}public T getKey(){return key;}}// 在public与返回值之间的<T>必不可少，这表明这是一个泛型方法，并且声明了一个泛型Tpublic <T> T showKeyName(Generic<T> container){  // 定义一个带有类型参数的简单方法System.out.println("container key :" + container.getKey());T test = container.getKey();return test;}

例子比较简单，容易理解。当然，关于泛型的实用性更多体现在集合中，上文提及的 Comparable 接口本身也是一个泛型类型。

【返回目录】

代码托管

• 本周代码上传至 ch13 和 Practice 两个文件夹里：
  
  （statistics.sh脚本的运行结果截图）

本周考试错题总结

• 本周无考试，上周考试错题详见第1周学习总结。

【返回目录】

结对及互评

• 莫礼钟本周状态不是很好，和上周相比落差较大，总是需要督促学习，更糟糕的是最近迷上了“狼人杀”，天天玩，通宵玩！可以说在学习上很难调动兴趣，只能凭借一时的热度，而对于生活中的其他方面显得很有情趣，我还是会继续督促他，希望他有一天能够意识到学习的重要性。

本周结对学习情况

• 20162319：未发表博客

• 结对学习内容：
  • 简单学习了《构建之法》中的内容

其他（感悟、思考等，可选）

　　这周学习的内容慢慢多了起来，课上的例子主要针对泛型、Map类和Comparable接口讲解了一些简单示例，我们小组的团队博客也渐渐开设起来，本次因为是分配学习，然后汇总写入博客，所以有我负责编辑格式。说实话，小组成员每个人自己总结的格式不同，汇总起来就比较头疼，我们会在以后慢慢改进磨合。构建之法中我也了解到所谓的“敏捷的团队”，也希望在我们每个人的贡献下，我们的团队也能成为这样的团队。
　　团队内容占用了比较多的时间，总的来说效果不错。相比之下，我这周课下泛型的学习还不够深入，只会使用几个简单的例子，因此在复习git和调试时也要多巩固泛型的语法，为下周的考试和后期学习做好准备。

【返回目录】

学习进度条

• 	代码行数（新增/累积）	博客量（新增/累积）	学习时间（新增/累积）	重要成长
  目标	5000行	30篇	400小时
  第一周	234/234	1/28	14/14	了解算法效率、大O符号等理论内容
  第二周	255/489	1/29	12/26	了解敏捷的团队、泛型的使用

• 计划学习时间：15小时

• 实际学习时间：12小时

• 有效学习时间：5小时

• 改进情况：保持了上周的状态，但还是太懒了，每天早晨的计划总是拖到晚上，做事很难集中注意力，可能是在宿舍的时间太长了，下周会减少每天在宿舍的时间。

参考资料

• 《Java程序设计与数据结构教程（第二版）》

• 《Java程序设计与数据结构教程（第二版）》学习指导

• Comparator接口与Comparable接口的区别

• Comparable接口的实现和使用

• 泛型的基本介绍和使用

• 构建之法（第三版）

【返回目录】