20170914-构建之法:现代软件工程-阅读笔记
Posted L龙先生
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了20170914-构建之法:现代软件工程-阅读笔记相关的知识,希望对你有一定的参考价值。
第一章-概论:
软件 = 程序+软件工程;
软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程;
软件工程包括以下领域:软件需求分析、软件设计、软件构建、软件测试和软件维护;
软件工程和以下学科相关:计算机科学、计算机工程、管理学、数学、项目管理学、质量管理、软件人体工学、系统工程、工业设计和用户体验;
软件的特殊性:复杂性、不可见性、易变性、服从性、非连续性;
软件工程的目标:创造“足够好”的软件,所谓软件工程,就是把软件中的Bug都消灭掉的过程;
Bug:直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性;简单地说,软件的行为和用户的期望值不一样,就叫Bug;
我们将在本书学习的目标是:1.研发出复合用户需求的软件 ;
2.通过一定的软件流程,在预计的时间内发布“足够好”的软件;
3.能证明所开发的软件是可以维护和继续发展的;
第二章-个人技术和流程:
单元测试:模块内部的改变不会影响其他模块,而且模块的质量能得到稳定的、量化的保证;
好的单元测试标准:应该能够准确、快速地保证程序基本模块的正确性;
1.单元测试应该在最基本的功能/参数上验证程序的正确性;
2.单元测试必须由最熟悉代码的人(程序的作者)来写;
3.单元测试过后,机器状态保持不变;
4.单元测试要快(一个测试的运行时间是几秒钟,而不是几分钟);
5.单元测试应该产生可重复、一致的结果;
6.独立性----单元测试的运行/通过/失败不依赖于别的测试,可以人为构造数据,以保持单元测试的独立性;
7.单元测试应该覆盖所有代码路径;
8.单元测试应该集成到自动测试的框架中;
9.单元测试必须和产品代码一起保存和维护;
效能分析工具:两种分析方法--抽样【Sampling】(优点:不需要改动程序,运行较快,可以很快找到瓶颈,但是不能得出精确的数据,也不能准确表示代码中的调用关系树【Call Tree】);--代码注入【Instrumentation】(缺点:程序运行的时间会大大加长,还会产生很大的数据文件,也相应增加了数据分析的时间;同时,注入的代码也影响了程序真实的运行情况);一般情况下,先采用抽样的方法找到效能瓶颈所在,然后对特定的模块用代码注入的方法进行详细分析;
效能分析的名词:调用者【Caller】,被调用函数【Callee】,调用关系树【Call Tree】,消逝时间【Elapsed Time】,应用程序时间【Application Time】,本函数时间【Exclusive Time】,所有时间【Inclusive Time】;
第三章-软件工程师的成长:
软件工程包括了:开发、运营、维护软件的过程中的很多技术、做法、习惯和思想;
软件开发流程:软件工程把这些相关的技术和过程统一到一个体系中;
软件开发流程的目的:为了提高软件开发、运营、维护的效率,以及提升用户满意度、软件的可靠性和可维护性;
团队对个人的期望:1.交流;2.说到做到(按时交付);3.接受团队赋予的角色并按角色要求工作;4.全力投入团队的活动;5.按照团队流程的要求工作;6.准备(准备工作);7.理性地工作;
第四章-两人合作:
代码规范:代码风格规范----1.缩进;2.行宽;3.括号;4.断行与空白的{ }行;5.分行;6.命名;7.下划线;8.大小写;9.注释;
代码设计规范----1.函数;2.goto;3.错误处理(参数处理、断言);4.如何处理类;
代码复审:自我复审,同伴复审,团队复审;
代码复审的目的:1.找出代码的错误(编码错误,不符合团队代码规范的地方);
2.发现逻辑错误;
3.发现算法错误;
4.发现潜在的错误和回归性错误;
5.发现可能需要改进的地方;
6.教育(互相教育)开发人员,传授经验,让更多的成员熟悉项目各部分的代码,同时熟悉和应用领域相关的实际知识;
结对编程:起源于1987年Intuit公司的两个技术人员;因任务具有高速中完成、较高的技术要求和任务失败的高代价,所以采取结对编程模式;角色分工:驾驶员【Driver】:控制键盘输入,领航员【Navigator】:起到领航、提醒的作用;角色可以互换,建议定时更换驾驶员;
开发中的复审主要包括:设计复审、代码复审、测试计划复审和文档复审;
结对编程和传统开发过程的复审区别:传统意义上的伙伴复审,即程序员之间的互相复审,存在以下问题:
1.复审人缺乏对程序的深入了解,减弱了复审的效果;
2.不能持久、定时地进行复审;
3.对需求和设计的不了解导致无法实现全面有效的复审;
团队复审是指多于两人的团队就某一程序实体进行的复审,团队复审的缺点在于:
1.不可能一个团队天天开会;
2.牵涉的人员众多,理解程度不一,复审的速度和效果不能得到有效的平衡;
3.正是由于成本问题,无法对所有的设计和代码进行深入的复审;
4.由于人员众多,有面子问题;
两人合作的不同阶段:
1.萌芽阶段【Forming】,2.磨合阶段【Storming】,3.规范阶段【Norming】,4.创造阶段【Performing】,5.解体阶段【Deforming】;
影响他人的方式:
1.断言(感情,推----主动推动同伴做某事);
2.桥梁(逻辑,拉----吸引对方,建立共识);
3.说服(逻辑,推----让对方思考);
4.吸引(感情,拉----描述理想状态,吸引对方加入);
评论他人的三种层次:
1.最外层:行为和后果;
2.中间层:习惯和动机;
3.最内层:本质和固有属性;
第五章-团队和流程:
团队的共同特点:1.团队有一致的集体的目标,要一起完成这个目标;2.团队成员有各自的分工,互相依赖合作,共同完成任务;
软件团队的模式:一窝蜂模式【Chaos Team】,主治医师模式【Chief Programmer Team,Surgical Team】,明星模式【Super-star Model】,社区模式【Community Model】,业余剧团模式【Amateur Theater Team】,秘密团队【Skunk Work Team】,特工团队【SWAT】,交响乐团模式【Orchestra】,爵士乐模式【Jazz Band】,功能团队模式【Feature Team】,官僚模式【Bureaucratic Model】
开发流程:写了再改模式【Code-and-Fix】,瀑布模型【Waterfall Model】,瀑布模型的各种变型----生鱼片模型、大瀑布带着小瀑布,统一流程【RUP(Rational Unified Process)】,老版驱动的流程【Boss-Driven Process】,渐进交付的流程【Evolutionary Delivery】、MVP和MBP,TSP的原则【Team Software Process】;
第六章-敏捷流程:
敏捷流程:一系列的价值观和方法论的集合;
敏捷开发的原则:
1.尽早并持续地交付有价值的软件以满足顾客需求;
2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势;
3.经常发布可用的软件,发布间隔可以从几周到几个月,能短则短;
4.业务人员和开发人员在项目开发过程中应该每天共同工作;
5.以有进取心的人为项目核心,充分支持信任他们;
6.无论团队内外,面对面的交流始终是最有效的沟通方式;
7.可用的软件是衡量项目进展的主要指标;
8.敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去;
9.只有不断关注技术和设计,才能越来越敏捷;
10.保持简明----尽可能简化工作量的记忆----极为重要;
11.只有能自我管理的团队才能创造优秀的架构、需求和设计;
12.时时总结如何提高团队效率,并付诸行动;
敏捷的步骤:
第一步,找出完成产品需要做的事情----Product Backlog;
第二步,决定当前的冲刺【Sprint】需要解决的事情----Sprint Backlog;
第三步,每日立会,外部人士不能直接打扰团队成员,一切交流只能通过Scrum大师【Scrum Master】----冲刺阶段【Sprint】;
以上是关于20170914-构建之法:现代软件工程-阅读笔记的主要内容,如果未能解决你的问题,请参考以下文章