粗读《构建之法》后的思考和收获

偏执的太偏执、 2021-11-23 05:20 206阅读 0赞

在整体的通读过程中，我是抱着学习的态度一直在学习，因为本校刚刚申请了软件工程这个专业的本科，而我之前是计算机科学与技术专业毕业，所以，对于我来说，我也一直在从头学习软件工程这门课和一些相应的软工专业课程。所以，很多时候，我是在吸收，并没有太多的问题。

问题一：第3章软件工程师的成长中讲到了初级软件工程师如何成长的问题。当然，积累软件开发的必备技能、积累问题领域的知识和经验、对通用软件设计思想和软件工程思想的理解、提升职业技能和实际成果，这五个方面都是其个人的努力和学习。我想说的是，一个成熟的软件开发团队，一些优秀的软件工程师，如何带动和帮助初级水平的软件开发人员尽快提升，尽快成为一名优秀的软件工程师呢？自身当然是主要内因，但环境和周边的帮助也是相当重要的，能让他少走很多弯路。

问题二：第6章关于敏捷开发是不是大神的问题，我查看了很多资料。看到了很多观点，其中这个观点吸引了我：敏捷开发不是万灵丹，先找到问题点、知道为什么要采取敏捷，重点是卡在哪里需要敏捷这个「方法」来解决。设计师改来改去是为什么解决什么问题？敏捷 开发的小幅度改来改去、和现况设计师的改来改去有什么不同？如果都一样为什么要采取敏捷？我想弄清楚这些问题，就可以更好的理解敏捷开发和运用敏捷开发了。

我觉得敏捷开发适用「头脑清楚」的人，只是这种人往往是大神级的了。和大神 PM、大神 Planner、大神 RD 合作，都清楚知道自己在干嘛、别人在干嘛，还能 Cover 一点别人的领域，知道解决这个问题可以往目标更进一步，这种合作模式才有办法做到「敏捷」，而不是因为抓漏抓虫在修改。是啦这也算朝目标迈进，但「创新改良产品」和「让产品看起来洞没那么大」的改来改去本质上是两回事啊！敏捷开发只是个方法，不是万灵丹。

问题三：第8章需求分析中，我明白了需求分析原来也是有门道的。本来以为需求分析是整个软件工程中最简单的一个环节，现在看来，这其实是最重要的环节之一。如何准确的掌握广大客户的需求，如何更好的把握软件开发的各个点，这些都需要从需求分析入手。同时，我还学习到了准备的需求可以用什么方法获得。受益匪浅。

问题四：第十章典型用户和场景中关于用例的理解，我还是不是特别清晰。上网大致查了一下：Use Case(用例)是一个UML中非常重要的概念，在使用UML的整个软件开发过程中，Use Case处于一个中心地位。用例是对一组动作序列的抽象描述，系统执行这些动作序列，产生相应的结果。这些结果要么反馈给参与者，要么作为其他用例的参数。用例被认为是第二代面向对象技术的标志。关于的用例的故事性描述和粒度，还是有很多模糊的概念，不太理解。

问题五：关于书上第十一章软件设计与实现中的移山公司开发流程图，让我有了一个整体的框架概念，非常直观。在第十三章软件测试部分，我大概明白了一个软件的主要测试环节和步骤。同时也上网查了很多测试的步骤和方法。比如一个网站如何测试。

首先，查找需求说明、网站设计等相关文档，分析测试需求。制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试。开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。定期评审，对测试进行评估和总结，调整测试的内容。

通过大致粗略的通读《构建之法》，我对软件工程有了全新的认识，期待接下来的学习。

转载于:https://www.cnblogs.com/zhanggreenwind/p/11181238.html