眨眼又是一周,这周完成了以下工作:
- 与国外同事合作,完成了CPA分析
- 完成自动化测试系统框架的开发
- 进行了为期两天的公司价值观培训
- 练习英语听力200分钟
- 阅读了《构建之法》的前四章
这周做了很多事情,但让我收获最多的是阅读《构建之法》。在介绍学习《构建之法》的心得前,先简短总结一下其他的事情。
完成CPA分析
CPA(Critical Path Analysis)分析即软件关键路径分析。
简要来说,在汽车ECU软件的开发阶段,工程师通过CPA分析找出软件设计过程中的缺陷,并及时更正,从而保证车辆运行过程中软件的可靠性,保证乘客安全。
本周与国外同事合作完成了软件的CPA分析,并提出了若干修改意见,例如:变量汉明距离、重要信号备份、CRC校验等等。
这些问题已经在本周六修改完毕。并发布了一个小版本。
自动化测试系统框架开发
自动化测试是Team Leader安排给我的额外项目,目的是完成回归测试的自动化,节省人力。
为什么会安排给我?因为整个Team只有我一个人会Python。白天上班用C语言,下班回家用Python,这种酸爽也是妥妥滴。
经历了两周苦逼的摸索,利用python基本完成了自动化测试系统框架的开发。
其流程为:利用python调用编译器自动编译代码,然后打开CANoe下载代码到ECU,接着操纵CANoe进行自动化测试。
阅读《构建之法》
《构建之法》的阅读心得是本篇文章的重点。我之所以阅读这本书也是各种机缘巧合促成的。
之前,我在极客时间买了课程《软件工程之美》,讲师推荐阅读这本书。而在开发过程中过程中,我也遇到了很大的问题,反思后明白是由于基础知识的缺乏。之后,我在淘宝买了该书进行学习。
在阅读的过程中,书中提出的很多理论给我留下了深刻印象。例如:程序 = 数据结构+算法,软件 = 程序+软件工程,软件企业 = 软件+商业模式。
对于程序员来说,程序(算法、数据结构)是基本功。如果想要开发高质量的软件,则必须将软件开发作为工程问题解决,而软件工程决定了软件质量。
软件工程包括:软件需求分析、软件设计、软件构建、软件测试和软件维护。同时,软件工程也包括多种开发模型,例如:瀑布模型、极限编程、结对编程。
以汽车电子行业为例,汽车ECU软件的开发通常按照“V”模式开发流程,其本质就是瀑布模型。
首先,根据主机厂需求,系统工程师写出系统需求。接着,软件工程师通过分析系统需求形成软件需求。之后,程序员进行软件设计,编码。最后,进行单元测试、回归测试、集成测试、系统测试和实车测试。
其中,软件开发工程师负责分析系统需求,并形成软件需求。之后,进行软件设计、编码、单元测试和回归测试。但由于我所在的公司在产品概念开发阶段没做好,导致现在很多项目直接carry over别的项目,造成现有项目没有单元测试。
根据《构建之法》的定义,单元测试是用于测试代码的基本功能/参数的正确性。同时,单元测试应该覆盖所有的代码路径,包括错误处理路径。
由于没有单元测试,使得目前开发项目的大部分时间用于解Bug。而我作为一个转行程序员更是两眼一抹黑,完全不知道如何针对ECU代码写单元测试。针对这点,我需要在以后的工作过程中多多留心,并向跳槽来的员工请教,总有会写单元测试的同事。
至于回归测试,公司有专门的测试文档,我也做了很多次,基本能够明白回归测试的用意。回归测试即是每次发布新版代码之前所做的测试,旨在测试该版本的代码与上个版本相比是否发生了功能回退。
除了上述对软件工程基本知识的介绍,《构建之法》着重讲了“人”在软件开发中的作用。
第二章讲了个人技术与流程,作者引用了CMU的专家们针对软件工程师开发的评价模型(PSP, Personal Software Process),表格如图:
各位读者可以根据这张表格参考自己处于什么层级,我本人应该是处于PSP0的层级,真的是很惭愧,看来转行之路还是任重而道远啊。
除此之外,《构建之法》在第三章讲了软件工程师的成长。在这个章节,作者讲了程序员自身的发展路径和自我评估,以及团队对于程序员的能力的要求。
第四章讲了两人合作编程,说明了在软件开发过程中“1+1>2”的道理。由于我在汽车电子行业,工作中并没有接触过结对编程。因此,对结对编程这种工作形式并不很了解。
但根据书中的讲述,能够看出结对编程能够在一定程度上保证代码开发过程中单个程序员出现的纰漏,例如:代码规范、代码设计、代码审核。而在汽车电子行业,工程师也会在编码结束后开会进行Review,从而在一定程度上保证代码的正确性。
由于这周读了四章,仅仅属于皮毛。而《构建之法》的其余章节才是精华,等下周读完这本书再做一次总结。
ps. 欢迎关注我的公众号[酷酷的coder],分享转行菜鸟程序员成长过程汇总的烦恼和反思。