软件工程 —— 课程回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任建) |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 系统性地学习软件工程理论，并开展实践 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾曾经提出的疑问，为软件工程总结。 |
| 教学班级 | 006 |
一、链接到以前提问题的博客
二、请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。
问题1：软件工程中的学习层次与刻意练习。软件工程的开发最终要落实到编码等基础环节，需要通过刻意练习将基础内容变为自动化行为，才能够有精力参与更高层次的规划设计等工作。但是术业有专攻，若采用分层解耦合思想，使用伪代码、输入输出等替代实际编码，这样是否不再需要刻意练习了呢？
途径：课外书籍阅读、软工实践
在《象与骑象人》一书中简要阐释了人的理性大脑与感性大脑、自动化系统和控制化系统等人体生理规律，使用理性大脑和控制化系统，不仅会比其他系统反应更慢，而且消耗更多的能量，因此刻意练习的目的在于帮助大脑将一些简单的工作任务迁移至自动化系统中处理，就像交换机直接在硬件层次上实现数据帧的转发以尽可能地逼近线速。
将简单任务转移至自动化系统的显著优点便是节省有限的精力资源，将其应用在富有挑战性的任务上。但是，自动化通路并不是建立后一成不变的，在长时间不激活的情况下又会逐渐退化到控制化系统中（从小到大所经历的各种考试和复习就是最贴切的体现）。因此，我认为刻意练习是非常工具性和功能性的，并且随着个体发展处于动态变化中。在每个阶段，在能够明确分辨出占用精力多的常规任务情况下，我们都应该借助刻意练习去尽可能减小此类任务占用的精力，从而尝试更多成长性、挑战性的任务。
此外，基础决定上层建筑，在团队软工中，若对基础编码和程序语言不了解，则上层的设计将受到很大的制约，此时基础编码其实应属于挑战性任务，需要利用刻意练习降低其难度。
问题2: MSF框架中所提的9条规则，部分规则如“共同的愿景”、“投资质量”等属于短期内很难改变的内容，在实际工作中，最重要、真正能够优化变化的规则是什么呢？
途径：软工实践
在软工团队项目中，我确实感受到规则中“为共同的愿景而工作”、“投资质量”是团队自组建而与生俱来的，成员的主观能动性都很强，大家工作的目标性也很明确。这种源自自身的动力我认为是团队的核心竞争力，也是长期工作中所需要的，因此这两条规则也是我认为最重要。
但是就如我在提问时考虑的一样，上述两条规则具有先天性，如果在候选人充沛的情况下作为团队准入条件当然可行，但实际情况并不总是这样，在剩余的MSF规则中，我认为“各司其职，对项目共同负责“很重要。
- 前半句话突出了成员在工作中的不可替代性，益于提升动力，同时也尽量解除了耦合：例如实际任务中，按照栏目和功能区分工。
- 后半句话强调 成员对每个项目的责任心，起到了冗余和备份：例如实际任务中，代码互审。
问题3: product, project and program manager之间的差异？
途径：博客讨论和博文阅读
经过阅读，我的问题能够从表层大致解答了，但是由于并没有真实在公司中体会，因此无法做深入的研究。
我认为相较于传统的PM，Program Manager设计目的是用于有效分割两层：
- 第一层分隔是管理层和技术层：微软PM模式将项目的管理和具体需求实现进行了隔离，使得技术层基于更相近的层次展开交流，提高效率和交流氛围。
- 第二层分隔是功能组内部和外部：微软项目部门盘根错节，技术层次的交流也大量存在，技术部门间的合作也是需要PM解决的，这也是微软自身业务特征所决定的。
问题4: 什么样的人能够成为测试人员？程序员小白最初应该做测试员 与 测试员是软件的最后一道防线是否具有矛盾？
途径：博客讨论
交由测试员的程序理应经过了开发人员自己编写的单元测试，对于大多数软件测试来说，就是从用户视角进行测试，因此对技术掌握的要求不高。因此测试需要的是责任心而不是技术，从这个维度观察，小白和资深程序员可能并没有显著的差异，相反，小白可能由于更强学习动力和压力，而能够更好地守护最后一道防线，因此不具有矛盾。
三、是否原来的问题还不明白？如果有，请分析。
经过一学期的软工课程学习和实践，我对学期初所提出的问题都有了比较清晰的认识。软工本属于工程类课程，涉及许多和实践相关的实际问题。对于上述问题的看法在真实工程中也不应一概而论，而是应该动态变化，许多规则、设计原理等等应该充当框架作用，想到但是不一定完全循规蹈矩。
四、是否产生了新的问题？如果有，请提出。
- 本学期受到疫情影响，软工的课程全部转为线上进行，团队成员的交流均通过会议系统进行；新闻上也听闻Facebook决定半数的员工将永久远程办公。在新环境下，常态的远程软件工程应是新的研究方向，请问这种新常态对原来的软件工程管理带来什么变化呢？
五、软件工程这门学问有很多 “知识点”， 这门课强调 “做中学” - 在实践中学习知识点。
- 请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点即可。
- 需求：使用NABCD的方法分析目标用户，Need - Approach - Benefit - Competitor - Delivery.
- 设计：需求分析下的设计属于编码设计与测试设计。
- 前提是明确的需求分析：功能为中心。
- 编码设计：前端从可分解的布局和功能展开，实际中需要开发框架和基础页面的先行搭建；后端从ER图展开。
- 实现：代码互审制度不仅提升项目可靠性，也对于处在成长阶段的开发者以良好学习的契机。在后续各类合作项目中都应涉及环节。代码互审需要依赖良好的工作平台，因此像Github等平台使用的学习十分重要。
- 测试：测试是一项有条理的任务，而不是仅是自动化的任务。真实的软工项目中，网页前端开发、游戏开发等均无法实现有效的自动化，测试时真正的王牌是测试的逻辑设计，而后在尽可能节省人力的情况下再考虑自动化问题。
- 发布：产品的短期价值是用户点开链接能够得到什么（一份紧扣其需求的文献路书样例、作者统计）；产品的长期价值是用户能够在平台上做什么（易用合理的文献整理、路书绘制、单元管理）。
- 维护：PM需要主动督促开发者对代码注释、设计文档、技术文档、测试文档的撰写。
六、结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。
虽然在大二学期就已经接触了面向对象的课程，对软件工程所涉及的编码和测试部分有了很深的体会，但是本学期的软件工程是我第一次参与以软件开发全流程为载体，训练合作和团队精神的课程，从中体会到在真实产品背后的工程化管理和实现。软件工程不同于其他许多知识性学科，教给我们的是在面对具体任务时所需要的框架，框架自身没有太多实质性的内容，但是就像地基一样能够为后期实现提供稳固可靠的支撑，避免少走弯路。
此外，我在本学期的软工课上也有一个遗憾，那就是在团队开发的Alpha和Beta两轮中没有进行角色轮换或变化，始终是在负责前端Vue的开发，虽然平日小组讨论的会议能够观摩其他角色的任务，但是还是没有具体从事来得实际。写在这里也是建议这门课后来的同学能够关注自身在软工中更全面的提升，而软工小组在保证进度推进的情况下可以采用“轮值PM”、“前后端调换”等方式进行人事变动。
最后补充一点我对工程学的看法，计算机科学与计算机工程属于不同的研究方向，但是，不同于计算机科学在中国快速发展，有关计算机工程的研究在国内是与国际有显著差距的，因此我认为不仅是软件工程，在各种方向的生产工程中，我国都需要抓紧对工程学的研究和总结，总结出一套高效的生产机制，助力新时代智能制造的发展。
