【无标题】

这个作业属于哪个课程	软件工程实践-2023学年-W班
这个作业要求在哪里	软件工程实践总结&个人技术博客
这个作业的目标	总结
其他参考文献	docker部署nginx

一、课程回顾与总结

1.1 以前问题思考的博客链接

软件工程实践寒假作业

1.2 再次解答

在项目或程序比较复杂的情况下，如何高效率的进行程序理解？ 1. 构建工具角度：拿到一个比较复杂的项目时，可以先从项目的一些非源代码文件中看出项目的构建工具是什么，如maven，gradle。之后迅速找到其构建的关键文件，比如maven的pom.xml文件，即可快速看出该项目都使用了什么技术 2. 配置角度：接着看一般项目都会有的Config文件夹，里面一般会用源代码或XML等进行项目全局性的配置，比如全局拦截器，全局异常处理，全局工具等，有助于快速理解项目整体上的运行方式 3. 架构角度：这首先要求程序员需要对主流的编程模式、设计模式和架构模式有比较多的理解，比如说MVC框架的整体架构模式，从而能够从软件包名字就能看出项目所采用的整体架构 4. 版本控制角度：这是我软工实践下来一个很深的感受，从Git等版本控制工具的提交记录中一般就能看出整个项目的主要功能，以及开发流程。并且每一条记录都可以查看对应的修改，十分有助于程序员快速上手项目。

想从事软件开发的大学生是去企业实习成长更快还是在学校实验室实习成长更快呢？ 先说结论，我认为绝对是企业实习更快： 整个软件工程实践下来，我发现上手一个新的技术，绝对不是看看官方API文档或者看看教学视频就能融会贯通的。就算是跟着视频做了博客，做了笔记，也终究是纸上谈兵。真正想要掌握某个技术，一定要找到这种技术实际应用场景或项目，在明确的目标下通过这个技术去达成目标。在这种情况下遇到问题时去搜索才能更深的记忆在脑海中。也只有经历过足够多的弯路，踩过足够多的坑，对技术的原理和使用方法才会有更深的理解，写出的博客也才更有水准。而企业正是有最多业务，有最多实际需求的地方，深耕进去才能快速的成长自己。

低层次的问题能依赖工具解决么? 暴论：低层次的问题完全能依赖工具解决。 然而，这个结论需要一定的澄清和解释。在很多情况下，工具确实能够极大地提高解决低层次问题的效率。例如，在编程中，IDE（集成开发环境）可以帮助开发者自动补全代码、检查语法错误、进行版本控制等，这些都是低层次但至关重要的任务。同样，在数据分析中，Excel、Python等工具和语言可以帮助用户处理大量的数据，完成复杂的计算任务。 但是，完全依赖工具解决低层次问题也存在一些问题。首先，工具只是辅助手段，它们无法替代人类的思考和判断。在面对复杂问题时，工具可能无法提供完整的解决方案，或者提供的解决方案可能不是最优的。此时，需要人类根据自己的经验和知识来分析和解决问题。

为什么软件工程师个人能力的衡量中重复性工作更重要？ 经过本次实践课程与队友的磨合与开发后，我深刻的认识到在软件工程师个人能力的衡量中，重复性工作的重要性可能不是最直接的，但它在某些方面对软件工程师的评估确实有其价值。主要是以下几个角度的原因： 效率与准确性：重复性工作能够展示软件工程师在执行常规任务时的效率和准确性。能够快速且准确地完成重复性工作是高效软件工程师的重要特征之一。这不仅节约了时间，还减少了出错的可能性。 自动化与工具使用： 在解决重复性工作时，软件工程师倾向于使用自动化工具、编写脚本或创建模板。这种能力反映了工程师对工具的熟悉程度以及他们通过创新来简化工作流程的能力。 耐心与细致：重复性工作往往要求工程师保持耐心和细致，因为即使是最小的错误也可能导致整个系统出现问题。能够长时间保持这种工作状态，并且确保工作质量的工程师，往往被认为是值得信赖的。 持续学习与改进：即使在处理重复性工作时，优秀的软件工程师也会寻找机会进行持续学习和改进。他们可能会寻找更高效的算法、更简洁的代码结构或更先进的工具来优化工作流程。这种对自我提升的追求，是他们个人能力的重要组成部分。 项目管理和时间管理：当项目涉及大量重复性工作时，有效的项目管理和时间管理能力就变得尤为重要。软件工程师需要合理安排自己的时间，确保工作按计划进行，并与其他团队成员保持有效沟通。这种能力对于项目的成功至关重要。 错误处理与调试：即使在重复性工作中，也可能会出现错误或异常情况。软件工程师需要能够快速识别问题、定位错误并采取有效的解决方案。这种错误处理与调试能力是软件工程师个人能力的重要组成部分。 团队合作与沟通：在处理重复性工作时，软件工程师可能需要与其他团队成员合作，共同完成任务。良好的团队合作和沟通能力有助于确保工作的顺利进行，并减少误解和冲突的发生。

