提问回顾与个人总结
提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 在结对项目和多人团队项目中，更加系统地学习软件开发，培养工程化的思维 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾本学期课程经历以及自己对课程的感悟 |
| 个人博客 | 提问博客连接 |
问题解答与分析
Q1: 单元测试应该由谁来写？程序作者还是其他人？
关于单元测试的问题，本身就得回归到实践中才能得到结果。自己在结对编程的时候参与到了单元测试，而在团队项目的时候也尝试部署前端页面的单元测试，但是后者难度较大，以及学习成本较高便没有继续尝试。最终对于自己当时的疑问也有了比较明确的回答，单元测试还是得熟悉代码的人去测试。
这里还是引用书上的观点
单元测试必须由最熟悉代码的人（程序的作者）来写：
代码的作者最了解代码的目的、特点和实现的局限性。所以，单元测试没有比作者更合适的人选了
在尝试单元测试过后，自己也清楚，为了更全面的覆盖代码测试，首先就是得要对代码足够的熟悉，一个不太熟悉的代码从理解上需要一定精力，此外还需要对代码构思清晰，代码侧重点在哪儿都需要足够熟悉。这一点在自己结对编程的时候便有体会，自己在编写代码上贡献较少，于是大部分精力放在了单元测试上，这个时候即使是对结对编程所编写的代码有所了解，但对细节的理解还是不如作者本身清晰，也花费了颇多精力，所以自己也肯定了这个问题的答案。
回到当时自己疑问的点上，自己当时比较关心的是程序作者可能对需求定位不是非常清晰，这一点也在自己团队项目中得到了解答。一个项目进行需求分析的时候，往往是一个团队都进行参与的，所以一个良好的代码编写者，对需求的理解也是相当清晰的，也就没了当时的疑问。
Q2: PM（产品经理）的定位问题
自己不是产品经理，所以对该问题的理解可能还是存在一定偏差，但是感谢我们的PM@QSY。在他的身上我也看到了一个合格的产品经理所应具备的能力:
带领团队形成团队的目标/远景, 把抽象的目标转化为可执行的, 具体的, 优美的设计。
管理软件的具体功能的生命周期 (需求/设想/设计/实现/测试/修改/发布/升级/迁移/淘汰)。
代表客户和用户的利益, 主动收集用户反馈, 预期用户新的需求。 协调并决定各种需求的优先级。
收集团队项目管理和软件工程的各种数据, 客观地分析项目实施过程中的优缺点, 推动项目成员持续改进, 从而提振士气。
这里摘取了当时所列举了几个产品经理所该做的工作，而这几个工作也是在团队项目中我们PM所体现的较为闪光的地方以及我认为产品经理所应突出的地方。首先，就是产品经理是团队的主心骨，其对项目的态度影响了整个团队对项目的态度，也正是PM认真负责的态度，使得我们整个删库跑路对不队上下齐心，完成了超过2w行的项目。另外对于项目进度的把握和人员任务的合理分配，也是PM所应有的能力，项目开发周期应根据需求和参与人员的能力进行裁定，任务的分配更是得根据人员的能力裁定，这里我们就得到很好的分工。最后，PM也是作为与客户交流的一个重要环节，代表着客户与用户的利益，积极收集用户的反馈，并根据反馈，指定合理的新需求，这一点我们PM也做的很到位。
Q3: 结对编程具体实施产生的问题
当时所疑问的点在于如何去确定结对编程的具体实施才能发挥每个人所长的同时考虑效率？这一点在进行结对编程前，自己可能太纠结于"一起"这个概念了，认为"一起"就是两个人做重复的工作，从而降低了编程的效率，在自己参与到结对编程当中时，我才发现，这种一起，不是对工作的重复，而是对类似前后端独立编程那种做法的另一方面，一个人的代码编写完成之后由另外一个人复审，这一过程就保障了整体代码的正确性。此外：
驾驶员和领航员不断轮换角色，不要连续工作超过一个小时，每工作一小时休息15分钟。领航员要控制时间。
不得不承认，当时进行结对编程的时候，编写强度确实有点高，如果让某一个长时间高度精神集中，那么会降低效率和准确性。
但是，以上的分析只是解决了自己对于"一起"的疑问，而本次的结对编程更是在应对作业来看，使得整体对二人能力最大化发挥感受不是特别明显。自己对于如何发挥自己所长还是保留疑问，如一个人如果思维敏捷，擅长编写代码，而另外一个人心思缜密，擅长对细节深究，擅长进行测试，那最终是采用结对编程"领航员与驾驶员身份不断轮换"的方法更适合二者还是，让二者专精与各自领域更合适？
Q4：如何正确地处理顾客的需求
顾客的需求，首先是在产品开发前就应该确定的，明白用户的痛点所在。就如本次的团队项目来说，用户的痛点就是在于需要一款便捷性极高的刷题软件。项目开发前所理解的需求便是整个项目的重中之重，需要高度重视，于是我们团队便对此进行分析然后得出较为合适的解决方案。
而在上述过程中，更多的是开发者在帮顾客的需求做决策，这里就解决了部分"不合理顾客需求"，同时也根据开发者对项目的把握，从而挖掘出了属于项目的闪光点。
而后的过程，也需要和顾客进行更多的合作——用户反馈。在团队项目中，我们建立了反馈群，群中时常会收到对某些需求的反馈。比如能够统一对模拟考试的题目进行判断的需求、题型扩展的问题。这些问题在开发阶段，都不是很极端的问题，都可以的得到良好的解决，这一过程就是当时疑问的解答——“如何正确引导顾客提出切合自身需要并切合实际的需求，以及如何挖掘用户需求中的"闪关点"，从而形成自己的产品优势？”
先是根据用户需求为用户做决策，再根据用户反馈，取舍进行改进。例如所提及的题型扩展，兼顾便捷性和我们实现的难度，选择题可以很好适应这个项目，但是填空题就难度较大，同时还有其他形形色色的解答题。这里我们收到用户反馈后，与用户协商，最终推出了知识卡片和资源社区两个优势功能，帮用户解决问题。
Q5：在绩效评定中，引用某著名互联网公司的一个二维评价体系（书P407）中，价值观该如何定义？
这里还是再次反驳书中的观点:
如果价值观不断提高, 但业绩平平, 则是听话的小白兔, 或者哈巴狗。 可以给机会, 但是机会不多了。
如果业绩很好, 但价值观不太对路 (不太听话?), 则是一条野狗。 要坚决清除, 不然功高震主
价值观绝对不能跟听话关联。一个团队内，绝对不是以绝对标准来推进项目的，也绝不是一旦用户提出需求，就需要往自己项目堆的。价值观的存在，只要不是违反道德法律规范，都应该在一个项目中存在，求同存异是基本准则。在思维碰撞中，去理性分析取舍，而不是一股脑的就是上。就比如，我们的项目最求的是便捷性，这个时候，在用户反馈阶段中，有人提出需要网页PC端的刷题软件，对于该需求，是否要“听话”？经过了本次的团队项目之后，我对之前自己的反驳更坚定了，同时也能给出自己的定义:价值观是公司/团队，为了公司/团队更好发展，而不断磨合碰撞的产物。
新问题
- 项目开发周期短的前提下，磨合期和适应期短，如何快速定位开发者的能力从而安排合适的工作？
- 对于课程教学的疑问，教学在技术上给予的帮助如何体现，整个学期体验下来，关于技术方面的知识全靠自学，而如果遇到困难，例如自己对于前端单元测试的困难，在自身难以通过简单查阅资料理解的前提下，课程组能否以及如何提供帮助？
学到的"知识点"
需求
需求分析阶段最重要的知识点就是:NABCD。系统的来分析项目的需求。
NABCD主要从需求、做法、好处、竞争、推广五个方面进行具体分析，这个五个方面几乎囊括了项目所需考虑的内容。五个点一个点都不能忽视其重要性：需求，是产品的灵魂所在，明确自己的产品是面向什么用户，解决什么用户痛点是开发者不可忽视的；做法则是在尚未编码之前，对如何解决的一种大致方案给出；好处或者说产品主打的优势，是项目能够让用户产生良好印象的关键；竞争则是对现有产品横纵向的对比，值得借鉴的可以借鉴，不足的地方可以作为自身闪光点而体现；推广，则是最容易被忽视，但也是非常重要的一个点，直面用户群体，何时何地进行推广都是讲究，就如项目本身的刷题软件，如果在开学进行推广，根据受众习惯，几乎没有人会在此时进行刷题，所以投放时间点应该在临近烤漆阶段，此外明白推广受众，做到精准地点对点的推广也会使得产品优势得到扩展。
设计
设计主要就是学习到了如何设计技术规格说明书和功能规格说明书。
- 技术规格说明书：明确整个项目所使用的技术栈。这一点就是需要对自己能力的一种评估，以及如何根据需求选择合适的技术栈，例如本项目是设计刷题软件，那么后端就需要一种能够很好处理高并发、高负载等性能问题的技术栈。而前端，为了更好的迭代开发和适应多平台发布的功能就需要选择例如UNI-APP这种结合Vue组件化优势和多平台开发的开发框架。
- 功能规格说明书：这一点就是对需求的做法的进一步细化，细化到需要给用户提供一个怎么样的UI界面，针对于每一个页面能够解决用户什么需求，以及如何体现自己的产品的优势。功能规格书可以说是比较复杂的一个说明书，但是在开发阶段来说，正是前期定下了每个页面的UI设计和功能，使得开发阶段流程更加迅速。
实现
本人在团队项目参与到的是刷题软件的前端页面设计与功能实现，学到的知识点便是为了适应迭代开发而产生的组件化设计思路。
因为前端采用了以Vue为主要框架的Uni-APP，保留了Vue的组件化特色。在开发过程中，设计了诸如答题组件、日历组件、评论组件等自行设计的组件用于产品的开发，简化了代码的同时也提高了可维护性，尤其是答题组件，在Beta阶段时，对答题页面进行优化时，设计答题相关的部分只需修改组件便可实现优化。此外，Vue支持导入其他组件，并支持对规范的组件进行修改，使得自己开发阶段中，对如uni-checkBox组件UI设计不满意时可以直接进行修改。
测试
在团队项目中，因为前端单元测试难度较大，所以没有进行规范的单元测试。进行了模拟用户行为的真实测试，即自己去体验产品，这里收获到的就是针对化测试知识。
测试不一定需要覆盖所有代码分支，而是应该对需求强烈的功能进行集中测试，保障功能完善。此外对于该功能的细节再进行测试，模拟更多可能会出现的行为操作，这种以需求为导向核心的测试便是测试时所应看重的。
发布
发布主要学到的知识点就是：学会合适的时机进行推广。
这一部分在上文有所描述，重点就是需要知道，什么时候，什么地点以什么方式进行推广。我们的项目最终选择，在烤漆并在对应的课程微信大群，面向群体的集中微信大群进行推广，以文字、产品介绍视频等方式进行推广，效果也很好。
维护
维护阶段主要学会的是如何收集反馈。
这里我们采用的是建立反馈群的方式，在推广的时候鼓励受众进入反馈群进行反馈。对于反馈的内容收集，如果是BUG，则需要明确是如何复现的，需要即使修复；如果是新需求，需要和用户进行沟通，明确产品定位之后，适当对新需求给出解决方案并询问用户能否接受。
理解和心得
个人项目
本学期的个人项目，主要就是几篇博客的撰写。前面两篇博客个人阅读作业#1,个人阅读作业#2主要就是对软件工程的一个导入，在较短时间内建立起对整个软件工程了解的大体框架。并在带着疑问进行了到之后其他的其他项目中，一个学期过来，之前的疑问大部分也得到解决具体可以参考前面部分，而自己对软件工程的期许也完成了大部分。
而后的案例分析作业中,通过对成熟软件的使用和BUG寻找与分析，清晰了软件评测的思路和方法，以及对BUG复现反馈的能力，从用户的角度对产品进行评测，这与之后以开发者的开发者的视角去评测方向不同，但也可以反过来帮助自己加强对软件评测的理解——用户往往会针对自己所想要用的功能进行评测，然后对与自己使用习惯产生较大偏差的方面进行反馈。
总体而言，个人项目更多是对理论的一种思考，和软工的入门。
结对编程
结对项目算是自己第一次接触的东西。有点类似与之前数据库的前后端开发但又有显著的差别。后者工作相对十分独立，前者则是对同一个项目进行合作编程，让1+1>2。
领航者和驾驶员的身份轮换也很值得自己去探究。尤其是结对双方的认识评价，结对强调的是这一个“对”，成对编程不单单是两个人一起做事，更是两个人一起把事情做好，需要默契度和足够的分工分配。这一点在结对编程的时候自己和队友都尽量在这一过程中不断放大自己的闪光点，所以即使整个结对编程，无论是工程量还是难度都很大，我们结对的效果还是相当不错的。此外，结对编程这种一个人写代码和一个人复审代码的过程，也让自己学会了如何规范化编写代码（代码规范加直观的代码注释）以及阅读他人代码的能力，以及最后完成的单元测试，也让自己明白了一个合格的项目也最终离不开充分的代码测试。
团队项目
首先，很庆幸自己能够遇到一群优秀上进负责人的队友使得我们的删库跑路对不队能够最终开发出题士这一款功能较为齐全的产品。全体成员也能够一起经历Alpha阶段和Beta阶段，让整个项目的迭代没有出现太多的波折。自己在项目中一直担任的都是题士产品的前端开发人员，以自己先前做数据库网页Vue框架开发的经验，以“在实践中学习”的态度，从零开始学会了Uni-app和小程序开发流程，这一过程虽然遇到了很多BUG，但最终也还是得益于团队的帮助和自己上网查询，方得解决问题。
总的来说，团队项目最让人感慨，从一开始六个人一起为了需求分析和技术规格计划书编写忙到凌晨3点多，到后面项目开发时协商API接口以及功能和页面的优化，再到最后一起推广产品，这一步步都是软件工程开发的流程，更是整个团队合作向前的脚步。
知识点都不是在课堂上学习到的，都是自己在课后实践过程中一点点积累而成的，这也是自己认为团队项目比较具有挑战性的一点。然而当经历过Alpha阶段之后，Beta阶段开发更加得心应手，这足以体现自己在实践过程中自身能力的提高。
最后，感谢删库跑路对不队全体成员的辛苦付出!
课程建议
对于中期换人的建议，首先很感谢课程组在本学期还是采纳了同学们的意见，采用了每组出人进行协商的办法，保留人员可以继续在本小组开发做法。希望课程组能够继续保持，能够更多听取学生的意见，不是说学生的意见要毫无保留地答应，而是可以郑重地考虑一下大家的意见，毕竟真的能提出意见的人，都是对自己项目、对课程的真心热爱。
|
