《构建之法》读书笔记#
——构建之法第二版（邹欣著）
目录
- 第二次作业实践经历
- 结合招聘信息对AGV小车控制软件工程师知识能力分析
- 基于模型的设计流程的优缺点
- 结合实际案例对基于模型设计方案的改进
- 其他收获
第二次作业实践经历
——结合书中工程师能力评估和发展
书中一开始引用足球的例子，引入个人能力和团队能力的关系，类比到软件工程师，一个软件的开发流程不光有团队的协作流程，还有个人的开发流程。一个IC(单个成员Individual Contributor)在团队中需要学会与人交流，不断实验，理解问题，并提出各种解决方案，做好相应的分工协作，与他人共同完成一个软件系统。
第二次作业虽然偏向于个人，主要是对个人开发能力的一个锻炼，然而大家在群中却形成一个暂时团队，许多问题都放到了群里面一起讨论，大家相互之间的交流帮助我们快速理解题目，并且寻找到相应的突破口。
像这位同学，发了一个关于FreeRTOS的操作指南，通过里面的介绍我才可以知道如何使用任务函数，如果缺乏群里的交流，许多问题都不能马上得到解决，起码我是不可能在规定时间完成任务的。
所以，好的工程师需要具备好的团队协作能力，这也是一个衡量标准。一个工程师的职业等级的成长过程，就是对团队能力的把握过程。
除了团队能力，还需要个人能力，类比到搬砖，普通程序员的个人技术和能力可以用以下数据来衡量
a.工作量
b.花费时间
c.质量如何
d.是否按时交付
工作量和花费时间是可以直接反映个人能力的，而代码的缺陷数量，返工次数也能反映一个工程师的编程效率。同时好的工程师需要对自己的能力有一个好的把握，正如兵家所云：知己知彼，百战不殆，不仅需要了解项目的难易程度，还要对自身能力的一个评估。稳定型的工程师，往往更加受到青睐。
自我评估方面，作者举玩魔方的例子，会记公式所以能将一个乱序的魔方拼好，但这不代表你精通魔方，因为你无法知道什么样的方法是最高效的，也无法对方法进行进一步的改进，更谈不上设计魔方。如果给你一个魔方，你用最快的方法将之前的乱序的魔方拼成完好的，然后你能反过来再将这个魔方还原成之前的样子吗？从原理上，正向和反向的难易程度是一样的，然而许多人不能反向还原。所以正如书中所说，技能的反面是解决问题。
工欲善其事必先利其器，我们学习某个算法，或者软件，大都先是直接调用，这是入门软件的最快方法。但是想要用好，就必须要理解其中的内部意义，从而进行改进，选择最恰当的参数。正如我以前写图像识别的程序时，虽然使用Cany算子可以很好的对边缘进行提取，但是为了适应不同的环境，我们需要理解其中的机理，对图像进行预处理或者对算子进行相应的优化。
书中所言，在当今信息时代，照抄别人的设计是很容易的，可以帮助我们在短时间内获得利益，但是这也导致我们缺乏市场核心竞争力，如果不进行深入改革，迟早也是会被淘汰的。正如中国改革开放之初，许多企业一昧的引进外国产品并加以仿造，忽略对产品核心技术的理解。如果没有涉足产品的底层开发过程，也就不能明白产品技术难点在哪，也就不能够继续有所突破。短期利益确实可以提高，但不利于长足发展。
结合招聘信息对AGV小车控制软件工程师知识能力分析
—— 以湖南艾博特机器人系统有限公司为例
以下是公司招聘信息
其中的软件项目是对路径规划和传感器数据采集的设计，作为两大模块，这两者之间需要不断地相互调用，但又比较独立，其中涉及的算法和技术很多，实现的方式也有很多，如何做出最为完美的AGV小车，需要工程师充分发挥个人能力和团队协作能力。而对于刚进入公司的学生，正如书中所言，需要以下几点：
-
首先是得积累软件开发的相关知识，提升技术技能。
-
积累问题领域的经验和知识。
-
对通用的软件设计思想和软件工程思想的理解
-
提升职业技能（自我管理的能力，表达和交流的能力，与人合作的能力，按质按量完成任务的执行力）
结合具体情况也就是：我们在大学学的东西大都比较广，且没有深入，再加上遗忘性，我们的知识储备和经验明显不足，比较专和精的知识也不是很了解。所以，首先我们得了解公司软件的开发环境，逐渐深入学习AGV小车的算法以及数据结构，积累软件开发的相关知识，由浅及深，在小项目中不断积累经验，这个过程是很痛苦的，需要自我约束能力，不能懈怠。同时在企业中，个人编程能力是有限的，需要我们的团队协作能力，在学校中大都是独自为战，缺乏团队经验，在企业中我们需要积极与人交流，积极向大神请教，保持谦逊，不断培养自己团队能力，尽快融入软件开发环境中。
基于模型的设计流程的优缺点
传统的waterfall（瀑布模型）工程开发进程是十分缓慢的，每一个步骤联系得较紧，期间任何改动都需要很长时间修改，这显然是不适合作为一个大型产品的研发流程。书中也提到了瀑布模型的各种变形如生鱼片式，虽然解决了不同子系统间进度不一的问题，但是最后系统进行统一的测试难度很大，而且耗时较长，所以也不适合大型软件开发过程。参考《Managing Model-Based Design》和上课内容，如果将开发过程独立，不再针对某个实际的产品，而是基于Simulink model。即基于模型的设计流程，前期的测试和数据采集都是在虚拟模型中实现，其速度肯定比人工采集来得快，如此，产品周期大大缩短,并且有着有极高的可靠性和质量要求
但也存在相应的缺点，自然因素是复杂且不可控的，而且需求有时候也是磨棱两可的，这就决定了模型的不易建构性，同时也要求相应人员经验必须足够丰富，能够对模型的好坏做出正确判断。所以一般基于模型的设计方案针对大型和长期的项目比较有效，但是对于较小的，一次性的方案显然不适用。而学生大都采用写了再改的模式。
结合实际案例对基于模型设计方案的改进
—— 以卫华起重机械有限公司为例
曾经在卫华起重机实习过一段时间，虽然不是一个软件工程，但起重机的校核过程也有一个基于模型的设计过程。起重机由于它的规模是单件小批量，所以产品的校核和检测必须在产品生产出来之前进行，设计人员必须建立相应的模型，传统的校核过程是手工计算，如今大都采用ANSYS分析，需要绘出起重机三维模型，再设置材料，质量，大小等这些参数，并且加入诸多约束，之后进行校核计算。虽然计算机模型的介入使得校核计算变得简便，但是模型的建立过程确实很麻烦，参数的配备也很繁琐。
在一个月的实习中，我也发现其实起重机的结构是大同小异的（汽车也类似），变化的只是相应的参数，如果公司开发一个自动建立模型的工具，可大大提高设计效率，或者模型采用图形驱动，直观地改变某些参数，也可以缩短校核周期。当然这种想法只适合于生产单一化产品的公司。
其他收获
结对编程
以前编写程序或者写文档的时候，尝试过两个人一起写，写完之后发现质量比较高，基本不用复查，书中也提到这种方法，对此深有感悟，许多时候，对于一些参数或者函数的选择，往往是难以决断的，独自为战时，心里总是没有底，而当有个人陪同编程时，不仅可以增加编程的把握，提高自信心，而且一起完成的感觉不比单枪匹马完成的感觉差，我也比较喜欢这样的模式。
单元测试
书中举例大学四年级学生和工作三年的软件工程师在项目的PSP对比，令我惊奇的是，工程师虽然在具体编码上花的时间少，但在“需求分析”和“测试”这两方面花的 时间明显要多。我们学生接触的项目一般比较小，代码行也很少有超过一千行的，对于每个细节也都了然于胸，修改起来也很方便。所以对于我而言，单元测试的概念是比较新鲜的，而且编写单元测试占用了软件系统编写过程中的大部分时间也是令人惊讶不已。往往我们都是编写完毕后，再统一测试，现在发现确实不适合大工程，而且我们的能力还相当的不够。
匈牙利命名法
大一在上C++时，老师强调了命名的规范性，建议我们使用匈牙利命名法，书中也强调，在团队工作中，为了增加代码的可读性，需要每个人约束规范命名方式。但是后来学习其他语言时，这种命名方式反而成为了摈弃的对象，许多编程大牛也都不建议使用。书中也谈到我们在C++中学的运算符重载，继承类等等，都是编程过程中尽量避免的，所以，总的来说，不一样的环境，就有不一样的规范。没有最好的方案，只有最合适的方案，软件编程也切勿一成不变。
总之，此次对《构建之法》的学习，让我认识到高级软件开发工程师与刚毕业的大学生之间的差距，也意识到软件工程的复杂性以及其中的团队协作。学无止境，距离成为一个合格的软件工程师的路途还很遥远。