会不会有很多软件工程师可以更短时间内完成任务却特意花更长时间呢？ 一定有，因为我也打算在将来的工作中这么做 这其实不是技术上的问题，而是如何让自己在职场中活得不那么累的方法。很多情况下，工程师可能故意放慢工作速度以应对工作压力或管理问题。这可能是由于过度的工作负担、不合理的时间表、缺乏资源或支持，或者是因为他们想要通过表现出更高的工作量来获得更好的绩效评估。我认为这是十分合理的行为，职场就是个巨大的草台班子，在这样的体系中，只要不超过既定的提交时间，我认为最多提早一天交付任务才是合理的做法。

1.3 阶段收获

每个阶段收获最大的知识或能力 需求阶段：将实际需求具象为项目具体功能的能力 设计阶段：将项目功能具体到实现的能力，这其实是十分困难的。我认为页面体现上需要具体到每个页面的布局，组件，以及页面间的跳转，通信，并且确定哪些东西应该设为通用组件，哪些东西应该作为全局配置。而项目系统逻辑上一定要把每一个功能具体为一至多个接口，并且理清接口间的关系，将共通性抽离成公共方法，一定要明确哪些逻辑应该在什么层去做，并且一定要给出一个好的模块划分（包括每个模块都需要开发什么）。从而确保后期的协同开发时不会出现工作内容大幅交叉导致各种问题的发生。 实现阶段：编写接口文档的能力 测试阶段：单元测试，集成测试，以及项目监督的能力 发布阶段：项目部署的能力与整体测试的能力

1.4 理解与心得

结合本次课程的经历，我将我的心得与体会展示如下 个人开发：项目不大的情况下，我觉得这种方式是最快乐的，整个项目的架构，思路都在自己的脑海中，每一次修改都不会带来额外的沟通投入，事实上效率我认为是很高的。如果身处一个水平良莠不齐又没有管理能力较强的组长的团队中，无效沟通带来的内耗降低项目开发速度有时甚至会低于单人开发，甚至我认为这种现象有可能还是多数 结对开发：非常非常舒服的一种开发规模。尤其是分为前后端的情况下，两个人直接敲定接口文档，每一次的修改、意见也能够快速得到讨论与解决。不需要开会，也不需要项目管理软件，更不需要绩效考核，相互之间每天的交流就是最好的加油剂。 团队开发：这种开发规模的话，我认为需从两个角度讲体会。一种是组员，组员不需要有大的全局的把控，不需要对整体架构有很深的了解，不需要从零开始将整个项目架构好。我认为作为组员在一个管理较好的团队中极其舒适，根据计划按部就班的完成自己的开发任务，偶尔提一提自己的意见，并积极做好进度汇报，其实压力不大并且也是能学到技术上的东西的。另一种，就是各种小组长和总负责人。整个体验下来，我只能说，压力大、担子重，同时还要兼顾整个项目的进度监控，照顾组员情绪，进行合理分工，并且向领导、上级汇报的也是负责人。只能说，如果在薪资上无法与普通组员拉开差距，我是不会在将来的工作中当组长的，而是当一个项目中非Leader的重要技术人员。

1.5 自我评分

课程目标	评分	解释
目标1： 理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念。	95	整个项目中，我们采用了数据库密码非可逆加密，用户登录检验，仅在约球开始时间之前可查看对方联系方式等举措对用户安全进行了很好的防范，我认为我是十分遵守软件工程师的职业道德规范的
目标2： 掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。	85	许多功能的细节在初步开发对应接口完成后才能意识到
目标3： 掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。	92	作为组长负责了整个项目的设计和各种图的绘制，锻炼很多，但做的不够完美
目标4： 能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。	93	在后端开发的相互测试接口与源码品读过程中，我认为我得到了很好的锻炼，也提出了许多可以优化的方式
目标5： 遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。	98	全覆盖
目标6： 具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。	96	我认为我作为组长虽然有些开发策略上的不足，但整体的项目进度安排，分工方式都是较为合理的
目标7： 能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。	90	没有使用项目管理工具，但通过QQ的管理倒也不是非常差

二、个人技术博客

docker部署jar包应用与nginx代理[CentOS]