构建之法

成员及分工

组长&程序猿：20162311张之睿······C4-6
程序猿：20162324春旺······C13-15
博客匠&市场推广营销小能手：20162325金立清······C16-17
20162309邢天岳······C1-3
20162312张家铖······C7-9
20162313苑洪铭······C10-12

返回目录

内容简介

- 软件工程牵涉的范围很广, 同时也是一般院校的同学反映比较空洞乏味的课程。 但是软件工程的技术对于投身IT 产业的学生来说是非常重要的。作者邹欣有长达20年的一线软件开发经验，他利用业余时间在数所高校进行了长达6年的软件工程教学实践，总结出了在16周的时间内让同学们通过 “做中学 (Learning By Doing)” 掌握实用的软件工程技术的教学计划，并得到高校师生的积极反馈。在此基础上，作者对软件工程的各个知识点和技能要求进行了系统性整理，形成教材。 本书共分17章，对照美国ACM/IEEE2013年新出版的计算机科学教学指导（Computer ScienceCurricula 2013）中的软件工程相关部分，这本教材覆盖了其中大多数Core-Tier1和Core-Tier2的内容。可以说，全书对软件工程内容的覆盖不逊于任何一本现行的教材，同时讲述了业界最新实践方法。

返回目录

作者简介

- 邹欣现任微软Windows中国工程团队首席研发总监。1996—2003年，邹欣在微软Outlook团队从事开发工作，2003—2005年，他在微软内部质量工具团队和Visual Studio团队负责软件项目管理工具的开发。2005—2012年，他担任微软亚洲研究院技术创 新组研发主管，负责研究成果的产品化和创新项目。2012—2014年，他担任微软亚洲互联网工程院首席研发总监，负责必应搜索客户端、必应输入法、必应词典等产品。加入微软前，邹欣从事过商用Unix系统、GPS/GIS软件开发及测试工作。他在2007年出版了《移山之道》，于2008年出版了《编程之美》 （合作）。他于1991年获北京大学计算机软件专业学士学位。1996年获美国美国韦恩州立大学（Wayne State University）计算机软件专业硕士学位。 微博　http://weibo.com/sdxinz 博客　http://www.cnblogs.com/xinz 专栏　http://zhuanlan.zhihu.com/goujianzhifa

返回目录

分章学习及发现问题

  • 第一章 概论

  • 第二章 个人技术和流程

  • 第三章 软件工程师的成长

Points

  • 构建之法从什么是软件工程介绍到职业道德，不仅仅讲技术还告诉我们团结的力量，不仅仅讲理论还让我们不断的实践，第一章写的是软件工程的发展史，从开始到应用，所经历的过各种变化；第二章编程代码要要懂得团体的力量，合作取得双赢；第三章提到了成为软件工程师所要具备的条件。前三章通过具体的例子清楚地表述了一个个人开发的软件工程师所需要具备的能力，以及在面对程序设计细节问题上的处理。同时，也以四则运算这一简单程序的设计来体现了一个软件的发展，随着要求的提升，难度也在逐渐提升，会遇到的差错也在逐渐增加，这就需要软件工程师自身的能力来减少误差的发生。同时，也需要工程师投入大量的时间和精力进行实践，判断一个工程师的个人能力，实践效率包括测试方法的熟练掌握也是重要的一点。

Questions

  • 问题一
    现实的开发过程中往往会比理论中多出很多问题，作为软件开发者，我们是否需要先设计好所有的可能漏洞再进行实际操作，还是应该“做中学”，将需求细化到任务，然后在细化到设计，最终使得能够在规定的时间内有条不紊的完成目标？
软件开发是一个工程，有时只是一个小项目，有时可能是一个要耗费大量人力和精力的大项目，而软件工程的目标就是创造“足够好”的软件，当软件的可靠度和可维护性较高，模板清晰问题较少，则可以在编译过程中直接开始，在开发过程中也可以解决，如果是工程量巨大的项目，则在设计过程中就要开始考虑细节问题，同时也要在做中不断细化。
  • 问题二
    如果最后做性能测试的时候发现性能问题造成的原因是前期一个细微而不起眼的不妥当架构造成的，这个时候该如何取舍？或者该用什么样的方法来进行补救？
