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

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

泛型的研究

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

列表的泛型

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

泛型的类

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

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

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

学习进度条

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

• → →

  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测试，通过态度、行为、定性、定量来规范调研的尺度。
  

五、开发阶段的日常管理

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

六、实战中的源代码管理

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

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

七、代码完成

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

第 12 章 用户体验

一、用户体验的要素

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

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

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

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

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

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

第 16 章 IT 行业的创新

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

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

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

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

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

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

6、该如何使单元测试给自动化/p>

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

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

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

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

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

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

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

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

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

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

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

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

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

20、结构和实现又有什么样的关系/p>

21、代码覆盖率是什么重要在哪/p>

22、理想的覆盖率分析工具是怎样的/p>

文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览34618 人正在系统学习中 相关资源：Scrum敏捷软件开发_敏捷开发-专业指导文档类资源-CSDN文库