软工实践总结_阳光总在风雨后

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

一 、问题回顾

问题思考博客链接

1.1 再次解答

• 程序员是否有必要为满足小部分人的需求去做软件,或者为软件添加某些功能？

寒假时的认知是片面的，是否需要为小部分人添加某些功能需要考虑很多因素。

1. 用户需求和价值：评估用户需求的重要性和广泛性。如果满足这些需求只会给少数人带来价值，并且对于大多数用户来说并不重要，那么可能不值得投入时间和资源。
2. 商业价值：评估项目的商业潜力和可持续性。如果为满足小部分人的需求而开发软件无法带来商业回报或持续发展，那么可能需要重新评估是否值得进行。
3. 可行性和资源限制：评估项目的可行性和资源限制。确定是否有足够的资源（时间、人力、技术等）来满足这些需求，并评估开发这些功能的复杂性和成本。
4. 用户反馈和市场反应：考虑用户反馈和市场反应的重要性。如果小部分用户的需求代表了更广泛的市场趋势或需求，那么满足他们的需求可能会增加产品的竞争力和用户满意度。
5. 软件可定制性：考虑软件的可定制性和扩展性。如果软件具有良好的可定制性和可扩展性，那么可以考虑为满足特定需求的用户提供定制的解决方案，而不必为每个用户都添加相同的功能

• 花费时间越多，代表工作量越高吗？

花费时间的多少并不总是代表工作量的多少。工作量是指完成一项任务或项目所需的实际工作量和努力。尽管在某些情况下，工作量和花费时间可能是相关的，但并非总是成正比的关系。

1. 一个高效率的人可能能够在短时间内完成大量的工作，而一个低效率的人可能需要更长的时间完成相同的任务。因此，两个人在相同时间内完成的工作量可能是不同的。
2. 具备更高的技能水平和经验的人可能能够更快地完成任务，因为他们掌握了更有效的工作方法和技巧。相比之下，相对缺乏经验或技能较低的人可能需要更长时间来完成同样的任务。
3. 一项复杂的任务可能需要更多的时间来理解、规划和执行，而一个相对简单的任务可能可以更快地完成。因此，完成相同工作量的任务所需的时间可能因任务的复杂性而有所不同。

• 个人在团队中角色就像是一个流水线上的机器吗?

个人在团队中的角色不应被简单地比喻为流水线上的机器。尽管每个团队成员在项目中扮演不同的角色和承担不同的责任，但这并不意味着个人仅仅是像机器一样执行单一的任务。在团队中，每个人都是一个有思考能力、创造力和独特贡献的个体。每个人都有自己的专业知识、技能和经验，能够在团队中发挥独特的作用。团队的成功往往依赖于每个成员的合作、协作和相互支持。

• 如何让自己能够跟上软件工程发展，做一个永不落伍的开发者呢?

1. 首先持续学习提升自己，软件工程领域每天都在不断地更新和演变，我们要保持更新的知识和技能，不断地学习就是关键所在。可以通过参加培训课程，交流会，线上论坛等学习的机会，阅读相关书籍，浏览相关博客，来持续增强自己知识的储备。
2. 其次要继续提高编程技巧，不断提高自己的编程设计能力。学习和应用设计模式、重构技术、测试驱动开发等软件开发的最佳实践，以提高代码的质量、可维护性和可扩展性。
3. 然后就是容易被忽略的一点，加强沟通和团队合作能力，软件开发往往是团队合作的过程，所以加强沟通和团队合作能力非常重要。学会有效地沟通、倾听和理解他人的需求，协调和合作解决问题，与团队成员建立良好的工作关系。
4. 最后是要培养自己解决问题的能力，作为一个开发者，解决问题是日常工作的一部分。培养解决问题的能力，分析问题、寻找解决方案，可以帮助你应对各种挑战变化。

• 对于一名工程师而言，究竟应该是更”专“一点好，还是更”广“一点好呢?

这是一个值得大家深讨的一个话题，寒假的时候我认为相较于现阶段“广”更加的适合我，其实不尽然。毕竟个人没有那么多的时间完成很多的事。可以先专注研究一个方面的东西先“专”，专注一件事到精通它，然后再去涉猎其他部分的东西，总的来说就是由专到“广”。有句话叫做技多不压身，学习更多的东西，有助于我们丰富自己的技术栈，对于以后的求职应聘有更多的出路，可以饰演更多的角色，当然前提还是应该你精通于它。