关注出现问题的本质以及问题的性质，如果是在逻辑上的根本错误导致编译错误，就需要调整整个编译框架和设计思路。
  • 问题三
    虽然绝大部分的软件开发都是由多人合作完成，但不同的人所编译的风格和习惯都有所不同，就个人开发技术流和多人开发技术流一直到团队开发技术流，各有什么优劣？
正如[个人与团队是永远的核心][1]说的那样：再好的方法论都需要由个体去实施，而个体不可能是全能，因此我们需要团队。
技术人员都有那么一些”个人英雄”主义的情结,但一般只要是复杂的系统项目,更需要的是整个开发团队的通力合作，所以个人独特的编译风格和习惯可以有，但针对某个项目团队中达成一致的条款必须遵守，这也有利于彼此交接无障碍，工作更高效。
  • 问题四
    就一个软件工程师的发展及成长来说，是个人技术素养和水平的提升更重要，还是其所处的发展平台和发展空间更有优势？
就个人开发水平而言，提高水平是关键，而软件工程师所处的大环境和所能接触到的人无疑对其自身的开发水平和业务能力有很大帮助。

返回目录

  • 第四章 两人合作

Points

  • 1.代码在书写、设计上需要规范
    无论写代码使用哪种风格，都要有规范，我们设计的代码要让其他人能看得懂，最好遵从简明，易读，无二义性的代码风格的原则。

  • 2.代码复审
    不论是自己编程还是两人合作，或者是团队合作，都不能忽略代码复审。自我复审可以找出自己的错误，不断提升自己；同伴复审更容易找出错误；团队复审有教严格的规定和流程。总之，代码复审不仅能找出代码的错误，还可以起到教育开发人员、传授经验的作用。

  • 3.结对编程
    这是将代码复审运用到极致的一种模式，这种思想也就是极限编程。结对编程如果真的做得好，可以实现不间断的代码复审，这对于项目开发有很大好处。当然，要真正学会结对编程，还需要了解两人合作的不同阶段的技巧，需要两个人不断磨合，才能发挥出结对编程最大的作用。

  • 第五章 团队和流程

Points

  • 1.团队和非团队
    团队有一致的目标，团队成员各自分工，共同完成任务。而非团队则是只是一群人聚在一起干一件事，干完就一哄而散。

  • 2.软件团队的各种模式
    书上列举了十种模式，我就不一一赘述。其实不同的模式适用于不同的情况，我们要根据实际情况具体分析，从而决定使用哪种模式

  • 3.开发流程的模式
    书上介绍了六种模式，和软件团队的模式一样，没有哪个是万能的。只有分析清楚项目的具体情况，才能根据实际作出正确的选择。

  • 第六章 敏捷流程

Points

  • 1.什么是敏捷流程
    我这里把敏捷理解为快，即尽可能快的把成果交付给用户。在进行敏捷开发时，各个步骤的时间都在保证质量的情况下尽可能快。而如果遇到问题，则是等冲刺阶段结束再说。
  • 2.敏捷总结
    不是所有团队都适合敏捷流程，如果团队很弱，强行把敏捷流程套在上面也没有用。敏捷对项目的众多要求采用分而治之的方法，在短时间内解决部分问题。将敏捷发挥到极致，也是一种极限编程。同时，敏捷不是“银弹”，不能解决所有问题。

Questions

  • 第四章的代码设计规范中，有一条语句“Goto”,不知道是什么意思
解决办法：上网查找，发现是C语言中的语句，于是询问懂C语言的同学，其实是“跳转”的意思，即跳转到Goto后面的内容。

返回目录

  • 第七章 实战中的软件工程

  • 第八章 需求分析

  • 第九章 项目经理

Points

  • MSF:
    1.沟通：宁可过分沟通、使用团队协作服务器（TFS或者GitHub）
    2.为共同的远景而工作：有明确的共同目标、由“有远见的人”提出目标、再公开讨论、凝聚共识、消除误解
    3.充分授权和信任：成员、团队间是平等协作关系，自上而下，每个人有权力估计并决定自己任务需要的时间 可使用VSTS系统支持
    4.各司其职，对项目共同负责：明确：1.谁负责 2.做什么，具体的执行方案，什么时候“做好了” 3.什么时候开始，什么时候结束
    5.重视商业价值，提供渐进价值：重视客户需求
    6.保持敏捷度，预期和适应变化：我们应预期变化而不是期望变化
    7.投资质量：1.效率 2.时机 3.长期 解决用户问题第一
    8.学习所有经验：在学习过去的经验的同时，也要避免让过去的经验妨碍解决现在的问题。 first,把经验总结出来 then,分享它

