软件工程实践总结

软件工程实践总结

这个作业属于哪个课程	<2021春软件工程实践S班>
这个作业要求在哪里	<软件工程实践总结&个人技术博客>
这个作业的目标	课程回顾与总结与个人技术总结
其他参考文献	...

目录

• 软件工程实践总结
  • 课程回顾与总结
    • 提问链接
    • 提问
    • 在项目的需求/设计/实现/测试/发布阶段（一共5个阶段）中，每个阶段收获最大的知识或能力
  • 个人技术总结

课程回顾与总结

提问链接

原提问博客

提问

一、在3.1中提到了关于团队对个人的期望

大多数工程师都在团队的环境中工作，怎么样才是一个合格，甚至优秀的队员呢?前面提到了PSP ( Personal Software Process )，和它对应的有团队的软件流程TSP ( Team SoftwareProcess )，TSP对团队成员也有要求:

1.交流:能有效地和其他队员交流，从大的技术方向，到看似微小的问题。

2.说到做到:就像上面说的“按时交付”。

3.接受团队赋予的角色并按角色要求工作:团队要完成任务，有很多事情要做，是否能接受不同的任务并高质量完成?

4.全力投入团队的活动:就像一些评审会议，代码复审，都要全力以赴地参加，而不是游离于团队之外。

5.按照团队流程的要求工作:团队有自己的流程（见“团队和流程”一章)，个人的能力即使很强，也要按照团队制定的流程工作，而不要认为自己不受流程约束。

6.准备:在开会讨论之前，开始一个新功能之前，一个新项目之前，都要做好准备工作。

7.理性地工作:软件开发有很多个人的、感情驱动的因素，但是一个成熟的团队
成员必须从事实和数据出发，按照流程，理性地工作。很多人认为自己需要灵感和激情，才能为宏大的目标奋斗，才能成为专业人士。著名的艺术家Chuck Close 说:我总觉得灵感是属于业余爱好者的。我们职业人士只是每天持续工作。今天你继续昨天的工作，明天你继续今天的工作,最终你会有所成就。

那个人应该对团队有期望吗？还是说应该如何选择适合自己的团队？

经过一个一学期的软件工程实践，当初觉得选团队和领队关系很大，现在也有了一些新的体会，比如确切体会到了管理者的作用。第一次Github实战，在组长青涩的领导之下，一顿手忙脚乱，中途遇到了各种问题，最后的结果也不尽如人意。经过后来几次团队作业，大家都有了成长，组长的管理能力也有了提升，一切也变得井井有条起来。

二、关于书中4.3.2提到goto

函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用,包括goto

实际应用中，goto究竟适不适用？团队会不会对这方面有所要求？

这里只有一条从实践中得体会，跟着团队的代码规范走就得了。

三、书中6.3关于敏捷的团队

敏捷对团队的要求很简单:自主管理( Self-managing )、自我组织（Self-organizing )、多功能型(Cross-functional )，但是这很难做到。
软件项目的团队各式各样（请看“团队和流程”一章)，假设一个团队做得还不错，现在要变成敏捷流程，那团队要做下面的改变:

1.自主管理:以前领导布置了任务，我们实现就可以了，现在要自己挑选任务;每次
Sprint结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自主管理”不等于“没有管理”。
2．自我组织:以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。
3．多功能型:以前规格说明书由PM来写，测试由测试人员来做，现在每个人都全面负责,自己搞定规格说明书，和别人沟通，同时自己搞定测试。

这里提到了每个人要联合起来对项目负责,落后还要帮忙改进。但是书中也提到过我们在团队中要各司其职，如7.2.4。这冲突吗？

“每个人要联合起来对项目负责,落后还要帮忙改进”是敏捷的团队中的内容，而“各司其职”指的是一般的团队，实际上我们在实践中也是各司其职的，但是也有“落后还要帮忙改进”的情况。后来再次阅读书本发现当初误把敏捷的团队和一般团队放在一起比较了。

四、在12.1.3中提到的了

长期使用之后，软件会更好用么?