1.2 新的问题

• 工作时是否应该带着个人、感情驱动的因素?

思考：

在程序开发过程中，个人和情感驱动的因素可能会对工作产生一定的影响。一般认为程序开发是一门技术和科学，应该以客观、理性和实用为导向，而不应受个人喜好或情感的干扰。

然而我的理解是个人和情感驱动因素在程序开发中是有益的，可以激发创造力、激情和投入感。个人和情感驱动因素可以激发我的创造力和热情，帮助我开发出更具创新性和质量的解决方案。毕竟遇到自己感兴趣喜欢的事物，我们会加倍的投入其中，有更多好的想法。

虽然个人和情感驱动因素有益，但是也要适度的平衡。在程序开发过程中，需要始终保持客观性、理性和专业性。程序开发不仅仅是个人的创造力和情感表达，更是为解决问题、提供价值和满足用户需求而进行的工作。

• 结对开发是否能提高开发效率？

思考：

一开始我是这么想的：结对开发是两个人的事，两个人共同去完成一件事，这其中需要两个人不断的协商，沟通交流。毕竟两个人的喜好，看法，观点有所不同，这些都是需要时间的，还不如自己一个人直接全包了来的快。

但是经过了结对项目经历，我才明白了结对开发不失为一种提高效率的手段。

1. 两个人所掌握的技术栈同，擅长的领域不同。结对可以让我们形成互补知识技能的差距。
2. 代码的问题够及时的发现，多一个人多一双眼睛。身为编写代码的人“当局者迷”，而你的队友作为一个“旁观者”，可以清楚的察觉到你的Bug，及时指出改正。
3. 项目的创造性更强了，两个人可以共同解决问题，进行“头脑风暴”，可以激发我们在编写过程中的创造性思维，通过不同的观点和看法，找到解决问题的最优解。

尽管结对开发可以提高效率，但是需要自己与队友不断的磨合，形成默契。而且结对开发并不适用于所有场景，有的时候个人开发能有更好的效果，应该视情况而论。

二、 项目实践

2.1 需求阶段收获

在需求阶段我的最大收获就是API需求文档的编写。

首先通过NACBD分析，将自己的认知由个人推广到市场需求，真正了解用户需要什么。

其次在了解了项目的需求是什么，通过团队的沟通来确定项目的预期效果，所需要实现的功能。

最后，也就是重中之重的就是通过团队的沟通编写严谨的API文档，并且之后代码的实现严格遵循文档。

2.2 设计阶段收获

在设计阶段我的最大收获就是学会使用墨刀进行原型的设计。

首先原型设计采用的是墨刀，将设计以另一种大致的方式呈现给用户。墨刀的可视化界面正好适用，易于操作，良好的展示。

其次学以致用，将之前在面向对象与程序设计课上学到的UML图（用例图、类图、对象图、状态图、顺序图）运用到项目中去，设计更加易于理解沟通

设计看似在项目中不起眼，但是真的值得我们花上大量的时间去完成，不仅仅是提供更好更清晰的展示，而且可以为后续的实现免去不必要的麻烦。

2.3 实践阶段收获

在实践阶段我的最大收获就是学会了一门新的语言Go语言。

Go语言作为一种轻量级语言，更易上手学习，语法与C相似，语法规范简洁易读。web的开发框架为与Go语言配备的Gin框架，而数据库的框架为Go相关的Grom框架。由于做的项目是基于ChatGPT的聊天项目，所以避免不了与AI斗智斗勇，在这个过程中学到了调试AI的基本参数，给予其“惩罚”，使其更加的“听话”，满足项目需求。

2.4 测试阶段收获

在测试阶段我的最大收获就是将本学期学到的单元测试，黑盒测试运用到项目中。

测试的目的包括：发现缺陷和错误，验证软件是否符合之前的需求，提高用户的满意度，降低成本提高软件安全性。

覆盖率测试是必不可少的，运用Goland覆盖率测试可以清楚的看到测试函数编写是否全面，避免遗漏。Postman对于每个小单元进行测试其正确性。

黑盒测试（等价类划分），将测试分为了正确和错误两个部分。