Questions

MSF中反复强调了重视商业价值，而其中最重要的是重视客户需求，而最近全球大热的一款游戏绝地求生似乎却反其道为之，在几百万玩家呼吁加快游戏优化，优化服务器质量，开发公司蓝洞却是置若罔闻，服务器崩溃日均破1，做为一个成熟的游戏开发公司，为什么会做出这样有悖MSF的决策？

解答：后来我通过网上的资料介绍了解到，蓝洞公司只是一个比较小的开发团队，对于维护一个活跃玩家近亿的游戏的服务器实在是力有不逮，而游戏优化也不尽如人意，并非是他们无视客户需求，主观违背MSF原则，而是当前的条件实在难以解决客户的问题。就在前几日，蓝洞将绝地求生国服的代理权交给腾讯也是出于对中国玩家客户需求的考虑。

返回目录

  • 第十章 典型用户和场景

Points

  • 1.在软件设计过程中，以自己对使用产品的习惯和对软件行业的熟悉程度出发，忘记对于不同用户之间差别的软件设计方式不可取，同时搞一个典型用户会强迫我们在考虑问题时从用户的角度出发。同时典型用户的定义也有区别，例如将典型用户分为受欢迎的和不受欢迎的用户，同时从两种用户的方向进行考虑。

  • 2.典型场景方面则需要根据具体场景与典型用户在该场景下的需求来进行区别考虑，针对每一个场景，设计一个场景入口，接着描述典型用户在这个场景中所处的内部和外部环境，然后根据场景划分优先级，按优先级排序来编写场景。即针对一个交易性网站而言，它的用户既可以是买家也可能是卖家，也可能是任意的浏览者，亦或是不受欢迎的黑客或者广告发布者，由场景到任务，有了场景，就可以根据子系统或者模块的所属关系把场景划分开。

  • 3.用例（use case）方面，原则方面，首先通过讲简单的故事来传递信息，其次保持对全系统的理解，其三关注用户的价值，其四逐步构建整个系统，一次完成一个用例，其五增量开发，逐步构建整个系统，其六适应团队不断变化的需求。局限性：存在某些场景不适用于交互式的系统，其二故事的颗粒度没有统一的标准，其三，如果软件的关键在于用户体验的细节，那么如何把这些UI的细节嵌入每个故事中且保证故事的简明性。

  • 4.规格说明书，分为软件功能说明说与软件技术说明书，功能说明书需要定义好相关的概念，规范假设情况，避免误解并限定边界情况，描述主要交互步骤，同时将副作用写出来，服务质量的说明也需要明确提出以免出现以讹传讹的情况。技术说明书则主要需要保持原则问题，抽象、模块化、信息隐藏及封装、界面和实现的分离等等均为技术说明书的原则。

  • 5.功能驱动设计：简称FDD，第一 构建总体模型，第二，构造功能列表，第三，制定开发计划，第四，功能实现阶段，第五，实现具体功能。同时FDD适用于团队成员对于需求没有切身体会的情景。

  • 第十一章 软件设计与实现

  • 1.分析和设计方法：通过软件解决用户的需求，整个软件开发过程都需要我们表达、传递和处理很多不同阶段的信息，如在需求分析阶段，需要确定，在现实世界中，哪些是实体，如何抽象出我们真正关心的属性，实体之间的关系是什么，在这个基础上，用户的需求是什么，软件如何解决用户的需求等等问题。

  • 2.图形建模与分析方法：我们要给事物建造出一个模型，描述事物、事物的属性、事物之间的关系以及各个事物之间的信息联系。表达实体与实体之间的关系通常使用思维导图、实体关系图UCD等方式。其它设计方法例如形式化的方法、文学化编程等方式。

  • 3.开发阶段的日常管理，闭门造车不可取，每日构建可以有效提升团队的积极性，构建大师称号授予导致构建失败的成员，来让构建大师负责管理构建服务器、调试构建负责找出构建的错误的原因、负责将构建大师的称号与责任交给下一个导致构建失败的成员，同时对于管理团队成员的过程中，宽严皆误，既不可以过于宽松也不可以过于严苛，小强地狱，小强指的是编写程序是的BUG，让BUG多的成员专心修复BUG，不要去开发新的功能。

  • 第十二章 用户体验

  • 1.考虑用户体验的各种角度，设计的层次，步骤和目标，认知阻力，用户体验的衡量标标准，情感设计，跨设备的用户体验等方面。

  • 2.用户体验的要素，首先用户体验的第一印象，这个问题可以通过前文中典型用户与典型场景的假设来进行具体性分析，同时在设计后应当通过5W1H的方法来判断是否是一个好的设计。同时从用户的角度来考虑问题，即软件团队的设计师和软件工程师要具有同理心的问题。同时在软件服务要始终记住用户的选择，例如在一开始用户选择的是英文，但是因为其它原因，在其后的选择中，由此原因而引起的诸如中英文互相编译的问题而出现的乱码，而这种问题正需要“基于场景的设计”来强化团队成员对于成员体验连贯性的理解。同时在设计时不应让用户犯简单的错误，用户体验与质量，需要将用户体验与软件质量维持在一个平衡中，在保持质量的同时尽量实现用户体验的舒适化。

  • 3.评价标准，尽快提供可感触的反馈，系统界面符合用户的现实惯例，用户需要有控制权，软件中要保持一致性和标准化，同时软件要适用于各种类型的用户，帮助用户识别诊断并且修复错误，同时提示和帮助文档极其必要。在多设备的用户体验，不仅仅是软件所在的操作系统的不同，同时也需要考虑用户使用设备的不同，用心选择参考系，通过不同的参考系对比，设计出在不同情况下表现形式不同的同一程序。

