多省前行
| 这个作业属于哪个课程 | <福州大学2021春软件工程实践S班> |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 软件工程总结和个人技术 |
| 其他文献参考 | 无 |
课程回顾与总结
问题回顾
-
re-work表示软件质量，用了一个例子是艺术家涂改作画的例子
-
问题引用
思考：我完全同意书中说的re-work并不能代表代码的质量。但是后面说到在一个很简单的代码上花费很多时间re-work我是存有疑惑的。艺术家经过很多遍的涂涂改改出来的一幅作品我认为是一件很好的事，因为每一次更改都代表着对上一次的否定。我认为小的代码的re-work也是必要的，不应该否定他的价值
-
当时只是单纯的觉得艺术家涂改作画可能有修改变好的情况，但实际上re-work实际上也存在着有效re-work和无效re-work，对于在一个简单代码上的re-work，不论怎样他都是一个简单代码，不会影响代码效率。而当时书中引用的是简单代码修改用艺术家涂改作画做例子我仍然觉得是个不恰当的例子。因为艺术家改自己的作品可以称之为雕琢，不良修改，但是简单代码的re-work就是很明显的可以变得更好但是没必要，甚至有可能更加耗时。虽然还没有想好更好的例子，但是还是不喜欢书中的例子。
-
-
流水例会
-
问题引用
思考:流水例会的确是一件可耻的行为，但却让我想到了流水例会产生的原因，无非就是无事可做的时候例会还要照常召开。在团队当中的确有这样的事情发生，无事可做，每天例会，那我们要用怎样的心情去对待。其次就是我看到冲刺阶段每次报告都要一个完整的图标之类的汇总，这些图表制作不需要时间的支撑吗？如何协调时间不足的情况下还仍然要做有效的报告呢
-
这次α，β冲刺的冲刺日报就是最有可能产生的流水例会的。当时提出这个问题的时候，想法是做了很多无用的东西似乎没有什么用。经过了αβ冲刺，虽然感觉每天都要写一大堆有的没的的东西，但是开会确实是有必要的。于其纠结于要不要开会，不如想怎么把开会变得有效。如果大家可以把自己的问题拿出来，让大家来解决，这样就会减少很多开发耗费的不必要的时间，因为确实坑就是那么几个，有人踩过都填平了，没必要再去找个坑跳进去，直接走对方的路就好了，可以节省开发时间。会议是有必要的，但是流水会议确实是可以避免的，会议主持人和开发者只需要花几分钟的时间思考一下自己会议需要的内容，就可以避免开发过程重复踩坑的现象，也可以很快解决会议。
-
-
几个案例
-
问题引用
思考:不论是飞机上的阅读灯，紧急跳舱，亦或是静音是否需要关闭闹钟，都存在有两面性。想要按钮统一，又想要避免按错，有时想要不关闹钟，有时又想要把闹钟开启。功能的需求总时有两面性，且多少还无法衡量，有的时候照顾了用户的需求反而加重了自己的程序员的负担
-
确实这方面是很难权衡的问题，所以在开发前的调研，分析，设计就显得尤为重要。到底要哪些要贴近用户需求，哪些要让用户去尽量适应产品，这些都是要考虑到的内容。一个产品在开发前只有先提前明确这些需求，才能有目标的开发。
-
-
IT行业的创新，成功的团队更能创新
-
问题引用
思考:我不记得在哪里看过这样的话，说，有一段时间掀起了青年创业的高潮，很多年轻人纷纷涌入创业，但最后有的平步青云，有的锒铛入狱。成功的团队更能创新，因为能力已经有很好的基础，所以可以创新。但是对于那些能力基础还不存在的，是否要冒着风险去创新呢，同时，创新究竟意味着什么，是前所未有还是优化改良。
-
有多大能力才能做多大事，如果不能很好的做好市场评估，或者调研，那么从创业团队变得一穷二白是很容易发生的事情。就我现在来看，创新的点子烂尾的事情还是存在的，所以点子是否会烂尾，一定要做好评估，不然会一发不可收拾。
-
-
有关猪，鸡，鹦鹉的故事
-
问题引用
思考:这个故事其实还蛮有意思的，但是后续的描述的确道出现实，也不免让我惊讶。猪在故事里就是要奉献一切的那一种，而鸡就是可以贡献但不是全部，鹦鹉是语言上的掌管者，交际圈。我个人觉得我和鹦鹉很像，但故事有一个问题就是没有给出结果的衡量。猪的确是奉献一切了，但是猪的回报是多少，高回报的确值得这么做。但是事实生活中的确也有人奉献了一切，牺牲了家人，朋友(这边不是说Jolin)，但是可能他们的贡献还没有一些鹦鹉或者鸡随便一下贡献大，他们真的不值得用自己获得的白菜的钱，操着卖白玉的心吗
-
现在结束了α，β冲刺，对这个故事的理解更是感同身受。当时我只看了自己语言上的掌控着，交际圈就认为自己是鹦鹉，但实际上我就是一只🐔，因为就我的成绩而言，只需要这门课通过就可以，会投入自己，但是没有更想要的内容。相比之下团队之下的很多组员都是猪的角色，他们在保研名单中，所以他们需要努力去做。这次身为开发团队的产品经理，对于每一个组员的开发进度我都看在眼里，所以说，猪真的有必要去努力，因为他们要的和鸡和鹦鹉都不一样，只有努力了才有机会把分数拉高。只不过猪的获得不是白菜，而是得到隐藏的宝藏，而且只有猪能够找到，他们为了宝藏去努力，是完全值得的，因为目标不一样。
-
阶段收获
-
能力获取
每个阶段获取的能力都是一样的，所以这边就概括啦
-
语言组织，表达能力：真的我没想到自己的语言组织能力可以得到很大的上涨。尤其是在最近跟别的老师的事件交谈的过程当中，更加有所体会。得益于这次博客园的主要掌管者，ppt展示，还有项目经理的工作。
-
人际关系处理能力：有的时候真的不想逼大家做事情，但是不得不那么做，因为这是自己的工作，工作之外大家可以玩的很好，但是在工作上，必须要把自己的事情做好。可以通融一下人性，但是一定要把自己应尽的指责做到。
-
抗压能力：遇到过很多让我很气恼地事情（这边还是悄咪咪的不说啦），但是，在刚开始的时候会直接火冒三丈，直接气到头晕，因为我本来就是个不饶人的，一定不能让自己吃亏。但是后面逐渐掌握了如何让大家都感到舒服，不是对抗，而是接纳，哪怕自己做不到，尽量去做，也比对抗来的好。
-
-
知识获取
- 需求
- 产品经理应该如何做。之前还专门研读了一下实验室那边一个产品经理的书本，害怕自己做不好。需要做到调研，拉取进度等。后面发现这些东西都融入到了详细的作业安排当中，所以本质上产品经理应该做的已经在前期调研的工作当中，按照团队为单位做好了
- 设计
- 功能设计合理性。原本打算做到很多级别评论，但是鉴于到自身的开发难度以及功能是否需求，就需要选择舍去，最后只做到二级评论。
- 实现
- 小程序开发。以前一直都想学小程序，但是一直晾着没有学，所以这次小程序开发前期就很快的把教程学的差不多了。具体的内容会在技术博客当中呈现
- github仓库使用。真的网太糟糕了，而且前期都是用的黑窗口搞得git，真的是很难受。不过gitee听说可以支持微信小程序，有机会还是蛮想试试的，毕竟比较符合国内生态。
- 测试
- 问题总结。由于小程序前端代码没有对于测试阶段的要求，所以这次的测试就由开发量较小的我进行黑盒测试。每一个功能要实现成什么，相差什么，都详细细致的告诉了相关开发人员。虽然在后续的调研时还存在有小小的问题，但是确实已经做到了问题概括归纳
- 发布
- 版本号控制。发布时，由于只有开发版，但是每一次开发版本的提交上传都需要做对其的描述说明。对于每一次进行的修改提交，大更小更改的把握都体现在了版本号控制上。
- 需求
理解心得
感觉到了这个课程很想让大家体会一把项目开发的完整过程。但是真的感觉战线拉得很长，有些作业时间安排真的很长，有些却很长，不免会让人难受。不过这次整体的开发确实给了我很深刻的印象，从个人作业火急火燎的做，到听说要开发项目的兴致勃勃，再到团队一起开发的前期准备，中期准备，后期准备。我觉得我实际上学到的东西就是在团队开发那里了，前面的个人作业讲真的真的没有学到什么，倒是让我一直很紧张。团队开发那边确实了解到了很多东西，知道了开发真的不是只有开发这么简单，还有别的内容。开发的后期由于设计数据库的不合理，也体会到了一把难受，所以设计好真的很重要。和大家一起相处真的很开心，而且也没有出现长时间不理产品经理的问题，真的是个很好的团队。不过还是有很多不足，只能放到以后再继续努力啦。