但是我非常的清楚仅仅靠这些还是远远不够的，测试只是包括了肉眼所能看到的部分，还有许多看不见但是潜在的问题没有被发现，这是一个任重而道远的阶段。

2.5 发布阶段收获

在发布阶段我的最大收获就是采用Github创建仓库进行版本不同版本的管理

对代码进行版本的控制，首先确定下来一个版本，那么在接下来的很长一段时间版本内容（API文档，数据库）都是固定的，这么做有利于代码的稳定性与完整性。

禁止直接向main分支提交pull requst，严格控制dev分支的提交（至少需要两位成员的审核），只能先将自己的代码上传到自己的分支再进行合并。这么做更加有利于发布阶段代码的整合，也不容易出错。

发布不仅仅只是将做好的产品推向市场，还要包含用户的体验反馈，在了解用户的体验之后，更好的明白产品的不足之处。通过用户给出的反馈，易于优化我们的产品。

三、 心得体会

• 在个人项目中我的感受就是有种孤立无援的感觉，我甚至怀疑自己能否做好这次的项目。首先明确自己的目标让自己保持专注，其次制定详细的计划和时间表，PSP表格就是一个不错的选择，它可以量化我们完成每个任务的时间，使我们做事不拖拉，更加合理的安排，最终比对实际使用的时间总结出自己的不足。在编写代码的过程中总会遇到一些困难，只有一个人，我们要保持乐观的心态通过书籍、网络查找，询问“大佬”来解决（自我催眠加油你是最胖的）。
• 在结对项目中我的感受就是真好啊，终于有人陪伴了。首先一开始还是有些社恐的，毕竟我与我的队友不相识，我们通过沟通对于各自所擅长的技术有了深入的了解，在项目开发的过程中集思广益，互相提出对方的问题并寻求最优解。在结对项目中我认为比较困难的部分就是要去学习新的技术，这个过程虽然可以说得上是“坐牢”，但是也为我接下来的团队项目打下了基础。
• 在团队项目中我的感受就是有一种真实在公司上班的情形，老大分配任务，身为小弟的我每天努力完成自己部分的任务（OvO）。团队项目真的是一次宝贵的经历前所未有，身为后端小组的成员，我的组长大人根据每个人所擅长的部分不同合理的安排每个人的任务，以确保任务的高效完成。每天晚上7点，准时进行每日冲刺的站立式会议开会，给我们提供了面对面交流的机会，小组成员之间更加具体细节的了解了项目进度以及接下来应该做些什么，并进行协商。

四、 自我评价

4.1 七大目标

• 目标1： 理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念。
• 目标2： 掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。
• 目标3： 掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。
• 目标4： 能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。
• 目标5： 遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。
• 目标6： 具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。
• 目标7： 能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。

4.2 目标评分

目标	掌握程度（百分制）	相应解释
目标1	90%	明白身为工程师职业道德规范的重要性，了解国情社情民情，设计的软件应该对社会产生积极的影响。
目标2	75%	了解需求分析的全部过程，能根据客户的需求做出相应的调整，但是还不是很熟练。
目标3	80%	软件的开发过程大体的掌握，无论是设计模型还是数据模型都能设计出方案，但是细节部分处理不好。
目标4	71%	创新部分还有待加强，但是具有对于设计模型的评判能力。
目标5	95%	在编写代码的时候严格遵循API文档书写，代码的规范性高，精确到大小写和格式，具备与业界同行交流的能力。
目标6	90%	组队时，在团队中负责后端部分，分工明确。每日站立式开会线下沟通，更加有效的了解代码的问题在哪，服从团队安排，默契完成任务。
目标7	70%	能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，但是不太熟悉配置。

五、 个人技术

• 个人技术博客链接
• 技术概述

关于使用Go语言调用ChatGPT API接口，在我们需要与机器人聊天，语言翻译，文本生成，等各种Prompt时需要调用ChatGPT API接口。其中我认为的难点是数据结构的构建和转换，ChatGPT接口所需的格式，通常是JSON，可能需要进行结构体定义、字段映射和JSON序列化等操作。在调用ChatGPT接口的过程中，需要适当处理可能发生的错误和异常情况。这包括检查HTTP请求是否成功、处理网络连接错误、处理HTTP响应状态码以及处理JSON解析错误等。