Questions

对于一个软件设计，一个有所作为的程序设计往往是由不仅一个团队来进行，而每个团队对于用户的看法于标准不同，当用户使用程序不同部分而出现不同的感觉，而不同的团队间对于用户的标准不同也是在长期实践下的结果，因此在这种情况下出现的差异，仅仅通过磨合与让步是不现实的，该如何解决这种问题？

返回目录

  • 第十三章 软件测试

Points

  • 基本名词：
    Bug：软件的缺陷；
    Test Case ：测试用例；
    Test Suit：测试用例集；
    测试的分类：
    按方法分类：
    黑箱和白箱

  • 按目的分类：

  • 功能测试：

  • 非功能测试：



  • 不同的测试方法：

  • 具体的例举了：

  1. 单元测试和代码覆盖测试；（第二章中介绍）
  2. 构建验证测试：在构建完成后系统自动运行一套测试，验证系统的基本功能；
  3. 验收测试：对系统的各个方面进行验收测试；
  4. “探索式”测试：为某一个特定的目的进行的测试；
  5. 回归测试：（第二章介绍）
  6. 场景/集成/系统测试：对软件进行全面和系统的测试，以保证软件的各个模块都能共同工作；
  7. 伙伴测试：找一个测试人员作为伙伴对新代码进行测试；
  8. 效能测试： 软件设计负载内能否提供令客户满意的服务质量；
  9. 压力测试：测试软件在超过设计负载的情况下的运行情况；
  10. 还有内部/外部公开测试、易用性测试等。

  • 十四章 质量保障

Points

  • 1.软件的质量：
    在本节的开头有两个这样的公式：

软件 = 程序 + 软件工程

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

  • 程序质量：
    1.软件外在功能的质量；
    2.软件工程的质量：
    3.开发过程的可见性
    4.开发过程的风险控制
    5.内部模块的交付质量
    6.开发成本的控制
    7.内部质量指标的完成情况

  • 测试中的常见的几个问题：
    1.既然有专人负责质量，那我就不用负责了！
    2.盲目信任“专业人士”扮演的角色
    3.为了自己的角色而做绩效优化
    4.画地为牢的分工
    5.无明确责任的分工

  • 第十五章 稳定和发布阶段

