20162330 2017-2018-1《程序设计与数据结构》第二周学习总结

时间 2019-11-14

标签程序设计与数据结构第二学习总结栏目软件设计繁體版

原文原文链接

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

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
袁逸灏	第一、二、3章
刘伟康	第四、五、6章
刘先润	第七、八、9章
马军	第十、十一、12章
刘诚昊	第1三、1四、15章
莫礼钟	第1六、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、典型用户

1.典型用户
定义：描述了一组用户的典型技巧，能力，须要，工做习惯和工做环境。
电影用户的角色：也有受欢迎的和不受欢迎之分。
典型用户的完善：定义了一部分典型用户后继续与其中表明进行沟通，进一步完善需求理解。
2.从典型用户到场景
场景：也能够是故事，用户为达到目标使用系统时经历的全部过程。
场景的使用：设计者模拟用户，设计一个场景入口，描述用户在这个场景的内外部因素，给场景划分优先级并写场景。
3.从场景到任务
分层：沿着子系统/模块的所属关系把场景划分开。（例如：P221.UI层，逻辑层，数据库）
任务与场景：不一样的任务将会把一个场景编织起来，获得开发任务后，能够建立和分配测试任务。

2、用例(Use Case)

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

3、功能说明书（Spec）

1.规格说明书
软件功能说明书：说明软件的外部功能和用户的交互状况。（软件是一个黑盒子，看不到内部）
软件技术说明书：又称设计文档，说明软件的内部的设计规范。（透明盒子）
2.功能说明书
从用户的角度描述软件产品的功能，输入，输出，界面，功能的边界问题，功能的效率（to user），国际化，本地化，异常状况等，不涉及软件内部的实现细节。
3.制定一份Spec
定义好相关的概念，规范好一些假设；避免一些误解，界定一些边界条件（定性且定量）；描述主流的用户/软件交互步骤；一些好的功能还会有反作用，服务质量的说明。
4.Spec的弊端
枯燥乏味，没法跟上时间的变化。
5.技术说明书
设计文档，用于描述开发者如何趋势线某一功能，或相互联系的一组功能。实现软件功能没有固定的模板，但总存在着一些规律。

4、功能驱动的设计

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

第 11 章软件设计与实现

1、分析和设计方法

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

2、图形建模和分析方法

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

3、其余设计方法

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

4、从Spec到实现

1.预估开发时间
2.写一些快速成型代码，看当作效，查找问题。
3.看到初始效果与了解实现细节后，开始写设计文档，并与同事进行复审。
4.按照设计文档写代码，解决遇到的问题。
5.写好代码后先根据设计文档与代码指南进行自我复审，重构代码。
6.重建或更新单元测试。
7.获得一个能够测试的版本，交予相关测试人员测试或者公开测试。
8.修复测试中发现的问题。
9.根据代码复审的意见修改代码，完善单元测试和其余相关代码，把新的代码签入到数据库中。
2. 把修改集集成到代码库中
根据场景和开发任务来决定集成的次序、互相依赖的任务要一块儿集成。
在测试场景时，要保证端对端的测试。
场景的全部者必须保证场景彻底经过测试，而后把场景的状态改成“解决”。
3.开发人员的标准工做流程（以下图所示）

5、开发阶段的平常管理

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

6、实战中的源代码管理

软件 = 程序 + 软件工程
软件的质量 = 程序的质量 + 软件工程的质量
代码须要版本管理
在源代码基础上进行修改后，留下新版本以及对应的负责人记录，记载bug的内容，处理人，处理时间，是否处理完成等内容以备查验。

7、代码完成

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

第 12 章用户体验

1、用户体验的要素

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

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

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

3、评价标准

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

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

第 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三、一个团队成熟的标记，就是对风险的管理，在《构建之法》中如是说，咱们对待风险该采起什么样的态度呢？

1四、关于项目经理PM，书中提到一个团队能够有不少PM，若是一个团队中针对一个项目造成了多个决议，这种窘况该如何解决呢？

1五、project manager 和 program manager 的区别在于前者管事也管人，后者只管事无论人，因此PM须要有很强的领导力吗？

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

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

1八、在设计典型场景时须要保持模拟内容的简明性仍是模拟全部可能发生的事件，不管是否与需求有关？

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

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

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

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

【返回目录】

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

【问题】我在最开始接触泛型时以为泛型的语法有些麻烦，对于数组来讲自身就有定义方式，那么相对于其余类、其余方法，泛型有哪些的好处，又有哪些弊端？
解决方案 ：课堂上听完娄老师对泛型的讲解，课后也阅读了相关资料，大体了解了泛型的好处。首先，泛型程序设计意味着编写的代码能够被不一样类型的对象屡次重用，然而在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"); //实例化泛型对象Pair
        String 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>必不可少，这代表这是一个泛型方法，而且声明了一个泛型T
        public <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小时
改进状况：保持了上周的状态，但仍是太懒了，天天早晨的计划老是拖到晚上，作事很难集中注意力，多是在宿舍的时间太长了，下周会减小天天在宿舍的时间。

参考资料

【返回目录】

20162330 2017-2018-1《程序设计与数据结构》第二周学习总结

目录

本周学习内容总结

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

2. 泛型方法设计

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

第 1 章概论

第 2 章我的技术和流程

第 3 章软件工程师的成长

第 4 章两人合做

第 5 章团队和流程

第 6 章敏捷流程

第 7 章 MSF

第 8 章需求分析

第 9 章项目经理

第 10 章典型用户和场景

第 11 章软件设计与实现

第 12 章用户体验

第 13 章软件测试

第 14 章质量保障

第 15 章稳定和发布阶段

问题集锦

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

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

代码托管

本周考试错题总结

结对及互评

本周结对学习状况

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

学习进度条

参考资料

20162330 2017-2018-1《程序设计与数据结构》第二周学习总结

目录

本周学习内容总结

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

2. 泛型方法设计

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

第 1 章 概论

第 2 章 我的技术和流程

第 3 章 软件工程师的成长

第 4 章 两人合做

第 5 章 团队和流程

第 6 章 敏捷流程

第 7 章 MSF

第 8 章 需求分析

第 9 章 项目经理

第 10 章 典型用户和场景

第 11 章 软件设计与实现

第 12 章 用户体验

第 13 章 软件测试

第 14 章 质量保障

第 15 章 稳定和发布阶段

问题集锦

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

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

代码托管

本周考试错题总结

结对及互评

本周结对学习状况

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

学习进度条

参考资料

第 1 章概论

第 2 章我的技术和流程

第 3 章软件工程师的成长

第 4 章两人合做

第 5 章团队和流程

第 6 章敏捷流程

第 8 章需求分析

第 9 章项目经理

第 10 章典型用户和场景

第 11 章软件设计与实现

第 12 章用户体验

第 13 章软件测试

第 14 章质量保障

第 15 章稳定和发布阶段