软件工程实践总结----完结撒花

182000318刘伟文学生 2023-06-06 10:20:00

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

一、收获

阶段	收获
需求	在需求分析阶段，我的收获是根据NABCD进行项目分析，对所学知识进行实践。并通过答辩，体会一个项目，如何找准和吸引投资者，怎么更好的进行分析
设计	学习了怎么使用工具进行原型的设计
实现	在结对作业中，提前熟悉了还没使用的JavaEE进行网站开发。在团队作业里学习了Vue，并立马投入使用。通过实现阶段，体会了掌握知识到实践的不易
测试	在这一阶段，对几个网站进行测试。掌握了产品的测试方法，了解其他同学测试的独到方法，更好的帮助自己在开发时规避缺陷。
发布	学会了产品的服务器部署，以及通过用户调查，对产品进行改进和完善

二、心得 --- 吐槽

团队项目：这次的项目实践是一个较大的项目，持续时间长。对于人员的合理安排，非常重要。如果在发现不合适的情况下，应该尽早修改，没有代码能力的，可以把博客等内容交给他们，有代码能力的，应着手于项目开发。

我们这次的项目一开始的时候做出的人员安排，在项目开发中出了挺多问题，前端的人员工作量是后端的好几倍。后端的压力给到少数人手上。在前端赶进度的时候，后端可以停滞很多天，没有任何任务。

并且前端的压力主要给到同宿舍的三个人，对于其他宿舍的人员安排，没法监督，任务完成没有反馈，自己闷声写。我们只能把任务都内部消化了。
我们可能需要熬夜到一两点来改Bug，只能说很难评。

与此同时，我们也发现，制定开发文档很重要 ，但是遵守文档进行开发更为重要！！！！

有些组员写的东西，按照自己的思想来，造成了很多难以预料的错误。比方说res返回，在api文档中写好了返回的格式，不按格式，对接的时候找了很久无法获取数据。再比如，规定好的类型，不遵守，写了一些不存在的属性，不知道哪里来的命名。再比如约定好了返回的东西，自己觉得没有用，擅自删除了,导致在req里面发送找不到发送的东西。再比如，写好的res属性名字，同样的返回类型，在不同的api里面，设置了不一样的不遵守文档的命名，导致前端的按文档请求的全是错误的，什么都获取不到。再比如，由于传回的参数类型，不遵守，重新传回时，造成了奇怪的问题。

这上面的每一个错误都需要前端，不断的重复尝试。浪费了不知道多少的时间。而这些错误都需要到对接才能发现。前端按进度写好的东西，到规定时间对接时，完全实现不了。
为了α冲刺能发布勉强能用的版本，白白熬夜。占用个人原定计划的时间。如果制定不是为了遵守，制定的意义在哪里？？？？

三、自我评估

目标1：理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念

90分，通过网上的各种案例，深刻了解了IT从业者不遵守职业道德规范的后果。并在耳濡目染中体会到了软件产品对社会、健康文化的影响。
目标2：掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。

80分，通过软件工程课堂的知识，具备了需求分析建模的能力，但是实践的次数较少，难以规范、准确地表达客户的需求。
目标3：掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。

80分，仅学习过相关知识，还没实践过。但是能遵循体系结构设计方法和基本设计原则
目标4：能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。

85分，项目的开发过程中，了解了评判的方法
目标5：遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。

90分，编写并使用了文档来进行开发，对该能力有一定的实践能力
目标6：具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。

95分，在项目开发里通过交流，解决了乱七八糟的问题
目标7：能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。

85分，对项目规模和工作量的估算具有一定能力，但是对于管理复杂项目还需要锻炼

四、问题思考

之前的博客链接

Q1:我都是大学生了，上课还要认真听老师讲课么？问题链接

我仍然认为这需要按情况来分析，有些东西听了也没用，它是理论的东西，但需要通过实践来得到，不然认真听了也没用。
在实践中发现的，老师讲的有些过于理论，听也没用，反而是边实践边理解有用，效率还高。
Q2: 为什么过早优化的后果会严重到成为“万恶之源”？问题链接

在整体设计完成之前过早的优化局部，会耽误其他部分的进度。而且，过早优化后未考虑其他部分实际的效率可能会低于预期。在开发中，有些问题并不是该优先解决的，为了完成α冲刺的项目交付，有些优化必须延后，才能不拖延进度。
Q3:在项目或程序比较复杂的情况下，如何高效率的进行程序理解？问题链接

通过阅读之前团队留下的注释或者文档。如果缺少注释，就需要和其他成员沟通，了解各个负责的部分。
在进行开发时，我们是以组件为单位进行开发的，为了进行整合必须弄清每个的功能，我就是通过文档和注释来了解各部分的功能，以及需要如何整合
Q4:如何发现社会的潜在需求？类似小黄车这样的项目，之前从未有人提出来过，这种颠覆性的创新是如何提出并且恰好被市场认可？问题链接

在实践中，我发现，需要依靠个人对市场的敏捷性，以及对用户使用的痛点和需求深刻了解才能创造出类似小黄车这样的项目。并且需要不断地试水才能获得认可，并不存在所谓的恰好
Q5:如何在团队中建立相互信任的关系？问题链接

在团队里，信任需要依靠个人的任务完成情况来获取。这次作业里，后端频繁的出错就失去了相互信任。想要改变，就需要主动的在错误发生后，进行一次整体的复查，给出确切的答案，而不是被一次次的提醒，又写出错误，而不主动修改。