2020软工提问回顾与个人总结作业
| 项目 | 内容 |
|---|---|
| 课程链接 | 2020春季计算机学院软件工程(罗杰 任健) |
| 作业要求 | 提问回顾与个人总结 |
| 课程目标 | 系统学习软件开发理论和流程，通过实践积累软件开发经验 |
| 本博客的收获 | 回顾了一本好书，反思了软件工程相关的问题，总结了一学期软工项目的收获 |
链接到以前提问题的博客
2020软工个人阅读博客作业中我提出了以下五个问题
- 单元测试最适合程序作者完成？
- 预估工作时间到底重要吗？
- 典型用户的种类好像有点太多了？
- 测试人员出现bug是否该立即交给开发人员？
- 成功的企业真的容易进入创新者困境吗？
对以前提出问题的解答
-
单元测试最适合程序作者完成？
Spec是由PM完成的，这么说来为了保证功能是完善的，作为最了解功能需求的PM才是最适合规划单元测试该怎么写的人吗？程序作者只是在规划好的单元测试上增加一些覆盖代码的测试用例，保证不会在运行时出现异常即可？
在实际开发过程中，我体会到了单元测试的重要性，也体会到了规划与编写的区别。
PM在单元测试中起到一个规划的作用，在项目初期就与团队成员一起讨论来制定一个详细的测试计划，比如哪些功能需要测试哪些情况，在PR前需要做怎样的测试工作。
而程序作者是编写代码的人，需要自己完成自己的单元测试编写，而且单元测试在保证功能正确的情况下，更多是代码逻辑方面的测试，防止一些极端情况下，逻辑出错导致结果不符合预期。
我转会前后所在的两个团队中都是没有严格的划分开发和测试人员，开发人员同时负责自己模块的测试，每个人也都在自己所分配的工作上忙碌，因此单元测试更需要作者亲自完成。
-
预估工作时间到底重要吗？
这么看来当我们无法确定预估时间的时候，随便说一个预估工作剩余时间即可？那么在这种随便说的情况下，同伴们可能因为这随口说的时间太紧而过度劳累，也可能因为太长而消极怠工，或者可以借口说“这个时间本来就是随便定的，我没法在这么短的时间内完成任务”。这个时候只能靠大家自身对美好目标的共同追求来一起尽合理的力来完成任务，预估时间作为一个摆设好像并不重要也没什么意义呀？
这个问题在博客发出时，就有老师在评论中给出了解答
通过这样的几次训练， 预估应该越来越准， 但是不会要求太精确。 这样大型项目的管理就有比较可信的数据做基础。
当时我也作出了自己的思考，剩余时间的作用不止激励员工，从管理以及与客户的交流上来说，剩余时间也是很重要的。越准确的预估完成时间应该越能博得客户的信任，有助于企业推广，就算是全员努力的团队，如果每次都瞎给预估时间，客户应该也不敢100%信任他们。
从我们实践中来看，预估时间在整个项目的功能计划中也起到了非常大的作用，预估时间越准确，越能在功能规划阶段给每个人安排好合理且充实的功能，如果预估时间过长，将会导致最后提前完成无事可做，再追加功能，没法保证整体最优，预估时间过短又会导致功能做不完，最后只能裁剪。
-
典型用户的种类好像有点太多了？
但实际上软件项目种类繁多，在还没有开始调查的阶段，如何确定构建典型用户的详细程度呢？又要定义多少典型用户的种类呢？书中给出的例子是先构建典型用户，再去做用户调查来筛选用户，是否可以换一下这两个流程的顺序，从而提前缩小典型用户各个内容的范围呢？
典型用户的构建是十分重要的。如果不构建好充分的典型用户，项目功能的开发就会非常局限，而且用户调查筛选用户也和无头苍蝇一样没有实际作用。比如我第一个团队的基于微软FOTT的项目进行开发，我们在规划典型用户时种类较少，因此在alpha阶段决定新增功能时也受到局限不知道该开发怎样的新功能，没有什么好的想法。因此我认为，能够构建典型用户的种类越多，整个项目的可拓展功能就可能越多，再主要针对有可能属于典型用户的人发放调查问卷，根据调查问卷的结果来规划功能的四象限，这样不仅调查问卷的结果比较可靠，而且后期项目宣传时也更能解决用户痛点，吸引用户使用。
是否原来的问题还不明白？如果有，请分析。
-
测试人员出现bug是否该立即交给开发人员？
在我看来，测试人员立即反馈bug给开发人员应该是最好的选项。因为基于bug开发出来的代码很可能也是bug，如果不能及时掐断的话，会严重影响开发效率，比如曾经OO课程中，由于输入处理出现bug，导致我在有bug的输入处理的基础上进行进一步的开发，最终大幅度重改。而且测试人员把bug交给开发人员，可以让开发人员在了解bug之后自己决定是否立即修复bug，应该是利大于弊的？
由于我所处的两个组都是开发人员兼职测试，基本上都是自己测试自己的模块，大多数别人发现的bug都是在复审或者整体性测试时测出来的，因此这个问题仍然困扰着我，不过现在有点理解原文中提到的
阿超：不一定。因为—— （1）开发人员在开发阶段最重要的任务是完成规定的功能！ （2）在项目初期，可以不用集体会诊，开发/测试人员可以直接处理“缺陷”，不必等待。 （3）在任何时候，测试人员都可以把“缺陷”交给开发人员，但是只有会诊的人员才能改变会诊决定。
在其他课课业同样很花费时间的情况下，开发任务还是比较繁重的，先上线一个可用的功能往往比处理一些影响不大的bug更为重要，如果开发的正兴起，被告知去处理另一个bug，就会打扰开发者开发思路，影响功能的上线效率。（不过出现bug，当然也是开发人员自己没做好单元测试、功能测试等等的锅）
-
成功的企业真的容易进入创新者困境吗？
原文在16.1节中提到
当成功的企业步入中年，它们当年发迹的市场成熟 了，当年赖以成功的创新技术成了主流的成熟技术，又叫“维持性的技术”，在成熟的市场和维持性的技术环境中，技术的创新并不是影响企业成败的主要因素。 然而，颠覆性的创新会带来产品和市场的巨大风险，这些企业中的流程、价值观和文化会排斥颠覆性的创新。
颠覆性的创新的确会带来巨大风险，但颠覆性的创新也许并不意味着企业就需要丢掉原本的所有文化和产品。成功的企业有着比初创企业更加雄厚的资金和人脉，有着更多的试错机会，对新产品也有着便捷的推广能力。比如谷歌、微软、腾讯等更能吸引人才进入，做出新产品也更能便捷的推广。相比之下小公司极少数才能真的能够抓住时代的脉搏，杀入市场，一不小心就会翻车破产。所以说，成功的企业更能创新我觉得更有道理一些。
“做中学” - 在实践中学习知识点
请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点即可。
-
需求：竞争性需求分析的框架NABCD
NABCD模型这一概念是在本学期软工课才学到的，在团队项目中我们也的确使用了这个框架对项目进行了需求分析和规划。比如我所在的第一个项目就是在经历过实际项目开发的老师的建议下，发现了表单数据涉及到隐私问题，获得的成本较高，但是为了开发和巡礼那表单识别模型，数据又是必不可少的，因此存在一定的市场需求，之后基于此需求提出了方法、好处、竞争性和推广方法。第二个项目就是受腾讯文档、google docs等气发，抓住了编程新手搭配环境难、本地编程转移困难等问题，提出了线上ide的想法，最终做出了很好的产品。
-
设计：设计文档
设计文档分为功能设计文档和技术规格文档。我们在开发之前首先写好了这两份文档，在实际开发中参照这两份文档来进行功能上的开发，比自己突然心血来潮加功能或者想怎么开发就怎么开发，的确更有效率，质量也更有保障。技术规格文档也可以为开发时使用的技术提供一份指南，提前约定好技术选型，不至于之后再花大量时间调研该用什么技术比较好。而且我作为一个转会者，到了新的团队，直接看他们的设计文档便可大致了解项目的情况。
-
实现：每日例会与代码管理
在团队项目中，让我的确感受到每日例会的重要性。每日例会上需要汇报当日工作进展，也要及时提出开发过程中出现的问题与其他人交流。例会不仅鞭策着自己要完成今日的开发任务，避免了把工作拖延起来最后完成质量差或者完不成的情况，而且能够及时的矫正开发过程中思维存在的漏洞，和其他模块的人员进行交流。代码管理方面我们也从实践中，学会了如何较好的使用github进行项目的代码管理，让整个项目开发过程都更加的标准和正规化。
-
测试：回归测试
在开发的每个阶段，每次进行代码签入之后，我们都会进行回归测试。由于我是前端开发人员，场景测试是最多使用的测试方法，我们会假想自己是用户考虑在现实环境中用户使用软件的流程是怎样的，然后模拟这个流程，看看软件能不能满足用户的需求。这的确帮助我发现过许多bug，也在亲自测试之后，增添了许多更加人性化的功能和想法。
-
发布：渐进发布
首先，按照课程组的要求我们进行了alpha和beta两个阶段的设计开发与发布。这的确为我们收集用户反馈和更好的完善和更新项目提供了帮助，比如我们根据最小功能集的开发原则，完成了项目的alpha版本，并且发布给用户使用。用户在使用的过程中，为我们反馈了不少好的建议，帮助我们让项目更好的进行下一版本的开发。特别是用户反馈中，会帮助我们进一步发现用户真正的需求，及时调整项目功能的开发方向。
-
维护：统一的代码规范和注释
代码规范其实可以划分到开发阶段，但这也的确在项目的维护中发挥了重要的作用。在第一个项目中，我们接手了FOTT的项目，该项目中大多数模块都对变量名和方法有着详细的解释说明，并且有着统一的代码规范，然而部分模块基本上是0注释令人难以理解，这种对比，也让我们切实体会到了代码注释和规范在项目可维护性上的重要性，激励我们更加用心地对待代码规范和注释方面的工作。
结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。
-
个人项目
个人项目部分，感觉还是比较像是传统的编程作业，其作用更多的是让我们熟悉github、单元测试等工具的使用，练习对工作时间的预估以及部分文档的简单撰写。在个人项目中，我体会到了单元测试的好处，尝试了测试驱动开发（TDD）的开发流程 -- 先规划好模块功能，写好单元测试，再根据单元测试来开发模块，便开发边测试，的确能够提高开发效率，减少bug出现的可能性。
-
结对编程
主要是体验了结对编程这一以前没有经历过的合作开发的形式。我和我的结对伙伴由于已经在许多课程作业中建立了深厚的合作基础和友谊，互相信任，因此总的合作过程十分愉快。体会到了结对编程更快的攻破技术难点、保持愉快的编程氛围、加快对新知识的熟悉和学习、持续性代码复审提高代码质量的优点，同时也感受到了合作开发与单人开发的不同，其涉及的学问更广，比如如何更好的协调每个人的课余时间一起开发，如何更加高效的沟通交流、如何根据每人的特点分配工作和任务。
-
团队项目
在团队项目中，我真正体验到了软件工程从需求分析到发布维护的一整套规范化开发流程，感受到了具有生命力的项目和用完就丢的程序的区别。
首先是技术方面，我被随机数抽中参与中期转会，虽然转会前后都担任前端开发，但两个团队的技术栈有一定差异，分别是TS+React和vue+iview，这就导致了我不得不快速的对新技术进行学习以免影响团队的开发进度，最终从前端小白成长为了一个前端低阶码农。在技术学习方面也有不少收获，比如一边学一边做往往能够更快的让代码跑起来，实现一个可用的功能，但如果一开始没有正确理解技术原理，走了弯路，最终可能会导致功能进行重构，做了不少无用功。
接着是团队合作方面，在两个团队中的工作都很愉快，线上交流也促使我学会了如何正确而高效提出、讨论问题，比如在发现bug时，除了对bug本身的描述，我需要告知出现bug时的使用环境，以及一个可复现bug的操作流程；与他人交流时，要根据别人的交流习惯挑选合适的时间，比如有的同学时间规划比较严谨，喜欢在某个特定时间段进行讨论和交流，有的同学则随时随地可以响应消息，这些都需要一段时间的相处之后才能更好的知道每个人的特点，更高效的交流。
还有项目管理方面，这方面在alpha阶段从微软FOTT项目中，学习到了许多实用的代码管理技巧，并且在beta阶段新团队中摸索着进行了推广和使用，的确感受到了github功能之丰富以及多人合作项目中一套稳定且规范的开发流程的重要性。
最后软件工程的维护方面，无论是接手微软的FOTT项目，还是转会后参与其他团队的项目开发，都让我意识到了文档和代码注释的重要性。详细的文档和注释才能增加项目的可维护性，不仅能让自己在测试时更加完善和全面，也能让后来人在接手时有迹可循。
最后的最后十分感谢所参与过的NameNotFound和拒绝VisualStudio两个团队对我的包容和帮助，也感谢助教和老师对我们的付出，整个学期唯一的小遗憾可能就是由于中途被强制转会，没能从始至终的开发一个完整的项目吧。