软件工程实践总结——在痛苦中飞速成长

[222000131魏诗卉]

这个作业属于哪个课程	2023软件工程实践W班
这个作业要求在哪里	软件工程实践总结&个人技术博客
这个作业的目标	课程回顾与总结 个人技术总结
其他参考文献	《构建之法》

目录

• 一、课程回顾与总结
• 1、寒假作业博客链接
• 2、对问题的再次思考与总结
• 3、产生的新问题
• 4、收获最大的知识和能力
• 5、结合个人经历谈谈理解与心得
• 个人项目
• 结对编程
• 团队项目
• 6、自我评分
• 目标一
• 目标二
• 目标三
• 目标四
• 目标五
• 目标六
• 目标七：
• 二、个人技术总结
• 1、链接
• 2、概述

一、课程回顾与总结

1、寒假作业博客链接

寒假博客链接戳这里~

2、对问题的再次思考与总结

问题一：如何能证明一个软件是可以继续发展的？戳这里

对于这个问题的解答，我仍然坚持之前寒假时的观点，这个软件在产品设计之初的大方向上必须是正确的，只有这样，在面对之后的发展中，才能够根据用户的需求做出适当的修改维护。但同时我对此也有了新的认识，即这个产品之前的设计架构必须是合理正确的，而不能是草草了事，能够达成功能即可。如在Alpha冲刺阶段，我们对于很多功能的实现是堆积起来的，并没有一个合理的架构，也没能达到软件设计“高内聚、低耦合”的目标，这导致我们在Beta阶段需要对功能进行升级时十分困难。因此，一个软件能否继续发展，与这两个点都息息相关。

问题二：作者用商用民航发动机来对比普通的商用软件，是否合适？戳这里

曾经的我对于这个问题的看法是不合适，因为当初看到这个问题时内心是十分嗤之以鼻的，认为一个商用软件怎么能够和民航发动机进行对比。直到后来在社区中再次看到这个问题时，有一条回答让我一下理解过来，并非提到商用软件就是“无所谓的”，相反，随着科技越发深入我们的生活，软件已经在我们的生活中占据了至关重要的地位，此时，若类比VX发生致命性错误，难道不是几十万甚至更多的人的生活遭受影响吗？并且，我赞成一条回答：商用民航发动机应该对标的是重要的商用软件，而非普通的商用软件。

问题三：如何区分一个好的程序员和不好的程序员呢？戳这里

对于这个问题在经历了多次的团队合作之后深有感触。在曾经，我只是简单的认为能够把基本的功能不断地做的更完整就已经是一个好的程序员了。可是在这次漫长的团队合作中，我见识了各式各样的“程序员”，有的具有团队协调能力，能够根据队员的能力和时间合理分配任务；有的具有挑战精神，能够提出各式各样的新点子并将之付诸实践，带领团队更进一个台阶；有的虽然沉默却能够很好的完成自身的任务；有的情绪稳定抗压能力强，能够在队友面临崩溃时“抗下”一些，这些在我看来都是十分美好的品质，都能够称之为是一个好的程序员。而有的队员每次分配任务时就推脱不做；有的队员完成一个任务时总是拖拖拉拉，导致他人的进度也被耽误，还有的做事时张口say no，拿分时格外积极，这些都是我不愿意在合作第二次的程序员。因此，在我看来，一个好的程序员不仅需要看其能力的高低，更重要的是他是否具有一个程序员应该具备的品质和素养，能否吸引与他合作过的程序员想要再次与他合作。

问题四：花费时间越多，代表工作量越高吗？戳这里

大No特No，花费的时间越多，有时往往不代表工作量越高，相反，经常意味着那个程序员的水平不够，查找问题和解决问题的能力不足。因此我觉得对于这样一个问题并不能够片面的根据时间来判断，我们还应该结合这个程序员的水平能力、以及时间花费的地方而决定，如果大量的时间花费在了修改bug上，是不是也意味着，这个程序员的大量时间都是浪费的呢？并且对于工作量的评价不应该只有花费时间这一个因素，代码行数、bug比例都是很重要的因素，且代码内容也十分关键。这次的冲刺我们曾经花费一个晚上的时间查找一个bug，最后发现只是因为名字没有对应而导致映射失败，显而易见，这个晚上的工作量是极低的。

问题五：什么人群适合看《构建之法》这本书？戳这里

