| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 在结对项目和多人团队项目中，更加系统地学习软件开发，培养工程化的思维 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾本学期课程经历以及自己对课程的感悟 |
| 个人博客 | 提问博客连接 |
提问
写了再改Code-and-Fix模式真的很差吗?
在这篇博客中,提到了使用写了再改模式缺点很多.但是在现实中写代码往往遇到设计很难想到的问题,比如oo课程中的表达式求导,很难说一次就想到一个很好的代码实现架构.而且即使是在企业中某个项目也没办法做到一次设计就能成功吧.下文提到的瀑布模型的修改不也是写了再改模式吗?
写了再改对于写作业来说应该是足够的。在实际企业开发中，我觉得其实很多也是这样做的。除非是极其有经验的程序员才能在一开始的时候看到整个项目的全貌，提前考虑到性能问题，所以对于绝大多数人来说都是暴力解决所有问题。直到出现性能问题才去解决问题。这样做在效率上有一定保证，但是从长远来看，该模式有一定的坏处，可能项目未来需要大规模重构。
博客中提到的众多软件开发团队形式有本质区别吗?
在这篇博客中,提到了一窝蜂模式,主治医师模式,明星模式 ,社区模式 ,业余剧团模式,秘密团队,特工团队,交响乐团模式....感觉这些模式都是为了应对不同的团队成员的个性以及项目的难度来做的一个调整,没有本质性的区别.而在现实中团队是一定要按某个模式来开发吗?或者说大多数的团队其实是根本不需要模式这个概念的,只要处理好一些沟通上的问题就行?
本质上都是开发团队组织开发的方式。不同点在于不一样的人，不一样的项目导致了不同的方式。在团队作业中，也能看到不一样的组采用不同的组织方式，但是从结果来看，不同的组织方式带来的效率也是不一样的。
开发团队中需不需要"影评家"?
在这篇博客中,提到了一个影评家这样的角色,那么在开发团队内部需不需要一个一行代码都不敲的影评家?虽然他有一定的提供需求的作用,但是很招人烦.
不需要，在团队作业中也听说了一些故事，所以还是不需要吧。
开源项目的商业价值如何体现?
在这篇博客中读了以下内容
斯坦：那开源/共享软件是怎么一回事，如果开源了，商业价值如何体现？ 阿超：这个问题问得好，我估计如果开放讨论，以咱们的风格，三天三夜也讲不完。对这个问题还是蛮好奇的,以及为什么很多人要去追求创造开源社区?
开源项目做大的商业价值就是用户不需要花钱，能够获得很大的流量，带来变现，同时能够搞得竞品流量下降。如果能辅以各种手段留住用户，那效益会更高。
像Vue个人技术型的盈利应该完全靠赞助，官网流量应该是挺大的。
像uniapp企业级开源项目做了很多的相关生态，插件市场，后台管理，云打包等等。
像鸿蒙操作系统开源，希望更多的开发者能够使用，从中获利也是迟早的事。
现在软件工程理论在现实应用中具有多少操作性?
随着技术的进步,越来越多的开源工具出现,很多大型项目其实已经有很好的辅助工具帮助进行项目的管理,包括测试,代码分格的要求,文档的撰写等等.包括软件工业化,出现大量的模板程序或者是ui组件.使得很多项目不需要软件工程方法就能实现很好的管理.同时现在写代码的人越来越多,你想到的需求很可能已经有人实现了,而那些没有想到的需求可能也不需要很多行代码就能完成.那么其中的理论在现在能用到的有多少?虽然看到老师的博客罗列很多,但都感觉只是现象或者是经验,而不是一个系统的理论.
把理论应用到实践难度是非常大的，特别是像软件工程管理这样的管理学科。我在团队作业过程中虽然没有刻意去留意用了哪些东西，但是或多或少用到了软件工程的知识。需求分析，设计，管理，测试等。虽然现在有了很多用于管理，开发的工具和组件，但是人类的需求是无限的，这些东西不能满足所有人的需求，因此还是需要一些理论作为支撑。
知识点
需求
- NABCD
- 需求一方面要开发者去思考，同时也要深入了解用户的理念。
- 在需求分析阶段我们自己根据自身经验设计了很多刷题app相关功能，如：做题模式、题目推荐、快速做题、搜索、题目收藏、错题整理、题目笔记、题目评论等，同时发放了问卷调查，根据用户反馈删掉了排行榜，在线pk功能。因为我们认为我们主要争对考期的同学实现他们的需求，pk和排行榜对于只有考期使用的用户来说应该是不会用到的。
设计
- UI设计对后期的指导和功能完善意义极大
- 在团队作业中我主要负责前端开发，在UI设计时使用了以前从未用过的原型设计工具。UI设计是将需求与功能结合，把最终产品呈现出来的过程。在产品做出来之前，想好产品是什么样子，能够帮助我们思考哪些需求还不够完善。以及不得不思考是UI满足需求还是需求满足UI，可以说这是一个双向过程。特别是首页的UI设计，不断地思考完善才能够做出更好的产品。
- 以及在开发工程中，有些页面不知如何下手时，也可以参考前期的UI设计，能够提供灵感。
实现
- 实现阶段一定要保持沟通，否则会有跟不上进度的情况。
- 在实现阶段起初我只顾完成自己的部分，与团队的工作有些偏离，导致后来有些耽误团队工作。
测试
- 测试能够保证系统的安全性和稳健性。
- 做不到完备的测试那就准备好及时修锅。
- 在前端开发的过程中，以为自己已经尽可能地考虑了文本溢出导致ui混乱的情况，但是在评论中还是出现了文本过长没有换行地情况。这一方面在后期开发中也是下了很大的注意力，但是依然不敢保证没有问题。
发布
- 发布阶段一定要关注同类产品的宣发，提前抢占资源。
- 在beta版本发布的时候，突然杀出一个IOS竞品，这是万万没想到的。ios版本的产品抢先一步在学校的表白墙，朋友圈等地方发布，使得我们再去会有一些误解，使得我们的产品发布会受到一些影响。
维护
- 要积极的收集用户反馈，满足用户的需求。
感想
个人项目
阅读作业上回顾了与计算机结缘，在计算机学习，未来的打算。在这里读书是挺幸福的事，要考研了，可能以后没书读了，呜呜呜。
阅读作业2阅读过一些博客以后，读过感觉和没读一样，之前课程如数据库也都讲过这些东西了，没什么收获，然后提了一些莫名奇妙的问题。
案例分析作业 掌握了一些软件测试的方法,学会了对一个软件客观的进行评测.
不是很擅长写东西，所以个人作业完成的不是很好，不论是排版还是内容都需要很大的改善。
结对项目
结对项目我有幸于一位大佬结缘，在实现过程中，深刻体会到了结对编程的效率之高，两人沟通之下使得敲代码也不再那么无趣，在不知不觉中便完成了项目。从大佬身上也学到了一些优秀品质，大佬对代码风格的要求很严格，用java实现事件回调和事件回滚机制，使得设计更加合理。同时我们也使用了CICD进行单元测试部署，帮助我们保证项目的正确性。
团队项目
团队项目有幸结识了一群愿意做出优秀产品的队友，大家的目的就是把他当作一款产品去做。在需求分析阶段我们连续熬了好几天，拍视频，写文档。起初本来定的项目是做一款与考研相关的app，本来我们将用户锁定到学校内的考研同学，将学校也缩小到985，211，从而达到缩小需求的目的，我觉得这个项目是十分可做的，但是被课程组给否掉了。
后来比较幸运，我们能够选到航概这个最简单的课程组提供的项目去做。但是简单的项目做出花来并不容易，我们需要考虑如何创造出新的东西。起初设计的功能包括：四种刷题模式的支持，错题和收藏的支持，题库数据的支持，这些功能并没有办法填满首页的六个格子，且都是已有题库小程序实现的功能。我们想到了用日历来管理考期的时间、用知识卡片来帮助大家复习非选择题、用资源社区帮助大家分享资源、在结对项目中，我对gitlab的issue使用有了一个比较深刻的体验(不断地向课程组的问档提问)，我发现这是一种很好的提问解答模式，于是决定在我们的小程序中实现一个类似的功能，帮助大家解决某一门课程的问题。这些都是我们的创新点所在。而课程组在需求分析阶段不考虑这些东西，在第二次设计阶段才考虑，可以看到需求分析所做的那场汇报是一个很空泛的东西，没有设计，没有实物，只有空谈出来的需求，课程组只根据这个，进行项目的否定和通过我觉得是有大问题的。我主要负责前端，之前也有写过前端，但是技术都不够成熟，也没有做出来一个自己引以为傲的项目。所以我选这门课的目的就是完成一款比较优质的应用程序，如果不是一件有趣的事可能真的很难坚持下去。
除产品设计以外，开发时队友也是比较给力，我们采用两天一次线下集中开发，每次开发都花费六到八个小时，这样的开发时间确实能够很合理的平衡上课和软工课程的时间分配。除此以外，PM的宣发令人十分舒适，他的爆肝带动我们爆肝。自己的分可以扬了，队友的分不能扬。