怕什么真理无穷
| 这个作业属于哪个课程 | 2021春软件工程实践|W班 (福州大学) |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 对整个软件工程实践过程进行总结，重新回答之前提出的问题。 |
| 其他参考文献 | 《构建之法》 |
课程回顾与总结
寒假作业二要求你在快速阅读《构建之法》后，列出仍然不懂的5到10个问题。现在的你对这些问题有什么新的看法吗？
问题链接
问题与重新解答
1.《构造之法》第四章 每人在各自独立设计、实现软件的过程中不免要犯这样那样的错误。在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。
以前的回答： 看过第四章的内容，结对编程他们通过交流会不会浪费本应该一次解决的问题，而且只使用一个键盘，他们每个人的效率往往会低于两个人分头行动，设置一个对于该项目两人都适应的文档，分开工作会不会更加具有效率？
在完成了结对作业与团队作业后，我才了解到这个片段的正确性，在完成项目的过程中，编程水平较高的程序员往往占据了交流的主导权，他提出的技术理论和实际编码往往都是最后所决定使用的方法，因为他们可能在前面的项目有使用到相关的技术会更有经验，也帮助了编程水平比较低的同学跨越了这一步。分头行动再整合的过程往往比两个人完成一份任务需要的时间多得多，在这次实践中因为交流过好或者需求定义不明去测试和寻找bug的世界花费确实要比一个人完成这份工作的时间要多很多。
2.《构造之法》第七章 MSF提倡自下而上的计划，每个人有充分的权力估计并决定自己的任务需要多长时间。
以前的回答：现实中这种情况太过理想，很难实现。通常都是自上而下的进行，那在被安排的时间过于紧凑时，如何更好地安排任务时间？（排除主观因素的情况）
在实际的情况里，我们只能大致估算自己完成整个项目所需要的时间，而不能很精准的计算我们的任务需要多少时间，一方面是不了解自己的任务在开始前是否有欠缺考虑的地方，是否有将这部分时间还有debug与测试加入你的任务时间。第二个是在分配任务的过程中，我在我们团队项目中担任PM，负责任务调度与项目管理。在这过程中，我发现往往在项目开发前设定的时间安排，我们基本都不会遵守，因为外界因素和内部因素，我们的时间是十分不准确的（大部分是时间比我们考虑得要多），有时候组员之间的交互也是无法让自己决定自己任务的开始时间与结束时间（加班debug与负责前一部分的同学还在完善）。这也证实了问题的观点，“自下而上”的计划确实是更好的选择（自上而下真滴很不准）。
3.《构造之法》第十一章 在软件开发中，如何应用建模方法？
以前的回答：书上只提出来软件开发时的模型，但是并没有提出如何在实际情况下建立一个符合现实的建筑模型。也没有具体提出在建模之后，如何进一步地完成任务，只是抽象地描述了建模时每个部分的作用，让软件开发时的我们无法开始下一步活动。能否对这个模型提出更具体的步骤？或是让这个模型变得更具体？
软件开发的过程中模型有很多，我们这次实践的前端主要还是在基于我们的原型模型来完成我们的UI设计。经过软件项目管理的学习，发现我们的团队项目也是一种模型，是敏捷模型中的scrum模型。在之前的回答中，我形成了一种思维定式，“只有能看到的模型是模型”，这种观点是错误的，而构建之法与软件工程课程中已经教会我们如何去应用已经定义过的模型，提供了详细的步骤，几乎所有类型的软件开发中都会有相关的模型来建立。如何应用就是在遵循模型定义的过程，在可以自由操作的部分按部就班地履行每人的义务就是如何应用建模方法的正确定义 。
4.《构造之法》第十六章 其实，大部分成功的创新者都不是先行者，例如搜索引擎，Google是很晚才进入这个领域的。
以前的回答： 我认为创新者绝对是能在他创新领域里最占优势的一个，他在绝大多数可能下会成为成功者。而那些例如谷歌的后来者，他们很有可能一部分的人是来源于创新者的，并且他们的平台资源更优秀才导致他们在这个领域里更加成功。
我考虑到另一方面的问题。因为我们的团队项目是游戏，我也有去研究过市面上的一些相关游戏，一类型的游戏是大同小异的，玩法也是相差无几，除了美工在努力carry留下一批心水这款模型或者认为使用的观感优秀留下的玩家，大部分的玩家不会因为你是第一款这样的游戏就给你贡献流量，而且第一款游戏往往是考虑不周到的，但是你还要为了留下原本的那批玩家，不能大肆删改最初的游戏模式与样式，大规模的更新版本是一次非常冒险的行为，不是作死就是涅槃，小型游戏公司往往不敢做出这样大胆的举动，必定是要靠着这款还算能赚钱的游戏吃饭，所以最成功的往往是那个最贴合当时主流的游戏。
5.《构造之法》第十六章 以发明即时贴（Post-It）闻名世界的3M公司的杰弗里·尼科尔森（Geoffrey Nicholson）对两者做了明确的区分，他认为“科研是将金钱转换为知识的过程”，而“创新则是将知识转换为金钱的过程”。
以前的回答：网上对科研的定义为：科学研究（Scientific research），一般是指利用科研手段和装备，为了认识客观事物的内在本质和运动规律而进行的调查研究、实验、试制等一系列的活动，为创造发明新产品和新技术提供理论依据。科学研究的基本任务就是探索、认识未知。 它并没有指明与金钱的关系。那科研一定是需要金钱来支撑的嘛？是否有能够不需要金钱完成的科研成果？而创新是否一定是知识转换为金钱？是否有可能是知识转化成另一种知识？
上面的问题有些杠精因素在里面，其实究其根本，最后演化出来的还是杰弗里·尼科尔森所说的那样，只能说是广义定义而已。
做中学
五个阶段的学习
需求阶段
需求分析是我们在实现项目中的第一个部分，“好的开始是成功的一半”，这部分我们项目做得自认为还不错，我在这里面做的工作是PM，是结合组员想法完成我们这部分任务的引导者，因为我们在第一次会议就大致决定了我们需要完成的功能，后面的过程就十分顺利，难点可能是在宣讲部分，跟其他组宣讲者比，我确实有点拉。
设计阶段
选择游戏方面从这部分需要考虑的地方就应该要比较全面了，系统设计与数据库设计都应该是需要仔细考虑的部分。可惜在第一次经验不足，完成地不是很充分，各个方面都没有考虑全面，比较大的收获可能是各个图的制作了。
实现阶段
因为在这个部分，自己担任的是pm，所以在开发部分没有太多的提升，最重要的是每日的会议记录与平时的团队管理与项目跟进。与开发人员的交流，沟通进度，保证项目的正常进行。
测试阶段
主要负责了接口测试与性能测试，这些测试可以发现我们在代码中的纰漏，就是profits的操作有点裂开，对unity测试好像不大行，只能测试其他的部分了。软件质量测试里的jmeter也用不了，（本来以为可以用这个的）。
发布阶段
发布阶段是当成一个用户来进行黑盒测试，发现了很多的问题，这是在测试中没有发现的，需要再继续更改的，因为发布时快要截止了，整个人处于裂开状态，还好兄弟们给力。及时发现并解决了问题，才让我们的项目正常运作。
项目总结
个人项目
个人项目是熟悉编码的一个过程，难度不是很高，但是用来熟悉编码是不错的选择，一些细节的处理也让我学到了很多知识，大神的博客的一些处理方式也给人很多启发。github的使用也是从这里开始的，当时在家里那个网络卡的离谱，上传卡的离谱，整得差点昏过去。（git不大会，全靠desktop来carry）
结对编程
结对编程里去写前端是一个痛苦的过程，各种奇奇怪怪的功能让我在代码里加了不少插件，一开始不知道从何下手，只能说自学一个框架是一个痛苦的过程，部署服务器的时候只能说队友牛逼，我躺好了。
团队项目
和兄弟们原生开发游戏果然是一个艰难的过程，每天都在提心吊胆会不会出现什么新的问题，真的很心塞。兄弟们很努力，能够完成这种程度，已经达到了自己的心里预期，但是没有完成到最好，有点可惜。最后几天真的是在边测试边修改，稍有不慎直接gg。希望以后自己的管理能力再提高提高，制作ppt的能力再提高提高，carrycarry兄弟们。
个人技术总结
我在团队项目里担任pm，好像没有多少开发工作。那就说一下结对作业使用的bootstrap吧