在设计软件界面时，我们的设计师经常会画新功能的UI设计图，来征求大家的意见。我注意到大部分设计都假设用户是头一次使用产品，
所以没有任何积累的文件、照片、处理过的图像、曾经做过的选择等数据。我同意第一印象很重要，但是当用户已经是第N次使用你的产品时，你的UI能否为这些用户提供方便呢?你的产品是下面的哪一种:

a．软件用得越多，一样难用

b．软件用得越多，越发难用

c．软件用得越多，越来越好用

软件是否好用和硬件也是相关的，但硬件发展很快（摩尔定律），所以软件开发的时候也要考虑硬件。

这abc三种情况是可能同时出现的，那么开发者如何把握软件功能的提升和对硬件的要求提升的平衡？

        同一款软件不断更新，可能有人会觉得越来越好用，因为他的硬件性能强大，有人觉得越发难用，因为他可能用的是好几年前的机器。
        拿手机来说，app的大小增长简直太可怕，几年前还是十几M或者几十M，现在动辄几G，有些应用因太大被用户暂时抛弃。
        我觉得软件提升前要考虑当前设备的持有分布，把握好用户群体分布，利益最大化；
极端假设：社会上所有人都很有钱，设备一直保持最新款，那软件的提升就只需要考虑软件本身的功能性能了，完全不用考虑用户的硬件是否支持，因为用户的硬件一直是最好的。

五、书中16.3.0提到的改良式创新(Incremental Innovation)和颠覆式创新(Disruptive Innovation)

提到了个故事：

雅卡尔( Joseph Marie Jacquard ) 1752年出生于里昂，一成年便在丝绸工坊打工，并且很快成为一个有创意的、技艺娴熟的工匠。
他的改革计划在法国大革命期间多次中断，但1805年一大批改革后改进后的半自动织机最终在法国运转了起来。
新织机不但缩短了产品的成型时间,更重要的是减轻了劳动量，减少了工作人数。这必然引起大批工人的恐慌和随之而来的抵制及破坏，
因为使用雅卡尔织布机后，原来需要六名工人完成的工作现在只需一名，这就意味着大批工人的失业。雅卡尔多次受到人身攻击，甚至有人对他以死相逼，
更严重的是，工坊里的新型织机不断被损坏和焚烧。尽管如此，革新的成果还是迅速遍及全国。1812年，整个法国已装置了一万一干多台雅卡尔自动织布机。

颠覆式创新的影响这么大，会不会对这种创新起到致命影响？比如因人身攻击之类被迫停止。有没有办法减小影响的同时改变社会？

查阅资料：

一旦颠覆性创新出现（它是市场上现有产品更为便宜、更为方便的替代品，它直接锁定低端消费者或者产生全然一新的消费群体），现有企业便立马瘫痪。
为此，他们采取的应对措施往往是转向高端市场，而不是积极防御这些新技术、固守低端市场，然而，颠覆性创新不断发展进步，
一步步蚕食传统企业的市场份额，最终取代传统产品的统治地位。

​ 我的想法和原先还是一样，也认为蚕食是个好办法，可以有效的减少冲突，但是需要付出时间代价；但是要是能更快的带来变革，也一定有积极的影响吧。至于会不会对创新起到致命影响，
​ 如果那么容易被击败，也就不能称得上颠覆式创新了吧，我认为影响最多就是蛰伏一些时间，当然时间也可能很长。

在项目的需求/设计/实现/测试/发布阶段（一共5个阶段）中，每个阶段收获最大的知识或能力

需求阶段：提升UML的相关能力

设计阶段：提升了绘制ER图与类图相关能力

实现阶段：学习了SSM框架整合开发

测试阶段：学习了一些测试工具如JUnit、JMeter的使用

发布阶段：学会了在服务器上部署Java web项目

个人技术总结

在第一次作业“准备篇”中你为自己制定了学习路线，现在学习了怎么样了？你在团队开发中是否担任了开发角色，你在开发中解决了哪些技术问题？获得了哪些技术进展？

学习路线已经中途转弯了。。。本来是计划学习前端知识的，结果后来在团队时由于后端人员不足去学习后端了。在团队中负责部分模块的后端开发。在开发中解决了一些文件上传下载问题。SSM整合开发能力获得提升。

链接：

SSM框架实现附带信息的文件上传&下载

概述：SSM框架实现附带信息的文件上传以及下载的一些内容