对于这个问题我的观点并没有改变，我认为《构建之法》最适合有一定代码量积累和经验的人阅读，尤其是在做项目过程中，时常感到困惑的一线工程师，或者是面对一个庞大的软件项目开发任务而感觉力不从心，无力掌控的负责人。因此当我们已经到了大三的时候，是非常适合读这本书的。同时，将阅读与实践结合是十分必要的，做中学，学中做不应该只是一句空话。这次的软工实践，真正的做到了学中做，做中学，受益匪浅。

3、产生的新问题

• 问题一：如果一个软件产品最初的建模步骤已经失败或者十分不尽如人意，当进展到产品构建阶段时，开发人员应该如何补救？
• 问题二；如果你在队内处于领导者的地位，当面临一些组员“不愿工作”、“互相推卸”、“只会抢占功劳”时你该如何做？
• 问题三：当开发中压力过大，一些组员的积极性反而降低时，应该如何提高组员的积极性？
• 问题四：目前chatgpt大火，很多人都预测将有一部分水平低的程序员将会被取代，是否如此？如果是真的，我们该做些什么来提高自己？以及如何正确的使用这些人工智能呢？

4、收获最大的知识和能力

• 需求分析阶段

  在这个阶段我们学会了NABCD模型，通过对于需求、做法、好处、竞争、推广这五个方面的评估，来判断一个产品是否具有市场竞争力，是否值得投入资金与时间，它教会我们理性的从这五个角度进行多维度评估，而非盲目的编程。而这次的团队项目，我们正是从当下最热门的抖音小游戏出发，从而选定了做这样一个小程序。

• 设计阶段

  这个阶段主要是对产品进行建模、对数据库进行分析设计。结合《软件工程》这门课程，我们对我们的产品进行类图、用例图的分析，以及数据库的分析与设计，但其实团队最初的设计是不充分的、甚至存在一些错误的，因此，我们这次团队合作对于设计阶段最大收获可能不是在数据库设计那次作业中，而是真正到了Alpha冲刺才发现这么一个问题，通过在Alpha冲刺阶段对于设计的重新构思，我们才真正获得了进步，该如何通过一个产品，或者说是通过需求去获得UML图。

• 实现阶段

  此次冲刺我主要负责后端云函数的编写以及前后端接口的连接，在这个阶段，我最大的收获是认识到API文档的重要性。初次对于认为无分配时其实我只负责后端云函数的编写的，并没有负责前后端的连接，是到了项目开发中期大家才发现这个问题，连接的同学对于前后端的接口无论是名字、功能还是输入输出参数都一无所知，因此他们无从下手。因此我们后面紧急调整为花两个小时编写前后端API文档，并且分配一个后端的成员去进行前后端接口连接的工作，这个问题才得以解决。因此，我认为在团队开发中，API文档是至关重要的。

• 测试阶段

  此次的项目测试我们运用了课上学会的内容，对我们的产品分别进行了黑盒测试和接口测试。我们首先对每一个接口都进行了单独的单元测试，确保每一个接口都是正常可运行的，接着，我们根据产品的功能流程图对于每一个功能都进行了测试，接着我们将功能连接，确保产品能正确运行。在最后，我们在手机上进行黑盒测试。唯一遗憾的是，因为微信小程序的限制原因，体验版小程序并不能邀请非名单内成员进行程序的测试，只能通过录屏的形式让其他成员感受，但这对于我们的测试就造成了影响，一个对于该产品不熟悉的成员能够成功的运行这个程序呢？我们其实并不清楚。

• 发布阶段

  由于我们开发的是微信的小程序，由于小程序上线审核时间长，且好像有限制说定位功能需要公司申请，个人无法申请，因此此次很遗憾我们未能发布成功，只能发布体验版本。

5、结合个人经历谈谈理解与心得

个人项目

• 之前审题其实都是草草了事，哦是这么个功能啊就开始编写程序，而这次在个人项目中就遭到了重创，编写到后期快要提交项目时才发现啊有这么多的要求，比如输出结果的格式、使用命令行输入等等，当时内心是非常崩溃的，最后几天常常肝到半夜一点才赶上截止时间，从那次之后，我再也不敢随便读题了，而是仔细地阅读到底有哪些要求，而我又该如何入手。

结对编程

