标签：阅读 orm 沟通 理解 自我 work 运行 oss 测试的
第一章-概论：
软件 = 程序+软件工程；
软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程；
软件工程包括以下领域：软件需求分析、软件设计、软件构建、软件测试和软件维护；
软件工程和以下学科相关：计算机科学、计算机工程、管理学、数学、项目管理学、质量管理、软件人体工学、系统工程、工业设计和用户体验；
软件的特殊性：复杂性、不可见性、易变性、服从性、非连续性；
软件工程的目标：创造“足够好”的软件，所谓软件工程，就是把软件中的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】；
标签：阅读 orm 沟通 理解 自我 work 运行 oss 测试的
原文地址：http://www.cnblogs.com/SirL/p/7523520.html
