【软件工程】提问回顾与个人总结

提问回顾

在学期伊始，我阅读邹欣老师的《构建之法》的时候提出了几个不太理解的问题，当时写下的博客链接如下：【软件工程】第1次个人作业

当年提出了如下几个问题：

• 问题1：re-work是否能够衡量代码的质量呢？

  这个问题我目前认为书中说的不无道理，re-work的多寡确实并不和最终的质量成正比，但re-work还是可以一定程度上反应工程质量的。正如博客中所认为的，在着手具体编码实现之前的设计，其目的就是为了减少甚至避免re-work，而如果re-work较多，则说明设计不够到位，也就说明之前的工程质量出了问题，我仍然坚持认为这个逻辑是没有错的。

• 问题2：函数中goto的使用？

  其实这个问题提出的原因是，书中说往往会使用goto函数来设置唯一出口，但老师告诉我们不要使用goto语句，或者说设置唯一出口的目的是什么呢？为了方便测试？还是什么呢？由于在团队中没有担任开发工作，所以这个问题目前我还没能得到能够令人信服的答案。

• 问题3：结对编程真的利大于弊？

  真的！真的！真的！结对编程可能是整个学期最有趣的部分了233333！对于两个比较熟悉的人而言，结对编程当真是快乐源泉，还能促进感情（滑稽.jpg）；哪怕是不太熟悉的人，经过快速地磨合，只要配合得当真的可以高效持续工作，这种感觉原理就好像是，如果一直匀速长跑，会让身体的疲劳感很强，但如果引入变速跑，比如快跑800然后慢跑200等等，会在保持心率和消耗能量的情况下大大缓解疲劳感，我猜测可能就是有了变化让人有了新鲜感。

• 问题4：懂技术的PM是否要参与开发？

  我们组的两个PM虽然称不上懂技术的PM，但也算是懂得如何编程、能够快速通过学习成为开发的PM。但经过了三个阶段的项目推进，我意识到在一个团队中，每个人都有自己的角色任务要完成，PM就好好做好设计，做好用户需求分析和项目推广的工作，按时监督项目推进进度就好，没有必要参与开发的。

• 问题5：优化该何去何从？

  好问题，事实是，在Alpha阶段这种紧锣密鼓的急速开发过程中，根本没时间想优化的问题，Beta和Gamma阶段才能回来想想优化。所以我认为，与其说提前考虑优化的问题，不如先设计好，让项目有充足的可扩展性，然后给后期的优化留下空间。

在项目的需求/设计/实现/测试/发布/维护阶段都学到了什么“知识点”？

• 需求阶段

  需求阶段首先我们是将自己代入到用户的立场上，考虑用户可能的需求，从而进行设计，但想要更有效地进行需求分析，最好在做好产品的大致需求分析后，找几位目标用户询问下他们的意见，往往他们会提出我们想不到的关注点。

• 设计阶段

  设计阶段的经验教训就是，一定要花足够多的时间在设计上，在设计的同时，也要充分考虑产品的可扩展性，否则就可能会出现，在后面的迭代过程中想要增加新的功能时，发现无法扩展，只能重构的情况。

• 实现阶段

  在实现过程中，前端与后端之间一定要积极交流，PM也要起到协助沟通的作用，出现问题了一定要抓紧解决，否则就可能会出现前端等待后端、后端等待前端，导致项目进度大大延后的局面出现。

• 测试阶段

  测试任务要随着开发一起进行，单元测试、回归测试都是必不可少的，同时，最好能对测试人员的测试质量进行检查，如我们组在Gamma阶段时，开发人员突然发现一个bug，而这个bug本应在Alpha阶段就被测试出来的。

• 发布阶段

  （发布阶段我实在想不出来什么知识点了……就按时发布、做好推广就好……）

• 维护阶段

  在项目推进的过程中，团队要维护好项目文档，一方面这也反映了项目的质量，另一方面如果以后有别的团队来接手我们的项目，详细的文档也可以帮助别的团队成员尽快熟悉我们的项目。

软工的心得体会

在团队项目的Alpha、Beta和Gamma阶段，我担任团队中的PM，和组内其他成员共同完成了VisualPytorch从0到1的转变，很辛苦也很荣幸。软件工程这门课给了我们每位同学一个机会，一个在学校内可以体验做一个完整工程的机会，这是不可多得的，也是别的学校可能体验不到的。在项目开发过程中，团队成员各司其职，也就可以真正感受到自己的责任是什么，而不是仅仅停留在理论层面的。然而不得不说，作为一门必修课程软件工程还是存在它的不足的，如：课上内容对团队项目的推进缺少必要的引导，总体一学期下来的感觉就是，自己完成了一个大作业，期间要写各种各样的博客来完成作业要求。不过，作为一门刚开设几年的课程，存在不足是难免的，也祝软件工程这门课程可以越办越好。