构建之法阅读笔记

阅读这本书的一个重要原因是应老师的要求，根据要发表的笔记数量，我将这本书分为三部分来阅读，第一部分为前六章，第二部分为第七章到第十二章，第三部分为最后五章。我目前已经阅读完前六章，来写第一部分的阅读笔记。

 

读完前六章之后，我发现这本书一个很大的特点就是网址很多，如果想要了解需要自己根据网址查询。我在之前阅读《大道至简》时明白：程序=算法+结构。在当时以自己的水平也只能写一个小程序。搞懂数据的结构和各种算法完全够用；但随着自己学习的不断加深，自己所要做的东西从程序升级为软件或网站。这个时候就需要明白：软件=程序+软件工程。这本书中在开头即阐释了如何将软件做好，分析客户的需求。其次，将软件的开发分为了几个阶段：玩具阶段->业余爱好阶段->探索阶段->成熟阶段。软件是逐步完善并成为一个系统的。在上学期自己做的一个随机出题系统，每个阶段都几乎符合。最开始时，仅仅用了三十几行代码就做完了，因为当时的要求很少，但随着要求的增多，自己需要改动的地方也越多。

 

软件所具有的特殊性：复杂性、不可见性、易变性、服从性、非连续性（由软件的本质所决定的），除此之外，这本书还列出了软件的其他特性

 

·有许多不同的程序设计语言

 

·软件工具和软件开发平台

 

·存在许多不同的软件开发流程

 

·软件团队中存在许多不同的角色

 

·软件通常既可以存储在磁带上，也可以存储在CD/DVD上

 

程序写完之后并不是立马就上线，还需要经过多次的测试，通过测试寻找bug，解决bug，或者进行代码优化。在之前我写的一个学生等级判断小程序中，测试时就产生了bug，例如：成绩为小数时怎么办？修改完这个bug之后，我对自己的程序结构进行了优化，使其能够更稳定的运行。一个简单的小程序都会有bug，更何况一个由多个程序组成的软件呢？

 

这本书提出了好的单元测试的标准：

 

·单元测试应该产生可重复、一致的结果

 

·单元测试应该在最基本的功能/参数上验证程序的正确性

 

·单元测试必须由最熟悉代码的人（程序的作者）来写

 

·单元测试过后，机器状态保持不变

 

·单元测试要快（一个测试的时间是几秒钟，而不是几分钟）

 

·独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性

 

·单元测试应该覆盖所有代码路径

 

·单元测试应该集成到自动测试的框架中

 

·单元测试必须和产品代码一起保存和维护

 

做完测试之后还要做回归测试，目的是：

 

（1）验证新的代码的确改正了缺陷

 

（2）同时验证新的代码有没有破坏模块的现有功能，有没有Regression

 

对于软件的效能分析，两种方法：抽样和注入。对于代码的优化，必须进行分析，否则只是徒劳。

 

在个人开发流程和实践中，向别人学习是必须的，但随着学习的不断深入，大学生应该迈出最重要的一步——管理自己的程序。

 

大学生软件工程师这条路上，明白这本书上的以下几个要点很重要：

 

·积累软件开发相关知识，提升技术技能（对具体技术的掌握，动手能力）

 

·积累问题领域的知识和经验

 

·对通用的软件设计思想和软件工程思想的理解

 

·提升职业技能

 

在工程师这条路上，学会处理个人与团队的关系、对于问题的解决过程如何把握、代码优化的时机、专和精的关系...

 

这之后软件开发过程中，必然会遇到团队合作的问题，在团队合作中必然有一些规范。

 

代码风格规范：缩进、行宽、括号、断行与空白{}行、分行、命名、大小写、下划线、注释...平时写代码的过程中，我觉得自己也有必要养成一个标准的代码规范（让人看着舒服）

 

代码设计规范：函数、goto、错误处理、处理类...

 

代码复审

 

·它的正确定义：代码是否在代码规范的框架内正确解决了问题。

 

·对于代码复审的人选：最有经验、最熟悉这一代码的人

 

·复审形式：自我复审、同伴复审、团队复审

 

·代码复审的目的：在程序早期发现问题并解决，降低成本；帮助团队之间相互理解。

 

结对编程

 

·两个角色：驾驶员（控制及那盘输入）、领航员（引航、指导）

 

·不间断复审

 

合作的不同阶段和技巧

 

·萌芽阶段->磨合阶段->规范阶段->创造阶段->解体阶段

 

·给予反馈，根据人的三个层次决定是否合作，最外层：不是故意的；中间层：平时习惯，需多加提醒；最内层：本质如此、无需多言。

 

团队和流程

 

·团队和非团队：一个是每个人互相之间都有联系，共同为一件事努力；另一个只为解决问题，每个人之间可能互相不认识。

 

软件团队的模式：

 

·主治医师模式

 

·明星模式

 

·社区模式

 

·业余剧团模式

 

·秘密团队

 

·特工团队

 

·交响乐团模式

 

·爵士乐模式

 

·功能团队模式

 

·官僚模式

 

无论每种模式，都有其优点和缺点。

 

在开发流程中，可以制定各种模型进行分析，例如：瀑布模型、生鱼片模型....

 

敏捷流程

 

敏捷开发原则：

 

·尽早并持续地交付有价值的软件以满足顾客需求

 

·敏捷流程欢迎需求的变化，并利用这些变化来提高用户的竞争优势

 

·经常发布可用的软件，发布间隔可以从几周到几个月，能短则短

 

·业务人员和开发人员在项目开发过程中应该每天共同工作

 

·以有进取心的人为项目核心，充分支持信任他们

 

·无论团队内外，面对面的交流始终是最有效的沟通方式

 

·可用的软件是衡量项目进展的主要指标

 

·敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去

 

·只有不断关注技术和设计，才能越来越敏捷

 

·保持简明——尽可能简化工作量的技艺

 

·只有能自我管理的团队才能创造优秀的架构、需求和设计

 

·时时总结如何提高团队效率并付诸行动

 

敏捷流程的问题及解决办法

 

对于快速出现的问题，不要试图一下全部解决，就像百米冲刺和110米跨栏不能同时进行。

 

项目的燃尽图跟踪值：实际花费时间、实际剩余时间、预估剩余时间

 

团队转变为敏捷团队：需要从三个方面考虑 ：自主管理、自我组织、多功能型

 

敏捷总结

 

在迭代开始时，团队审视摆在他们面前的任务，选择他们认为可以在迭代期间完成的那些任务（Plan）。然后团队独立地尽最大努力完成这些任务（Do）。在迭代结束时，团队给利益关系人展示成果（Check），并对开发流程进行调整（Act/Adjust）。

 

这里有一些实践者的经验教训：

 

·敏捷宣言表明的是一些优先级，不必当作圣旨或者教条来争论。

 

·Scrum Master不是一个官，而是一个没有行政权力的沟通者，就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master，大多行不通。

 

·一些项目需要很多暗箱操作和政治角力才能搞定，Scrum会把这些矛盾都摆到明处。这有好处，也有风险。

 

·在复杂的项目里，要让一线团队成员做决定。

 

·创业公司的团队其实经常是运行在Scrum 的模式中（只不过大家太忙，没工夫论证自己到底有多么Scrum）。

 

·在Scrum计划阶段的估计不是一个“合同”，领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint，这样即使不准的估计也不会有大的损害。

 

·不要和管理层谈“流程”，他们只关心“结果”。

 

·在大型团队、跨地区的团队，或者复杂项目中，Scrum并没有非常完美的答案，Scrum的创始人也承认这一点.