• 这次的实践我们尝试了一个新的vue框架，因为时间限制，当时的我们只能最终放弃前后端结合的方式而改用纯前端的方式编写。说实话时间很着急，根本没有给我们太多的时间花在学习上，我们只能采用边学边做的方式进行，但其实效果挺惊艳的，在这样的情况下，我们掌握新知识的能力大大提升。也正是这次的项目让我真正理解了“学中做，做中学”这句话。

团队项目

• 团队项目中我首先认识到的是一个好的队长以及队员是十分重要的，而一个差的队员对于项目的影响其实也是很大的。其次，在这次的实践中遇到不会的问题时我们不再是像从前一样盲目的查询百度百科，而是发现了两个非常实用的方法，分别是询问chatgpt以及查询官方的开发文档。chatgpt首先告诉你一个思路，你应该查询哪方面的内容，使用哪种方法，而官方文档能让你很清楚的明白这个接口应该怎样使用，自己又是哪里出现了问题，对症下药，非常有效！

6、自我评分

目标一

• 目标：理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念。
  • 评分：90
  • 解释：通过课上老师的讲解以及一道关于软件工程师的职业道德规范和实践要求的习题，我认识到一个程序员的职业道德规范和实践要求无论是对于个人还是企业都是至关重要的。

目标二

• 目标：掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。
  • 评分：90
  • 解释：在两次的作业中我们熟练掌握了制作原型的工具，立志于通过客户的口头描述准确的绘制出原型图，构建需求分析模型。

目标三

• 目标：掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。
  • 评分：80
  • 解释：能够通过客户的需求绘制对应的类图、用例图以及数据库表等，成从体系结构设计模型、数据设计模型和构件级设计模型，但构建出的模型还是会存在缺陷，不能够完全满足后续开发的需求。

目标四

• 目标：能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。
  • 评分：85
  • 解释：能够通过多次的测试，在原有基础上进行创新改进，设计出更加简介、算法更加省事的软件。

目标五

• 目标：遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。
  • 评分：90
  • 解释：在多次的团队作业中都参与了需求规格说明书、系统设计说明书、系统测试报告等文档的撰写，对于文档的规范撰写能力有了很大的提高。

目标六

• 目标： 具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。
  • 评分：83
  • 解释：冲刺的每一天团员们都是聚集在一起谈论和编写，无论是沟通能力还是合作能力都有了较大的提升，但是组织能力和指挥能力并没有特别大的进展，希望在后续的工作中能够锻炼到这方面的能力。

目标七：

• 目标：能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。
  • 评分：90
  • 解释：能够先对项目功能进行划分，并分配到每天的每个成员身上，且掌握了teambition等团队协作开发的工具。

二、个人技术总结

1、链接

微信小程序云函数的开发

2、概述

• 本次个人技术总结主要讲解了微信小程序开发的云函数编写调用。

[SoftwareTeacher]

感谢你的详细的 ‘回答’ + ‘再次回答’。 希望你可以把你的回答加到 https://bbs.csdn.net/forums/SoftwareEngineering?typeId=828 原始的提问中，帮助后来者。

[CSDN-Ada助手]

@SoftwareTeacher 作为一个领导，你可以采取以下措施来提高组员的积极性： 1. 给予肯定和激励：及时表扬组员的好工作，提高他们的自信心和工作动力，同时给予奖励和激励，如加薪、晋升、奖金等。 2. 设定明确的目标和任务：明确团队的目标和任务，并将其分解为小的阶段性任务，让每个组员能够清晰地知道自己的工作内容和目标。 3. 提供培训和技术支持：为组员提供培训和技术支持，帮助他们不断提升技能和知识水平，让他们有更强的能力来完成工作任务。 4. 创造良好的工作氛围：营造一个积极向上、团结协作、互相支持的工作氛围，让组员感受到团队的凝聚力和向心力。 5. 给予适当的自主权：给予组员一定的自主权，让他们有更多的自由度来完成工作任务，同时也能够更好地发挥自己的创造力和想象力。 6. 与组员建立良好的沟通渠道：与组员建立良好的沟通渠道，及时了解他们的工作进展和问题，给予必要的支持和帮助。

[SoftwareTeacher]

@CSDN-Ada助手当你是一个软件开发团队的领导， 当开发软件过程中压力过大，一些组员的积极性反而降低时，应该如何提高组员的积极性？

[郭渊伟]

顺应时代潮流，学会利用新工具来促进知识的学习掌握，很多开发中的经验不是AI能够轻易取代的