读《构建之法》的心得体会
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了读《构建之法》的心得体会相关的知识,希望对你有一定的参考价值。
读《构建之法》的心得体会
在课文的第一章绪论中说到软件工程包括下列领域:软件需求分析、软件设计、软件构建、软件测试和软件开发维护。软件开发活动(构建管理、源代码管理、软件设计、软件测试、项目管理)是软件工程的核心内容。
在看待软件bug中,我们要以客户的需求上去分析此问题是否是全局的缺陷,客户想要我们完成的功能我们却没有完成,当然,客户没让我们完成的功能我们也实现了,这同样是一个bug,当我们研发软件的时候,要通过实际的工作收集、提炼需求。需求来自于实际,而不是自己想象出来的,在软件开发的初级阶段。我们要对用户需求的分析有详细的文档说明,包括对将来发展的分析和计划,主要功能的设计文档和软件的实际行为一致,每次的修改记录都能看到,关键模块有可以正常执行的单元测试等。
学习单元测试后了解单元测试的功能可以让自己负责的模块功能定义尽量明确,模块内部的改变不会影响其他模块,而且模块的质量能够得到稳定的保证。在写代码的一开始就应该要写单元测试,不能在代码差不多完成的时候才写单元测试,不然不仅耗时间还耗精力。单元测试必须要由最熟悉代码的人来写,想想将来我如果要做一方面的工作,那么我必须就得要很细心,因为我需要考虑多方面,写单元测试的时候,最后覆盖率达到百分之百,但不代表覆盖率达到百分之百就代表百分之百的正确性。
软件开发流程不光指团队的流程,还包括个人开发流程,因为软件团队是由个人组成的。因此每个人的能力是很重要的,因此我们在学校首先要把理论知识给学好,因为没有理论的前提下是不能很好的实践的,特别是我们写代码这一块,我们也要锻炼自己快速学习的能力,将来出去工作的时候也能更好的学习新的知识。当我们写代码的时候,要做到代码规范,比如命名的名字需要具有一定的意义,命名的大小写需要注意,写代码的时候适当加上注释,这样我们再回过头来看代码就能很清晰明了了。写完代码之后需要缩进以及排版等,一开始写代码变养成了一种好习惯的话,对我们未来的职业道路上是有很大的帮助的。代码复审阶段最好不要自己去复审,让团队的人去复审会有比较严格的规定和流程,才能达到我们所期望的效果。
在两人合作的过程中,必然会经历两个人的磨合阶段,看了这一章节懂得了两个人一起合作如何正确地给予反馈,两个人要适当地站在对方的角度上考虑下问题,这样问题会容易解决多了。
以前的我不太懂项目经理以及产品经理是怎样的一个职位,产品经理对一个或多个产品或产品线负责。随着产品的发展,不同公司,对产品经理的要求会不一样,核心要求是,根据市场和用户需求,正确的把我产品定位和方向,解决用户的痛点,持续优化产品。
在团队的开发中,每一个成员都要了解用户的需求,如果在处理的过程中有出现误解或者偏差,就会导致开发过程中出现很多问题,这样会浪费我们时间,得不偿失。
虽然我们现在推崇创新精神,可以把用户界面做得惟妙惟肖,但是用户体验还是很重要的,怎么样让客户第一次使用你所开发的软件就感觉良好是一件很重要的事情,让用户怎样快速掌握你所实现的功能也是很重要的,因为用户和软件的第一次使用,很大程度上决定了用户对软件的评价,更要多从用户的角度上考虑问题。
在做测试的时候,我们不能画地为牢,严格只使用一种测试设计方法,要根据实际情况,要对系统更好以及更多的了解,写测试用例的时候尽可能考虑多种情况,这样才能达到测试的效果。
问题1:老师总是说要设置断点,但是我现在还是不太懂断点的基本用法。
问题2:什么是析构函数,写法是跟普通函数一样吗?
问题3:什么时候适合选择敏捷,敏捷的方法论到底是什么?
问题4:现在团队成员之间交流成本急剧成长,该如何解决交流成本问题?
问题5:作为一个PM,他应该以一个怎么样的心态去面对风险呢?
问题6:如果一个项目在规定的时间内没有完成是由于存在的bug太多,这时应该怎么办?
问题7:看不大懂思维导图。
问题8:如果我以后要做软件测试这块,从现在起我最主要的是掌握那些方面的内容。
以上是关于读《构建之法》的心得体会的主要内容,如果未能解决你的问题,请参考以下文章