构建之法第11,2,3,4章小结与感悟

第11章 软件设计与实现

11.1分析和设计方法

在”需求分析“‘，”实现和设计阶段“，在”测试“和”发布“阶段，要搞清楚一些重要启示。

11.2图形建模和分析方法

我们给事物建造出一个”模型“，描述事物，事物的属性，事物之间的关系以及各个事物之间的信息传递。

1 表达实体和实体之间的关系

思维导图 ，实体关系图

2 数据表的流动，有什么数据流过呢，拿图书系统为例。

1.和管理机构相关的数据流

2.和读者相关的数据流

3.和新书入库相关的数据流

4.和时间相关的数据流

11.3其他设计方法

形式化的方法 文学化编程

11.4从Spec到实现

此处写了一个开发人员拿到了设计文档（Spec）之后做的几件事

1 把修改集集成到代码库中

步骤：1.根据场景和开发任务来决定集成的次序

             2.互相依赖的任务要一起集成

             3.在测试场景时，要保证端到端的测试

             4.场景的所有者必须保证场景完全通过测试，然后把场景的状态改为”解决“

2 开发人员的标准工作流程

3 代码完成

11.5开发阶段的日常管理

1 一个“闭门造车”的故事

2.每日构建

3 构建大师

4宽严皆误

5小强地狱

感悟：用户体验对于整个软件完成的成败十分重要，设计的界面给用户的第一印象是什么？作为一个软件设计者，必须站在用户的角度思考，也称之为“同理心”。此章举了许多例子，比如不让用户犯同样的错误等等。以及情感设计也是十分重要的。

第2章 个人技术和流程

2.1单元测试

单元测试是一个很有效的解决方案。

1 用VSTS写单元测试

创建单元测试的主要步骤是：

1.设置数据

2.使用被测试类型的功能

3.比较实际结果和预期的结果

2.好的单元测试的标准

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

单元测试必须由最熟悉代码的人来写

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

单元测试要快

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

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

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

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

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

3回归测试

针对一个BUG FIX 要做REGRESSION TEST，目的是：

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

2.同时要验证新的代码有没有破坏模块的现有功能，有没有REGRESSION

2.2效能分析工具

1.抽样

2.代码注入

2.3个人开发流程

不局限于某一种软件技术(如编程语言)

不依赖于考试

在小型，初创的团队中，很难找到高质量的项目需求

PSP依赖于数据

PSP的目的是记录工程师如何实现需求的效率

感悟：想要组件一个软件设计团队，首先要保证团队中的都是软件工程师，个人的技术在团队中也起着非常重要的作用。此章中介绍了各种测试自我技术的方法。效能分析工具等，软件需要回归测试。

第3章 软件工程师的成长

3.1个人能力的衡量与发展

初级软件工程师如何成长，有以下成长。

1.积累知识，提升技术技能。

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

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

4.提升职业技能

5.实际成果

3.2软件工程师的职业发展

1.职业发展——考级之路

2.职业成长——STEVE MCCONNELL

3大公司版本

4.自我评估

3.3技能的反面

感悟：当一个技术人员在工作岗位上工作久了，她的技术和个人能力就会得到提升，对于这样的人来说，如何检验自己的技术和成长，此章中就对此有详细介绍。职业的发展有考级制度等等，我想对于一个长久的工程师来说，能力成长十分重要，一个工高级工程师和早期的程序员的待遇薪资也是天差地别。

第四章 两人合作

4.1 代码规范

分成两个部分

1.代码风格规范。主要是文字上的规定，看似表面文章，实际上非常重要。

2.代码设计规范、牵涉到程序设计，模块之间的关系，设计模式等方方面面的通用原则。

4.2代码风格规范

原则：简明，易读，无二义性

1.缩进

2行宽

3.扩好

4断行与空白的{}行

5分行

6命名

7下划线

8大小写

9注释

4.3代码设计规范

结论：现在我明白了代码规范非常重要，因为团队合作，需要让别人看懂你的代码。

4.4代码复审

代码复审的目的在于：1.找出代码的错误 2找出逻辑的错误 3发现算法的错误 4发现潜在的错误和回归性错误 5 发现需要改进的地方 6 教育开发人员，传授经验。

4.5结对编程

4.6两人合作的不同阶段和技巧

感悟：现在的代码由一个人单枪匹马地完成已经很少见了，本章的两人合作也叙述了完成代码时要注意格式，不然让合作对象很难理解。我认为代码即使有个人风格，也要确保能让别人看得懂并且能改。学会写注释。代码设计要规范，代码要复审。两个人也要一步一步经过各种磨合，能够正确给予别人反馈。

 

转载于:https://www.cnblogs.com/wuyuan1223/p/5470418.html