构建之法阅读笔记01

Posted ╄冷丶夜♂

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了构建之法阅读笔记01相关的知识,希望对你有一定的参考价值。

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

  过去,对于“软件”的含义,我只理解为为人们提供方便的电子工具,而书中对“软件”下了明确定义:软件=程序+软件工程,软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。软件工程的目标是创造“足够好”的软件,而衡量好软件的标准,在过去我单单认为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)、注释暂时只在四则运算程序里写过。而这给团队协作带来了极大困难。

以上是关于构建之法阅读笔记01的主要内容,如果未能解决你的问题,请参考以下文章

构建之法阅读笔记01

构建之法阅读笔记01

构建之法阅读笔记01

《构建之法》阅读笔记01

构建之法阅读笔记01

构建之法阅读笔记01