310
社区成员
发帖
与我相关
我的任务
分享“独行快，众行远”——团队协作中的技术挑战与成长|222100306实践总结
| 这个作业属于哪个课程 | 软件工程实践-2023学年-W班社区-CSDN社区云 |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客-CSDN社区 |
| 这个作业的目标 | 覆盖课程目标1、4、5 |
| 其他参考文献 |
第一部分 “独行快，众行远”——团队协作中的技术挑战与成长
5个阶段中，每个阶段收获最大的知识或能力是什么？
-
需求分析阶段：
-
收获：掌握了需求分析的基本方法和工具，如UML图、用户故事等，并学会了与客户进行有效沟通，确保需求的准确性和完整性。
-
能力：能够清晰地理解和表达客户需求，构建需求分析模型。
-
-
设计阶段：
-
收获：深入了解了多种设计模式，如单例模式、工厂模式等，掌握了架构设计的基本原则和方法。
-
能力：能够设计高内聚低耦合的系统架构，提高系统的可维护性和扩展性。
-
-
实现阶段：
-
收获：熟悉了编码规范、版本控制（如Git）、单元测试等实际开发中的重要环节。
-
能力：能够编写高质量的代码，并通过代码审查和测试确保代码的可靠性。
-
-
测试阶段：
-
收获：掌握了功能测试、性能测试和安全测试的基本方法和工具，了解了测试覆盖率和自动化测试的重要性。
-
能力：能够编写自动化测试脚本，使用工具进行性能测试，分析测试报告找出系统的瓶颈和问题。
-
-
发布阶段：
-
收获：了解了版本控制、部署、发布文档编写和用户培训等发布环节的重要性。
-
能力：能够进行自动化部署，提高发布效率和质量，并快速响应用户反馈，及时修复问题和更新版本。
-
结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。
在深入参与多个项目的过程中，我收获颇丰，无论是在个人项目中锻炼的独立思考和问题解决能力，还是在结对编程和团队项目中锻炼的协作与沟通技巧，都对我产生了深远的影响。
个人项目：
个人项目是我技术成长的摇篮。在这里，我学会了如何将一个模糊的需求转化为清晰的开发任务，如何制定合理的时间规划，并一步步实现目标。在这个过程中，我深刻体会到了持续学习和自我驱动的重要性。每当遇到技术难题时，我会积极查阅资料，学习新知识，不断尝试，直到找到解决方案。这种独立解决问题的能力，不仅让我在技术上有所突破，也锻炼了我的意志力和自信心。
结对编程：
结对编程让我深刻体验到了合作的力量。与伙伴共同工作，我们可以相互学习、相互启发，共同解决问题。在这个过程中，我学会了如何更好地与他人沟通，如何听取他人的意见，并尊重他人的工作。同时，结对编程也让我意识到，分工合作是提高效率的关键。通过明确分工，我们可以避免重复劳动，提高开发效率。此外，与伙伴共同工作也让我学会了如何更好地管理时间，确保项目能够按时完成。
团队项目：
团队项目则是一个更大的舞台，让我学会了如何在大团队中协作。在团队中，每个人都有自己的专长和角色，我们需要相互信任、相互支持，共同为项目的成功而努力。在这个过程中，我学会了如何更好地与团队成员沟通，如何协调各方资源，如何制定并执行计划。同时，我也深刻体会到了团队文化的重要性。一个积极向上的团队文化可以激发团队成员的潜力，提高整个团队的凝聚力。
技术与实践：
在多个项目中，我不仅积累了丰富的开发经验，还深入了解了多种技术框架和工具。例如，在最近的一个项目中，我们使用了微服务架构和Docker容器化技术，这让我对分布式系统和容器化技术有了更深入的理解。同时，我也学会了如何使用Git进行版本控制，如何使用Jenkins进行自动化构建和部署等实用技能。这些技术的掌握不仅提高了我的工作效率，也为我未来的职业发展奠定了坚实的基础。
总结与展望：
回顾自己的项目经历，我深感自己在技术、协作和沟通等方面都有了很大的提升。这些宝贵的经验不仅让我更加自信地面对未来的挑战，也让我更加明确了自己的职业发展方向。未来，我将继续努力学习新技术、新知识，不断提高自己的综合素质和竞争力。同时，我也期待能够参与更多有意义的项目，与更多优秀的伙伴一起成长、一起进步。
自我评估对通过课程的学习，对各个课程目标的掌握程度，并作出解释。
-
目标1（职业道德规范和实践要求）：
在软件开发的实践中，职业道德规范是每一位软件工程师都必须坚守的底线。这意味着我们不仅要追求技术上的卓越，还要关注我们的软件产品对社会、健康和文化的影响。
在职业道德规范方面，我深刻理解软件工程师的责任和使命。我始终将用户利益放在首位，关注软件产品对社会、健康和文化的影响。在项目中，我始终坚守诚信、公正和尊重的原则，与团队成员和客户保持良好的沟通和合作。
-
目标2（需求分析全过程）：
需求分析是软件开发中至关重要的一环。为了准确表达客户需求并构建需求分析模型，我们需要与客户进行深入的沟通和交流。通过收集需求、分析需求、验证需求等一系列步骤，我们可以确保对客户需求有全面而准确的理解。在需求分析的过程中，我们还需要注意识别潜在的需求和约束条件，以确保最终的产品能够满足客户的期望。
在需求分析方面，我能够与客户进行有效的沟通，准确理解他们的需求，并构建清晰的需求分析模型。我善于使用各种需求分析工具和技术，如用例图、流程图等，来辅助我进行需求分析和设计。同时，我也注重需求变更的管理和跟踪，确保项目的顺利进行。
-
目标3（软件开发全过程）：
软件开发是一个复杂而繁琐的过程，需要我们遵循设计原则和方法，完成高效可靠的服务组件设计。在开发过程中，我们需要关注代码的可读性、可维护性和可扩展性，以确保软件的质量。同时，我们还需要关注软件的性能和安全性，避免任何可能的漏洞和缺陷。为了提高开发效率，我们可以采用敏捷开发、持续集成等先进的开发方法和技术。
在软件开发过程中，我能够遵循设计原则和方法，完成高效可靠的服务组件设计。我注重代码的可读性、可维护性和可扩展性，并努力避免潜在的性能和安全问题。我熟悉各种开发工具和技术，如版本控制系统、自动化测试工具等，能够提高开发效率和质量。
但缺点是，有时候因为重构代码特别复杂，宁愿继续对代码进行堆砌，而懒得进行整理，这是需要改进的地方。
-
目标4（技术评测和设计能力）：
技术评测是评估软件质量的重要手段。从组件到系统，我们都需要进行技术评测，以确保软件的质量和性能。
在技术评测和设计方面，我能够进行从组件到系统的技术评测，评估软件的质量和性能。我具备设计模型的评判能力和创新设计意识，能够根据需求和约束条件设计出最合适的解决方案。同时，我也关注新技术的发展和应用，不断学习新的技术和工具。
-
目标5（文档撰写和交流能力）：
文档撰写是软件开发中不可或缺的一环。通过撰写规范的需求规格说明书、系统设计说明书、系统测试报告等文档，我们可以确保团队成员之间的理解和沟通。同时，这些文档还可以作为项目交付的重要资料，为项目的维护和升级提供支持。为了提高交流能力，我们可以参加各种技术交流活动，与业界同行分享经验和心得。
在文档撰写和交流方面，我能够撰写规范的需求规格说明书、系统设计说明书、系统测试报告等文档。我注重文档的清晰度和逻辑性，使团队成员和客户能够轻松理解项目的进展和成果。同时，我也具备良好的交流能力，能够与业界同行进行有效的沟通和交流。
-
目标6（团队意识和合作技能）：
在软件开发中，团队合作是至关重要的。我们需要与团队成员有效沟通和协作，共同完成任务。为了实现这一目标，我们需要具备良好的团队意识和合作技能，能够积极参与团队讨论和决策，关注团队目标和利益。
在团队合作方面，我具有良好的团队意识和合作技能。我能够与团队成员有效沟通和协作，共同完成任务。我注重团队目标和利益，愿意为团队的成功贡献自己的力量。同时，我也尊重他人的工作和意见，能够与团队成员保持良好的合作关系。
-
目标7（项目管理能力）：
项目管理是确保软件开发项目成功的关键。我们需要掌握软件项目管理的基本要素，如软件规模和工作量的估算、软件进度的规划和管理等。
在项目管理方面，我能够掌握软件项目管理的基本要素，如软件规模和工作量的估算、软件进度的规划和管理等。我熟悉各种项目管理工具和方法，如甘特图、敏捷开发等，能够进行有效的项目管理和风险控制。我注重项目的细节和进度，确保项目能够按计划顺利进行。
-
总结：
总的来说，我在上述七个目标方面都有一定的掌握和实践经验。然而，我也意识到自己在某些方面还有提升的空间，如项目管理能力和技术评测能力等。因此，我会继续学习和努力，不断提高自己的综合能力和专业素养。
回顾自己思考过的5到10个问题：尝试解答、继续分析、提出新问题。（20’）
寒假博客如下：软件工程实践寒假作业-CSDN社区
里面提出了17个问题的思考与分析，现在回头看，当时的思考已经比较深入，接下来将列出当时的思考，并进行补充。
片段1
-
内容：
软件还有其他特性： 软件团队中存在许多不同的角色
-
思考：
-
"工程中有不同的角色"这是我们还缺乏实践经验的。
-
感觉进入软件的开发，更倾向于独立完成，并不擅长联合做工作。
-
我在书上看到这一点的时候觉得知之尚浅，也许软件真的是一个团队的过程，而这个过程还等待我去探索，有一个合拍的团队很重要。也许软件的世界真的不是一叶扁舟，而是千帆竞渡。
-
片段2
-
内容：
Build To Serve：为了服务一定范围的目标用户而构建的工具等，有时以公开的SDK形式发布。
-
思考：
-
第一次知道SDK和接口，听起来和高端，听不太懂，后来慢慢理解，为什么叫做“接口”
-
【比喻】就是像烟花炸弹，里面的化学反应、构造不用我们去研究，只留一根线，我们只要知道怎么用就行；接口就是“引线”，SDK就是打包好的“炸弹”本身。这大大方便了我们代码的编写和使用。
-
片段3
-
内容：
好的单元测试的标准： 单元测试必须由最熟悉代码的人（程序的作者来写） 单元测试过后，机器的状态保持不变
-
思考：
-
在另一篇文章读到“测试最好不要由最熟悉代码的人来做”，因为这样会产生测试盲区。
-
测试时不仅需要以程序员为角度的测试，还需要以用户实际使用情况为角度的测试。
-
而测试和维护在软件工程中的占比，比软件编写完成所需的精力要多。
-
片段4
-
内容：
讲究高内聚低耦合
-
思考：
-
内聚：是单个模块中内部各组件的链接情况；
-
耦合：是各个模块中的互联情况。
-
我想起一开始学习分模块，不明白为什么要多此一举。
-
一个文件就可以跑程序，为什么要分成多个文件呢？有什么区别吗？
-
后来发现是因为开发的软件并不难，功能简单，不需要分为复杂的板块，而在实际开发过程中，当我们需要开发一个极其复杂的软件时，分板块就能为清晰思路减轻不少负担。
-
-
而为什么要高内聚低耦合呢？
-
让我们反过来思考——“低内聚，高耦合”：
-
板块内部各个部分没啥联系，各个板块间的联系很强，那么板块内部的各个部分为什么不分成多个板块呢？
-
不仅如此，还会“牵一发而动全身”，动了一个板块的某部分，由于各个板块间联系大，其他板块也要被牵连，维护成本又加大了。
-
-
那么再回过头看高内聚低耦合，就很合理了，一个小部分的牵动几乎只影响板块本身，大大降低了调试维护成本。
-
片段5
有很多代码编辑器，请把其中一个用得非常熟练。让编辑器可以实现自己的定制，可以用脚本驱动，用起来得心应手。 a) 只用老师教的一个； b) 随意； c) 没有任何定制； d) 会定制，并且分享给其他人； e) 还会学习和使用各种编辑器的扩展。
-
思考：
-
代码编译器原来是可以定制并用脚本驱动的！曾经听说过但不这么用，更不会分享给他人，说实话，我的代码量也是一个微乎其微的水平。每次有编程任务，好像都是压力巨大的活。
-
对于编译器，确实使用过许多不一样的编译器，各种编译器之间还有很多功能上的差别。比如个人认为Clion就比Dev-C++好用得多。由此以来，熟练使用某个编译器变得很重要了。
-
在编写代码时，会出现单词联想，减少了手动输入的代码量，减小了因为拼写错误出现的bug；
-
编写代码过程中，就会出现错误警告，而无需通过手动编写；
-
对于调试过程对值的监控也更加方便；
-
还能自动规范代码风格。
-
-
片段7
代码版本管理工具是你代码的保障，重要的代码一定要有代码版本管理。 a) 从来没听说过； b) 用QQ，u盘即可； c) 领导要求才用； d) 经常用； e) 不但主动做，还会影响同事一起做好。
-
思考：
-
备份是很重要的。像用坚果云等软件做文件备份一样，代码也需要好的版本管理。
-
最常见的代码管理工具是git，代码的回溯在我们编写的时候看起来，好像只是急救时的一条路，但当我们真正需要时，会发现它非常重要。
-
片段8
在debug的时候，不要惊慌，想想导致问题的原因可能在哪里。一步一步地找到原因。要在实践中运用工具，善于分析日志（log），从中找到bug。同时，在自己的代码里面加log. a) 从来没听说过； b) 只会printf； c) 加log太麻烦，我的代码不会有bug的； d) 一直主动这样做； e) 不但主动做， 还会影响同事一起做好。
-
思考：
-
听说过加log，但以为是写日记这种东西。一般调试的时候，我是用print，才知道log是比print更加精准的用法。
-
片段9
在设计中把展现模块 (View) 和实体模块 (Model) 分开，这样你的设计会更有灵活性。 a) 代码都在一起比较好改； b) 随缘啦； c) 没搞清楚啥是V，啥是M； d) 一直主动这样做； e) 不但主动做，还会影响同事一起做好。
-
思考：
-
听过MVC架构，也尝试过分离V和M，但在分离时还是觉得多次一举，其实我认为，VM一起写，不是挺合理吗？
-
片段10
在实际的运行场景中测试你的算法，不要停留在数学分析层面。有时候一个小小的实际因素 (是否支持大小写敏感的排序，数据是否支持多语言)会导致算法效率的巨大变化。 a) 从来没听说过； b) 想用，但不知道工具； c) 主要靠肉眼观察算法效率； d) 一直主动这样做； e) 不但主动做，还会影响同事一起做好。
-
思考：
-
原来连是否支持大小写敏感都会大大影响算法效率啊！
-
片段11
和一个实际的用户一起使用软件，获得第一手反馈。 a) 从来没听说过； b) 用户太蠢，不值得听反馈； c) 想做但是没有机会； d) 一直主动这样做； e) 不但主动做，还会影响同事一起做好。
-
思考：
-
原来检验软件是否合格的一个好办法，是可以和一个实际需求用户（他不一定要懂代码！）一起检验软件！曾经尝试过，这种体验秒极了，不仅可以获得用户的使用体验（程序员会慢慢淡化这种体验），还可以和用户沟通软件的搭建，互相了解。
-
片段12
（带领团队）了解用户的期望值，稍稍超出用户的期望值，让用户有惊喜。 a) 从来没听说过； b) 我们决定用户的期望； c) 如果有明确要求，我可以做好； d) 一直主动这样做； e) 不但主动做，还会影响同事一起做好。
-
思考：
-
这样的软能力是一个好思路。买瓜子的时候，老板总会多加一把，会让人感觉很爽
-
而“求其上取其中”，当我们选择把目标建立在稍高于期望值之上，往往能让用户达到期望。
-
片段13
团队如何评价自己的软件工程水平？ 有人说，“我们团队很强......” 是碰巧公司很有钱，还是团队的某个人有真功夫，那这个人走了团队还强么？究竟什么是团队的软件工程能力强？
-
思考：
-
这也是我一直在思考的问题。什么叫做团队强？团队强和个人强有什么关系？只要个人强团队就能强吗？什么叫做团队强？
-
我听说，团队各人各司其职，各有长处。作为领导者，未必需要懂得具体的实现步骤，但是它却能调动组员的积极性，发挥出他们的优势，这让我想到团队强未必个人强，个人强也未必团队强。
-
团队是一种新的独立于不同于个人的存在，评判的标准也是有别于个人评判的新标准。
-
片段14
除开外部原因，团队内部也在变化，我们对技术的掌握每天都在提高，原来认为不可能的事可能变得容易。我们对客观世界和软件系统的了解每天都在深化，原来觉得没问题的小细节忽然成了大问题。甚至原来一起打拼的同事忽然要离开……这些都要求我们团队保持敏捷的身段。
-
思考：
-
我们对技术的掌握每天都在提高，原来认为不可能的事可能变得容易。原来觉得没问题的小细节忽然成了大问题。让我预感到未来可能产生的感觉。
-
此一时彼一时，随着知识的积累和水平的提高，对原有事物笃定的认知可能会动摇，甚至发生翻天覆地的转变。
-
片段15
MSF在每一个里程碑结束时都要做一个“**里程碑回顾**”，这个回顾不必等到整个项目结束才做。这样做的好处是，大家对最近的成败都记忆犹新，能提供比较准确和全面的反馈；如果发现了错误，可以马上研究解决办法，在下一个里程碑中通过实践来验证。另外，一些好的做法可以及时得到总结和推广。 在项目结束时，MSF推荐请团队以外的专家来主持召开“**事后诸葛亮**”会，这样的专家会比较系统地总结团队的成功经验和失败教训，同时也客观评价团队的一些特性和团队的开发过程管理，这样能促使团队成员以客观、向前看、解决问题的心态来参加“事后诸葛亮”会，避免主观臆断或相互指责。
-
思考：
-
在项目答辩安排里看到“事后诸葛亮”这个词，原来是出自《构建之法》。对这个过程没有什么概念，大概是从来没有对“事后诸葛亮”做一个完善的总结。
-
在小时候的学习过程中。倒是有很多这样的经验，每次都在想“要是一开始这么做就好了”。但是这个词让我知道，“诸葛亮”都是最后出现的，也许一开始如何做也好，都必须等到最后出现结果，再复盘，才能提出比原来的解决方案。就像知道答案，再去想解决办法一样。
-
但是“大道至简，殊途同归”。各种问题之间总有相似之处，结果也有相近之处，也许解决方案的经验，就是在一遍又一遍“事后诸葛亮”中得到的。
-
片段16
11.3 其他设计方法 形式化的方法、文学化编程
-
思考：
-
文学化编程是什么？
-
片段17
这本书的作者邹欣老师在微软公司工作，他在整本书中把对软件构建的方方面面都写得很清楚，包括需求，设计，开发，测试，项目管理......甚至国内很多公司都无法做到像书中说的流程那么全面和到位。作者的思路很清晰，文字也很有趣，让人欲罢不能。全书都有很大的参考价值，至少对于我目前这样的状态的程序员来说，了解自己要怎么做，做的方向比要做什么更重要，本书提供了很多建议和方法，比如PSP（Person Software Process，在我看这本书之前，完全没有听说过PSP这个东西，），也由此了解到作为一个软件工程师，任务清单里面不仅只有要编好程这一项而已，还有计划，需求，测试，评估工作量等能力需要刻意培养。
-
思考：
-
由于寒假专注于比赛和其他更重的事，没有关注课程消息错过了布置浏览《构建之法》的宝贵时间，但是阅读这篇文章，让我对《构建之法》很感兴趣，想要立刻拿到书来读一读。
-
我们学过很多计算机的课程，但有些课本内容依旧抽象，像把一个抽象的东西讲得能让外行人都听的懂，是很稀罕的。
-
虽然我们身处大三，已经不是连C++基础语法都不会的“门外汉”了，但是对于计算机的底层原理，还是没有自己独特的正确的见解，也无法与“门外汉”谈及计算机的有趣，这让我感觉在IT行业还是依然处于知之甚少，只知皮毛的状态。
-
片段18
这本书最具特色的一个地方是把很多生涩难懂的概念用学生之间对话的诙谐幽默、生动风趣的场景来展现了出来，甚至还加入了一些电影中的经典台词、一些足球术语和篮球明星的专属名词，让我这个电影迷足球迷篮球迷一边读一边大呼过瘾，更开心的是学习到了很多知识，尤其是在软件工程项目开发过程中的许多技巧和需要注意的问题。
-
思考：
-
最让我感兴趣的是书中与其他学科的共联。
-
虽然我们是工科，与文科好像被人为划分一条鸿沟，井水不犯河水。但是《大学》说：“物有本末，事有终始，知其先后，则近道矣。”而万物同根，各个学科一定也有自己的联系。用其他领域的话解释这个领域的知识，会让知识更加灵动，也更加生动有趣。
-
文章后提到的建立了生动的人物形象来阐释书本内容，让我尤其感兴趣，这一做法在许多书籍中，是不常见的。
-
而文章最后对于自己学习软件工程的认知，比如觉得学好软件工程只要会编程，会算法，会计算机网络，就可以了，但往往不止于此。
-
而同样，我认为，当我们认知提升后，就会慢慢也领悟到这一点。曾经我们以为了不起的技能，可能只是基点，而要做的还有很多很多。
-
我们的路还很长，基础知识只是基本操作而已。而对于软件开发，团队的合作是必不可少的，我们很难单打独斗，不然要公司干嘛呢？这是我们逐渐在实践中需要领悟到的，也是现在缺少的。
-
另外，当我们慢慢意识到，软件工程师不止于编程，软实力的重要性也渐渐浮现，我们会发现，有时候光会编程很厉害，已经不管用了，如何敏捷开发，如何沟通团队，具有这样的能力，已经不是“无用”，而乃“大用”。
-
-
总而言之，在综合的评价体系下，对一个人的评价也更加综合，不仅仅是单方面会编程、单方面会沟通就足够，综合素质，更加体现一个人的价值。
第二部分 个人技术博客
链接
概述
Spring Boot是一个用于快速构建Java应用的框架，尤其适用于微服务架构。
MVC 模式实现业务逻辑与视图分离，支持团队协作。
我在团队开发中因缺乏Java和Spring Boot经验而遇到挑战，但通过不断学习和实践，我逐渐掌握了Spring Boot与Java的基础知识，理解自动配置机制、MVC 组件交互及异常处理，并在项目中实现了功能。
总结
在这篇技术博客中，我详细回顾了自己在团队开发过程中使用Spring Boot框架和MVC模式的经历。起初，由于对Java和Spring Boot不够熟悉，我在项目开发中遇到了不少挑战。然而，通过持续的学习和实践，我逐步掌握了Spring Boot的基础知识，深入理解了其自动配置机制、MVC模式中各个组件之间的交互，以及如何有效处理异常。
我认识到Spring Boot之所以能简化新Spring应用的搭建和开发过程，是因为它采用了“约定优于配置”的理念。在MVC模式中，我了解了Controller、Service、Repository和Entity等组件的作用，它们共同构成了一个可扩展的web应用程序架构。我学习到，团队之所以选择MVC模式，一方面是因为它广为人知，便于团队合作开发；另一方面是因为团队成员普遍擅长Java语言。
在实际开发中，我面临了一些技术难点，包括理解Spring Boot的自动配置机制、熟练掌握MVC模式的组件交互，以及处理异常和错误。我通过实际操作，逐渐克服了这些难点。例如，在项目架构中，我负责了Model部分，包括数据持久化和数据传输对象的定义。我创建了实体类、DTO、VO以及结果封装类，以适应不同层次的数据需求。
我还遇到了一些具体的问题，比如Java和XML两种不同形式的Mapper冲突问题，我通过分析和实践解决了这一冲突。在JWT鉴权方面，我学习了如何在Spring Boot中正确地将token添加到Header，并设置了哪些路由需要鉴权。我还分享了使用Apipost进行接口调试时遇到的问题，以及如何确保调试的顺利进行。
总的来说，通过这一系列的学习和实践，我不仅提升了自己的技术能力，还加深了对团队协作重要性的认识。这些经验对我未来的软件开发职业生涯无疑是宝贵的财富。
...全文
请发表友善的回复…
发表回复
