20162317 《程序设计与数据结构》第二周学习总结

20162317 《程序设计与数据结构》第二周学习总结

泛型的研究

泛型，即“参数化类型”。将类型由原来的具体的类型参数化，类似于方法中的变量参数，此时类型也定义成参数形式（可以称之为类型形参），然后在使用/调用时传入具体的类型（类型实参）。

列表的泛型

在图中可以看到，list1并没有用“<>”来确定类型，这也意味着可以往list1可以输入任何类型的数据。如图，我往list1中add String类型，int类型都没有产生报错。而下面的list2已经用“<>”来限定了列表可以承载的元素类型。如图，我向listt2中添加String类型没有报错，但添加int类型就报错了。这就是列表的泛型。实际上，由于一切的类都是Object的子类

由图中可以看出，list3与list1的效果是一样的。

泛型的类

这是一个叫做FanXingLei的类，它里面只有一个变量还有对应的getter和setter两个方法。留意类中，类名开头有个的标志，变量和方法中的参数也是T类。那T类是什么类呢？？实际上就是泛型。

可以见到在FanXingLeiTest.java中调用了FanXingLei这个类，<>中的类型可以为Integer亦或是String类都没有什么关系，但输出对应自己的类型。若如f3和f4那样调用setInformation方法填入任何类型的参数都没有问题。这就是泛型类。

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

虽说泛型增强的代码的灵活，但是还得尝试着去用，去实践。只有实践了才能消化这些知识。

学习进度条

	代码行数（新增/累积）	博客量（新增/累积）	学习时间（新增/累积）	重要成长
目标	5000行	30篇	400小时
第一周	200/200	2/2	20/20
第二周	20/220	1/3	20/40

** 团队学习：《构建之法》**

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

  　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 发布之后——事后诸葛亮会议
  这个软件生命的周期结束以后，如尸体解剖一样，把给软件的开发流程剖析一下。

第 16 章 IT 行业的创新

第 17 章 人、绩效和职业道德

问题集锦

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、理想的覆盖率分析工具是怎样的？