Points

  • 名词简介：
  1. Alpha： 指集成了主要功能的第一个试用版本。在这个版本中有些小功能并未实现。
  2. Beta： 功能基本完备，稳定性较Alpha版本高，用户可以在实际工作中小范围使用，可以有 Beta1、Beta2、Beta3 2 ……
  3. ZBB（Zero Bug Build）：某天的版本要把在之前（例如48小时前）记录的Bug都解决掉。
  4. RC（Release Candidate）：发布候选版本，RC1、RC2……直到RTM为止，版本间隔时间较短。
  5. RTM（Release To Manufacturer）：最终发布版本。如果某一个RC版本没有很大的问题， 那么这一RC就会成为最终的版本，通常情况下，软件公司会把最终的版本和相关的 文件及其他资料交给另一个团队（Manufacturer）去包装、刻制光盘。在App Store/ Marketplace的年代，我们有相应的RTM（Release To Market）。
  6. RTW（Release To Web）：要依赖“Web”来发布我们 的最终版本。如果软件产品是一个网站服务，则一般会交给网站运营团队（Operation Team）去管理，这样的发布也可以叫做RTO（Release To Operation），运营团队和 研发团队一起决定什么时候系统上线（Go Live）。把软件提交到各个应用商店则可以 称为 Release To Store

会诊小组；
复杂项目的会诊；
设计变更；
ZBB = zero bug build,已经解决所有bug；
最后回归测试；
砍掉功能；
修复bug的门槛逐渐提高；
逐步冻结；

不同频率和不同覆盖范围的渐进发布：
发布之后--------事后诸葛亮会议。

Questions

在书中提到用户的体验和产品的质量同样重要的观点，但是很明显他们有时也会有一定的冲突，在产品发布之后为了保证质量就会有相应的更新，但是这就大大的降低了用户的体验度，就在发生类次的冲突时应该如何取舍才可以保证两者之间的平衡？

返回目录

  • 第十六章 IT行业的创新

Points

  • 创新的同时需要重视用户，书中举例铱星计划（Iridium）的手机，它凝聚了多种先进技术，只往天上发66颗卫星把地球全覆盖，大家就可以随时随地打电话了。这比在地面上每隔几十公里就建造一个移动通信基站要好不知道多少倍。但是它没有了解客户，当时需要用手机的大部分集中大城市里需要在室内打电话。但是，在室内反而铱星电话通讯效果差。由于使用了卫星通讯技术，铱星的带宽、延时都比不上普通手机。它不到一年就申请破产保护了。

  • “对于颠覆性的技术，我们需要计划，但这个计划的目的是为了找到新技术的合理使用场景， ”换而言之还是在估计和预测用户的需要。所以我觉得IT技术的创新本质上是在了解自己的核心技术的基础上要重视用户，用户才是盈利和决定成败的关键之所在。

  • 文中举出创新的时机：先写论文从理论上论证其可能性（创新者阶段），然后做出原型供先行者尝鲜（早期采用者阶段）。随后广大人民群众中觉悟高的开始接受新技术（早期大众阶段），再传播到晚期大众（Late Majority），最后落伍者（Laggards）都开始使用这个新技术了。所以我觉得有时是时势造英雄，无数IT成功者正赶上了计算机发展最迅速，最蓬勃的时代。这也应该是IT创新的时机所讲的吧。

Questions

书上说，“创新的关键是技术还有要成为领域的专家，才能创新“”，但假设我有一个非常好的灵感，认为这会是一个很有前景和市场的软件，可实现出来是非常困难的，非我们学生之力所及，这就不能算创新了吗？如果这个构想由实力强的技术团队来完成，那么创新的究竟是想出这个idea 的人，还是实现它的人呢？亦或都？

  • 第十七章 人，绩效和职业道德

Points

  • 1.RASCI模型

　　　　R：Responsible，负责把具体事情做好

　　　　A：Accountable，对任务负全责，有批准的权利

　　　　S：Support，对任务提供支持，辅助任务的完成

　　　　C：Consulted，咨询，拥有完成项目所需的信息或能力的角色

　　　　I：Informed，知会者，应该事后及时通知结果的角色

  • 2.团队合作的阶段：

　　　　<1>、萌芽阶段，就像小苗破土而出，柔弱但充满希望

　　　　<2>、磨合阶段，就像一个人的青少年时期，充满了对个人、同伴和团队的疑惑和冲突

　　　　<3>、规范阶段，从磨合阶段毕业，进入规范阶段的团队，成员们意识到光争吵时没有用的，大家还是要协同作战

　　　　<4>、创造阶段，经历了萌芽、磨合、规范阶段，现在团队终于可以创造一些有意义的东西

  • 3.不管从事哪一个职业，不管你是属于哪个岗位上的，都必须具有职业道德，软件工程师同样也需要

返回目录