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-构建之法:现代软件工程-阅读笔记的主要内容,如果未能解决你的问题,请参考以下文章

《20170914-构建之法:现代软件工程-阅读笔记》

《20170914-构建之法:现代软件工程-阅读笔记》

20170914-构建之法:现代软件工程-阅读笔记

《20170914-构建之法:现代软件工程-阅读笔记》

20170914-构建之法:现代软件工程-阅读笔记

《20170914-构建之法:现代软件工程-阅读笔记》