构建之法阅读笔记01

Posted 2020-10-16 ╄冷丶夜♂

　　作为软件工程专业的一名学生，一开始我对软件工程并不了解，仅仅是听到过与这个专业相关、零碎的词汇“精通一门语言”、“需求分析”、“编代码、写文档”……，《构建之法》更清楚地认识软件工程。

　　过去，对于“软件”的含义，我只理解为为人们提供方便的电子工具，而书中对“软件”下了明确定义：软件=程序+软件工程，软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。软件工程的目标是创造“足够好”的软件，而衡量好软件的标准，在过去我单单认为Bug的多少，其实Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性，这些才是衡量软件质量的重要标准。而Bug，过去我认为是软件的缺陷，其实准确的专业的来说，软件的行为和用户的期望值不一样，就叫Bug。总之，《构建执法》刷新了我对软件工程的一些认识，使我离这个专业更近一步。

　　书上说“你的RP是由你的程序质量决定的”，因为大部分软件是由多人合作完成，例如谁的模块被其它的谁调用，虽然我暂时没有合作经历，也应注意，为保证团队协作顺利进行，一定要写足够健壮的代码，这时，单元测试就起到了很大作用。也许有人觉得测试工作太过简单，无挑战性，其实事实并不如此，好的单元测试应该准确、快速地保证程序基本模块的正确性。验证单元测试好坏的一系列标准如下：

• 单元测试应该在最基本的功能/参数上验证程序的正确性
• 单元测试必须由最熟悉代码的人（程序的作者）来写
• 单元测试过后，机器状态保持不变
• 单元测试要快（一个单元测试的运行时几秒钟，而不是几分钟）
• 单元测试应该产生可重复、一致的结果
• 独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性
• 单元测试应该覆盖所有代码路径
• 单元测试应该集成到自动测试的框架中
• 单元测试必须和产品代码一起保存和维护

　　课上老师写了一个求数组最大值的函数让同学们写测试样例，有的同学为测试程序，随机写了一些数组（如{1,2,3,4,5}、{-5,-4,-3,-2,-1}、等，而根据单元测试的要求，显然该测试没有覆盖所有情况，一组较好的测试用例如下，{-999,0,2,9999,88}（普通数组）、{1,1,1}（数组内所有元素相同）、{}（数组长度为0）、null（数组对象为null），可见并非所有人能够立马想到所有可能的情况，当程序较为复杂时，单元测试这项任务会费不少脑力。对于异常处理，因为数组元素未限定范围，当数组为空时返回零、返回-1显然不合理，因为可能素组中最大值就是0或1，对此，我想到到用异常处理机制解决该问题（当数组为空时抛出异常）。老师给出的解决方案为：数组为空时返回int型极大值，考虑到极大值应该是极少用到，所以该方案也可以接受。

　　当测试完全通过，也应注意程序运行的效率，但是不能盲目优化。

　　

　　对于代码规范，见过有同学只以自己的个性写代码，紧凑而有规律，变量名也很有趣味，问题就是让人看不下去，这在问问题时让人极为苦恼，虽然当时只是简单的C++程序，但是，，唉我真看不懂。。。我一直按照基本的规范进行（每句换行，常量全大写，变量、函数用Camel、类名用Pascal）、注释暂时只在四则运算程序里写过。而这给团队协作带来了极大困难。