猫猫警察的个喵总结
| 这个作业属于哪个课程 | 2021春软件工程实践W班 |
|---|---|
| 这个作业要求在哪里 | 作业要求 |
| 这个作业的目标 | 软件工程实践总结&个人技术博客 |
| 其他参考文献 | 无 |
课程回顾与总结
问题链接
解答
问题一
《5.3.5老板驱动流程》中提到：“领导对许多技术细节是外行，领导未必懂的软件项目的管理，领导的权威影响了自由的交流和创造”，但并没有说当问题或者分歧出现时要怎么解决。我在知乎搜索关于福州某知名游戏公司的工作待遇时看到，多数回答都在抱怨该公司官僚主义盛行，而且有些领导都是靠资历混上来的，本身没什么技术，有些产品也没什么实际意义。那么作为快实习的大学生，以后工作如果遇到类似的公司，面对分歧时要怎么和领导交流？领导权力大，可以找各种理由克扣工资，这时候是为了钱附和领导，还是为了做一个好产品或者让自己学到更多而跟领导提意见？若二者都想兼得，要如何与老板沟通呢？有没有比较好的建议呢？
在知乎搜索后了解到，初出茅庐的职场新人应当把重心放在自我学习上，项目走向、产品走向由领导决定，自己负责服从就行了。有时候有些决定虽然看着不太合理，但是背后会有很多弯弯绕绕，职场新人一般是不了解的。如果是有一定工作年限的职场老人，一开始可以试着和领导沟通。如果沟通无果，自己难以接受这种产品走向，但又很需要这份工作，不如放弃和领导起争执，在下班后提升自己，争取跳槽到更好的、更适合自己的公司。一般来说鱼和熊掌难以兼得，如果真的想和领导提建议，最好用比较委婉、不得罪人的说话方式。如果掌握不了这种话术，最好的方法就是闭嘴。
问题二
《6.3敏捷团队》中提到：“敏捷对团队的要求很简单：自主管理、自我组织、多功能型”。现在很多人都提倡敏捷开发，但是人都是有惰性的，就我本身与同学合作完成一个任务的情况来看，大家都喜欢做简单、轻松的部分。当轻松的活儿都被挑走时，剩下的不得不做较复杂工作的同学们心中都不乐意，容易引起团队矛盾。在敏捷开发的过程中，万一小组成员在认领任务时，只选择一些轻松的任务，把复杂的任务留给别人时，要如何处理呢？若有的成员认领任务前以为自己能完成，实际上手后发现有些知识或技术实在不擅长甚至无法处理，以至于工作落后需要别的成员帮助改进，那么别的成员难免有怨气，这时作为领导或者负责人要如何调节安抚成员呢？从前各有各的分工，如今一个人要全面负责：写规格说明书、与人沟通、开发、测试……，这些都需要另外花时间去学习对应的方法和技术，这对一个人来说是否负担较重，降低了开发效率？拿我自己举例，在本次程序设计中，我本人既要开发也要测试，还要写博客说明，而且在开发---->测试---->修改这一过程中经历了3次以上，感觉负担较重。若此时有人负责测试，有人负责写博客说明，那我觉得我的的开发效率会更高，因为这样我就能专注与问题的解决，而不用忙于写测试案例试图自己否定自己写的代码。
通过整个软件工程实践经历来看，对队长来说最重要的是选择成员，在组建团队时就应当考虑到未来成员的工作积极度；对成员来说，最重要的是选择团队，选择一个氛围融洽，工作有序的团队。如果不小心误入了一个不太积极的团队，就只能自己积极领取力所能及的任务，用自己的积极态度影响别人。最重要的任务还是保证自己的任务能够按时、高质量的完成。作为队长，筛选成员后，出现无人认领的任务时，除了要根据成员特性分配外，还要主动顶上。如果在完成过程中发现困难，应该叫任务较简单的同学帮忙。同时在队内实行打分制，分高的成员给与奖励，借此调动大家的积极性。队内中任何一个成员出现困难时，只要是任务已经完成的成员就应当主动去帮助有困难的成员。如果涉及技术方面，队友无法帮忙时，就要寻求老师或者这方面资深人士的帮忙，善用百度、Google等搜索引擎。任务先完成的成员应主动观察、询问是否其他成员有需要帮忙的地方，或者主动去参与文档的编写。
问题三
从《4.5 结对编程》中可以看出作者十分推崇结对编程，参与结对编程的双方应当只有水平差距，但编程过程中必然有主（驾驶员）次（领航员）之分，若在双方水平一样的情况下，要如何合理安排任务分配（即主次顺序)呢？现在我有了自己的看法，在任务开始前就要列个List来分清双方自己负责的任务，当双方都觉得这个List上的方案可行时，才能开始工作。在工作过程中绝对不在任务以外的范围干涉对方的行动，有任务以外的问题都等到“驾驶员”完成这部分的内容后再讨论。那么现在我又有了新的问题：若双方在编程时出现分歧，而且各自的说法都有道理，这是该如何协调呢？举个例子，假设我和WY同学结对编程做这次的程序设计，要处理一个有关在内存中以什么形式保存文本内容的问题。WY同学坚持将文本内容读取后全部存放在一个字符串中，然后直接用正则表达式提取文本内的单词；而我坚持每次只保存一个字符，然后马上跟上一系列较为复杂的分支逻辑判断来统计单词。WY同学的代码的运行时间比我短许多，但是面对400MB的样本就会出现爆内存无法运行的问题；我的代码运行时间比WY同学长许多，但是同样的400MB的样本用我的代码仍然能跑。可以说我们俩的做法都有各自的道理，那么此时，应该选择什么方法呢？或者如何协调这种分歧？
在分歧无法解决的时候，应当以用户需求为主，谁的做法更贴近用户需求，就用谁的方法。如果用户给出的文档都是几十MB的文档，那毫无疑问选择WY同学的做法；如果用户给的文档大小普遍偏大，就采用我的做法。后来看到助教提供的文档不超多几十MB，这时候选用WY同学的做法较好。
问题四
《8.1软件需求》中详细介绍了获取用户需求的步骤：获取和引导需求---->分析和定义需求---->验证需求---->在软件产品的生命周期中管理需求。但我认为再科学的步骤都抵不过甲方爸爸自己推翻了以前确认过的需求。若此时项目已经进展到后期，该怎么处理这个问题呢？要推翻重做吗？若是推翻重做会耗费人力、物力、财力，损失谁来承担；若不重做，该软件已经不再符合用户的需求，这个软件就没有意义了。在初期和甲方沟通的时候，若甲方是个想到什么就一定要做什么的人，思维天马行空，常常在项目已经有一些进展的时候就变更需求，而且要求开发人员一定要满足否则不付钱，这时项目负责人要如何决策呢？
如果是在讨论是否做这个项目阶段就发现这个问题的话，我个人觉得就两种办法：一，和这样的甲方say bye bye；二，和甲方签订好协议，如果是因为甲方修改需求导致项目无法进行或返工的情况，甲方负全责。这个问题如果出现在项目中期的话，我个人觉得很难有特别好的解决办法。因为没有事先签订协议保护项目工作者，甲方完全可以耍无赖让乙方负全责。如果甲方好沟通，那事情还有回旋的余地；如果甲方很难说话，那事情就大条了。
问题五
《13.2各种测试方法》中介绍了很多测试方法，其中开发人员使用最多的应该是单元测试。那么开发人员应当耗费多少时间在单元测试上比较合理呢？是只要正确运行一个具有普遍性的样例，不出错误就可以继续开发下一个部分，剩下的测试全部交给测试人员来做？还是要自己编写各种特殊的样例来定位bug，确保所有结果都正确才开始进行下一步的开发呢？如果是前者，有可能会面临多次返工的情况；如果是后者，开发人员的负担就变得很大，岂不是影响开发效率？如果是自己一个人独立完成一个project，那自然是后者，但程序猿一般都是团队工作，这时候如何把控自己花在单元测试上的时间？
通过这次软工实践，我个人觉得开发人员在写单元测试时，应当选用几个普遍样例和几个特殊样例来测试，能保持程序在较普遍范围能够运行就行，至于测试所有特殊样例的工作应当交给测试人员来做。团队开发时任务都有时限，在时间来不及的情况下我个人认为测试几个普遍样例就行。
阶段收获
需求
决定项目主题后，应当发调查问卷给目标群体，了解他们的需求和使用意愿。在设计调查问卷的过程中，我发现如果一份问卷的问题超过7题时，填写人数就会减少，而且填写质量也会降低。在填写别组同学发的调查问卷时，有些小组设计的问题太多，以至于我看到问题列表时就不想填写了。询问了组内的其他同学，他们也有一样的感觉。在设计问卷时，我就提出了这个现象，因此我们组的问卷题目数量一般把握在5-10题以内。
设计
数据库表设计很重要，好的表结构可以提高增删改查的效率，以及正确性。但是在合作中最重要的一点，就是表名、列名一定要对接清楚，不能有“我记得是这个名字”的态度。我们组在beta阶段的一个bug就是因为两名同学同一列的列名输入不一致而造成的，这个bug还找了挺久的。
实现
这个阶段遇到的困难主要是技术方面，要学会面向百度编程，要有自主解决问题的能力。特别是当整个团队中只有我一个人负责python端编程时，碰到问题在队内基本无法解决，这时候自我解决能力就非常重要了。百度解决不了就找Google，CSDN解决不了就找Stack Overflow，实在看不懂还有网页翻译，能用的网站都要用上。
测试
完成python端的开发和部署后，要测试代码在服务器上是否能正确运行。此时服务器代码和本地代码一般来说是相同的。但是有时候本地代码可以跑，且有结果；而服务器代码没有跑出结果，但也没报错。这个问题非常玄学，服务器环境是不太了解的CentOS，给调试带来了极大困难【微笑】。后来折腾了两天，发现是使用supervisor将程序挂后台的配置文件有点问题【微笑】，最后改用screen命令就没事了。
发布
有一台视频推送服务器推流配置有问题，凡是这台服务器传来的视频都无法播放，偶尔会造成opencv无法切帧【对就是“偶尔”，很神奇，有的时候能切帧】。这个问题会导致python端服务器程序停止运行，就算我加了异常处理也没用【对就这么离谱】。最后配置推流服务器的同学，重新改了配置解决了这个问题。这个问题告诉我们，有的时候运行有问题，不一定是我们的问题，可能是别人的问题，要对自己写的代码有自信。
心得
个人项目
事实证明想太多不是好事，最初版的代码跑助教的测试样例没有任何问题。然鹅在我考虑万一以后改需求，用户给的文档在几百MB以上后，我修改了程序【万恶的思考】。然后我又考虑到要提高统计效率，我又修改了程序【微笑】。我成功的让自己的程序出了点小差错，以至于有一个样例没跑过【微笑】。
结对编程
如果是前端，你就找个后端；如果是后端，你就找个前端。当你的队友出问题时，你只能前后端都搞【微笑】，要有极强的抗压能力。U1S1，WY的CSS模板和js图表做的确实可以。
团队项目
事实证明有个优秀的团队非常重要，组长相当给力，队友也很积极工作。感谢大家考虑到我辅修，让我任务完成之后就当个闲人了。一个团队要有有组织力的组长、能获取大量情报的情报员、有一双慧眼的网络警察，还要有一堆积极参与的搞事者。为发际线打call，发际线yyds。【有些同学抄袭被倒扣分数；有些同学作弊却只是分数清0，而且还不诚心道歉。虽然很玄学，不过读书人的事情能叫作弊吗？班级间充满了快乐的气息】
个人技术总结
CentOS8服务器之python程序后台常驻
主要解决python程序部署到CentOS8之后怎么进行后台常驻的问题。团队项目时需要将自己的python代码放在服务器上跑，并且保证持续运行，不然小程序端和后台Web端无法获取数据并显示图表。建议使用screen命令而不是supervisor，screen命令较简单且有效，而supervisor配置比较麻烦，有时程序仍然会自动停止。
