提问回顾与个人总结
一、问题链接
https://www.cnblogs.com/535812068wh/p/10469144.html
二、问题解答
-
单元测试之所以需要编写代码的人写，是因为可以省去测试人员重新阅读代码的麻烦，原先提到的可能会因为个人的思维局限而导致无法达到好的效果的问题并不存在。
-
在这次的软件工程项目中，我并没有使用goto函数，但react-native自带的周期函数（如render，componentWillUpdate）可以让我对goto有一定的了解。参数的变化会导致一些函数的自动触发，如果这些函数再次修改参数则会造成死循环，为了避免这种问题，需要对各个函数进行严格的周期控制。
-
代码复审和单元测试的区别在于，代码复审可以确定代码在规定的框架内部解决了问题，它所花费的时间长，且更直接。而单元测试只需要给出对应的样例即可达到类似的效果。
-
考级问题并没有在此次软件工程中展现出来，但一个软件工程所涉及的知识点以及技术是很广泛的，如果通过考证的方式来满足自己对各个知识点的需求也是不错的。
-
领导力在我们这次的软件工程中十分重要，在三年的学习过程中，我从没有哪一次像这次一样了解到它的好处，一个负责任的PM和一个纪律性强的团队确实会让开发过程事半功倍。相反，一个只讲究浑水摸鱼的团队则会让大家的积极性下降，并且导致最终的成果不理想。
-
用户体验中，我们并没有涉及到广告问题，但我们也确实为用户体验而费了很多心。在我们软件开发的过程当中，我们发现除了满足用户对功能的需求之外，更重要的是满足用户体验。比如说我们的产品经常被诟病太丑了，或者是说我们的设计风格不够现代化，导致用户不愿意使用我们的产品。为此我们团队花费了很多功夫，借鉴了几个比较主流的软件的开发风格，最终不仅美化了效果，更让许多细节变得更精致。
-
创新问题是针对学校授课方面的，我一直认为学校的教学方式不够现代化，每次都是从底层学起，繁琐且无用。但事实上了解底层知识对我们今后的学习有很大帮助（各个方面都有帮助）。此外，我们这次的软件开发是真的让我第一次了解到将知识运用到产品的困难，也算是与“现代”接轨了。
三、仍然疑惑的地方 & 新的疑惑
老实说，原先的问题基本上都有了一定的了解，但是我对这门课程又有了些新的疑惑。比如说，我不知道转会环节的实际作用在哪，因为我们需要照顾到每一个组员的感受，而小组中又缺乏一个有此全力的人。所以想要完美的解决转会问题基本上是不可能的，这也对大家的开发积极性产生了影响。我明白老师的教学是想让我们实际体验软件开发涉及到的方方面面的问题，比如说例会，比如说发布，但转会这个问题真的有点严峻，它并不像其他问题那么好解决（尤其是团队氛围很好的情况下）。
四、知识点
-
在需求方面，我们最开始天真的以为自己可以实现自己想要实现的所有功能，结果在查阅开发API之后才发现有些设想的功能根本没法实现。这也导致我们最初发布的需求问卷直接作废。在这个过程中我了解到需要先搞清楚自己能实现的功能再去发布需求问卷之类的。
-
在设计方面，我们最初并没有想过太多的设计，只是给功能画了一个大纲图，每个开发人员去实现其中一个章节的功能。然而，尽管在功能上面大家相互独立，但产品整体是要求很强的连贯性的，比方说，产品中的button或者输入框都需要达成一致的效果，但由于大家各成一派，最后还花了很久的时间对这些设计进行归一化。这在我们gamma阶段的开发得到了改善，我们先设计再开发，避免了后期繁杂的修改。
-
在实现方面，由于之前没有用react-native开发的经验，我们学习了很多的新知识。以往我都会去搜索各式各样的博客来解决开发阶段遇到的问题，但是这次却没有办法，因为react-native中的许多问题并没有被博客记录解答，我只好去Git上面查找对应的issue然后自己解决问题，这也是一个很不同的经历。
-
在测试方面，由于我是开发人员，因此我负责的测试主要是单元测试。早在大二我就学过了单元测试，但在实际运用中还是有点力不从心，想要全部考虑到开发过程中涉及的种种分支并不容易。好在我们几个开发人员讨论过后找到了解决单元测试的方法。
-
在发布方面，我们的产品由于是个APP，所以需要投放到各种应用市场，但大型的应用市场对于APP的审核要求十分严格，在我们去了解这个问题之后就发现没有时间来解决这个问题了。没有太早的接触让我们没有处理好这部分的发布。此外，我们的APP还在博客园官方网站上得到了宣传，这也让我们的宣发得到了很大的收益。在发布的时候需要了解用户分布在哪些地方、哪些年龄段，从而做到精准投放，来使收益最大化。
-
在维护方面，我们的产品曾在发布之后遇到了crash的情况，也正是那次，我第一次体会到了明明下班却突然要加班的痛苦。维护是需要考虑到多方面的问题，它与测试息息相关，一个好的测试可以让维护的负担变轻，但没有测试可以考虑到所有问题，因此维护是必要的。在我们的开发过程中，就因为没有考虑到“用户没有加入过班级”这个问题所以才会有了crash的情况，这也是我们需要反思的。
五、心得
在结对编程中，由于我跟队友的习惯不同，我们的结对编程进展的并不顺利，这也让我们的产品最终表现并不好。当时由于没有很快的进入状态导致了这个问题，在之后的团队编程就没有这些琐碎的事情了。
在团队编程中，由于我需要在课上发言并且在课下组织开会，所以每天要考虑的任务很多，并且很冗杂。PM并不是简单的文书工作，他需要考虑的问题是方方面面的。如果要说我的收获，我觉得最多的就是那种不得不做的情况下如何调整心态。有些团队选择了放弃，在alpha阶段之后有好几个队伍直接原地解散了！有些队伍选择睁一只眼闭一只眼，团队中干活的干活，划水的划水。而我们团队尽管在一开始的开发积极性很高，但之后漫长的开发时间还是让我们感受到了很大的疲惫，到了最后阶段的任务基本上谁都不想干活了。作为PM，这个时候要去给队友灌鸡汤，要自己去承担更多的责任，所以那段时间对我个人而言还是很痛苦的，基本上什么都是我在干，不过还好都过去了。
