软件工程-提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 本作业属于北航软件工程课程 | 2020春季计算机学院软件工程（罗杰 任建） |
| 本作业的要求请点击链接查看 | 提问回顾与个人总结 |
| 我在这个课程的目标 | 提高自身的代码能力、学习团队协作开发的过程 |
| 本作业帮助我实现目标的具体方面 | 总结课程收获 |
在学期开始的时候，我针对软件工程的方法提出了一些问题，提出问题的链接为：
已经能够解答的问题
问题一
教材的1.1章节客观地描述了软件工程中包括的各种内容：
1.1 软件=程序+软件工程
上面这些和软件开发活动（构建管理、源代码管理、软件设计、软件测试、项目管理）相关的内容，是软件工程的核心部分。广义上的软件工程也包括用户体验、用户界面设计（User Interface Design）等。所以，一个推论是：软件 = 程序 + 软件工程，一个扩展的推论是：软件企业 = 软件 + 商业模式当然，软件企业还需要各方面的支持工作，例如人员的招聘、绩效评估、升迁、淘汰等人力资源方面的工作。弄清楚这些概念，是进行所有与程序、软件、企业等相关的讨论的基础。回到本节开头的疑惑，答案就很清楚了，程序（算法、数据结构）是基本功，但是在算法和数据结构之上，软件工程决定了软件的质量；商业模式决定了一个软件企业的成败。软件从业人员和软件企业的道德操守会极大地影响软件用户的利益。
很显然，以上这些环节都是必不可少的，它们的技术难度有高有低，在实际的软件应用开发中薪资也有高有低。那么这些环节之间，哪个能对软件最终呈现的效果产生最大的影响？在学校中同学们都将学好程序技术作为第一目标，那是否在技术的基础上对软件工程掌握得越好就能开发出更好的软件？技术人员的重要性（地位）是否高于其他环节的工作人员？
-
解答：
在这次的团队项目中，我认为能“对软件最终呈现效果产生最大影响”的其实是软件设计的阶段，即这一软件希望实现怎样的功能。软件功能的设计和UI的设计结束后，软件所能达到的水准高度其实已经被确定。如果在立项设计阶段仅仅是设计出了平庸、大众化、已经被人重复了许多次的功能（比如很多学校的软件工程课都只是在做各种管理系统），那么无论技术人员的水平有多高，都是做不出优秀的软件的。在设计阶段，技术人员当然非常重要，可以是由技术人员来提出设计，在对软件功能进行设计时必然要考虑到这些功能是当前技术人员的水平、当前的计划时间内能够实现的，而不是天马行空地画饼。也只有高水平的技术人员、设计人员才能准确发现用户痛点、设计出简洁有效的软件功能。
“在技术的基础上对软件工程掌握得越好就能开发出更好的软件”这一点肯定是正确的，但是我认为软件工程的各种方法，对软件效果影响的优先度是不同的，在不同条件下的使用方法也是不同的。在最理想的情况下，软件开发时间充分、团队成员技术水平成熟并对项目十分了解，那就可以完整地实践构建管理、源代码管理、软件设计、软件测试、项目管理这一系列流程。但是，比如在团队项目的alpha阶段，团队成员对所需技术并不熟悉、需要学习成本，因此开发时间并不充足。所以一切活动以“完成功能”为第一目标，在项目管理等方面存在不规范的地方。而在团队项目的beta，时间充足、技术成熟，就有精力去完成规范的项目管理，还做了一些重构代码的工作。但是，由于团队规模并不大（6人）、模块划分清晰，不规范的代码管理并没有影响到软件的最终效果。可以说，当时间紧急、团队规模不大，可以以尽快交付为最高优先度。而当团队规模较大、对软件的稳定性要求高的时候，就必须要考虑严谨的源代码管理、项目管理、项目测试等部分。
在我们本次的团队项目中，因为项目工作量较大，所有团队成员都担任了开发人员和测试人员，因此无法完全区分“技术人员”和“其他人员”。但是可以得出明确的结论：技术之外的其他因素极其重要。如果没有一个优秀的pm，我们这个存在一定难度且工作量较大的项目甚至在alpha阶段按时交付都比较困难；如果没有一个熟悉项目、擅长的展示的团队成员，那么别人就无法得知我们项目的优势。优秀的技术人员诚然重要，但是一个优秀的pm更能充分地发挥出团队的潜能、保证项目的进度，而有一个优秀的“推销员”对软件推广就更重要了。
问题二
教材在3.1章节中这样写道：
3.1 个人能力的衡量与发展
在团队工作中，稳定、一致的交付时间是衡量一个员工能力的重要方面。软件项目的确需要创造性，需要一些意外，一些惊喜。但是，更多的是常规的、可重复的任务，软件工程的奠基人之一瓦茨·汉弗雷总结说，软件领域可以分为两个方面：一方面是技艺创新的大爆发；而另一方面是坚 持不懈的工程工作，包括软件的改善、维护和测试等，这一方面占了90%—95% 的比例。对于这些任务，一个成熟的软件工程师应该能够降低任务交付时间的标准方差。
结合以上内容，是否可以如此概括：工程师实现需求的效率和稳定性就是评价工程师能力的指标？
-
解答：
在我们的团队项目中，每个人都是开发者，每个人都可以对项目的设计提出观点，因此体现出的能力并非是单纯的工程能力。但我认为，如果要评价“工程师”的能力，就不再考虑“提出观点”的能力，实现需求的效率和稳定性的确是首要的评价指标。
问题三
技能的反面是什么？教材在3.3章节中这样写道：
3.3 技能的反面
计算机人机交互领域的科学家比尔·巴克斯顿（BillBuxton）在1995年的一篇文章中提到了“The Op-posite of Skill”[注释10]： Before reading on, think for a moment, and tell me what is the opposite of skill? I'll even give you a hint： I'm not looking for "unskilled". 巴克斯顿说技能的反面是“Problem Solving”—“解决问题”，
就我对文本的理解来说，作者认为“解决问题”指的是“解决低层次的问题”，如果一个人需要不断去解决低层次的问题，那么这说明他对低层次的问题掌握并不熟练。只有一个人当将所有的低层次问题都不再当成问题，都变成自然而然的操作、都不再需要“解决”的过程，才能称为是掌握了技能。
我的问题是：什么样的问题能被称为是“低层次”的问题？计算机技术飞速发展，新技术层出不穷，一个人不可能完整地掌握所有技术，不可能掌握所有新技术中的“基础”部分。面对新技术，无论怎样的“高手”都要经历一个学习的过程。那么面对一个问题，如何找到它在书中讲述的“问题的层次”中的位置。
-
解答：
这个问题在我这次的团队项目实践中得到了一定的解答：即使新技术层出不穷，只要是同一领域的问题就一定会有根本的互通点。一个“高手”如果是在他专业领域内的“高手”，那么对于一些共通的问题就能够轻松地理解。举个例子，我在这次的项目中就遇到了一个关于“对象深层复制”的问题，这样的问题在很多编程语言中都存在，但是我没有考虑到它在JavaScript中也会出现，因此一开始完全没有考虑到这一问题。究其原因，还是我对深层复制本身不熟悉，这是所有技术都可能存在的一个基础问题。如果熟悉，那么在进行操作之前就一定会先考虑：在这个新语言中是否存在同样的特性。
仍不明白的问题
有一些问题，譬如说关于工业界软件工程情况的问题，在我们的团队项目实践中没有得到解答。
问题一
教材在3.1章节中这样写道：
3.1 个人能力的衡量与发展
在团队工作中，稳定、一致的交付时间是衡量一个员工能力的重要方面。软件项目的确需要创造性，需要一些意外，一些惊喜。但是，更多的是常规的、可重复的任务，软件工程的奠基人之一瓦茨·汉弗雷总结说，软件领域可以分为两个方面：一方面是技艺创新的大爆发；而另一方面是坚 持不懈的工程工作，包括软件的改善、维护和测试等，这一方面占了90%—95% 的比例。对于这些任务，一个成熟的软件工程师应该能够降低任务交付时间的标准方差。
结合以上内容，是否可以如此概括：工程师实现需求的效率和稳定性就是评价工程师能力的指标？除此之外，我还想知道，这样的评价指标在实际工业界中推广和执行的程度如何？如何量化？
在项目实践中学习到的知识点
-
需求
从理论到实践还是非常困难的，虽然说我们学习了NABCD这样一个竞争性需求分析框架，但它只能帮助我们分析项目，不能帮我们提出项目。因为“做什么项目”关系到了我们这后半个学期为什么而努力，团队成员们都不想轻率地决定，否决了许多不太好的提案。在长达约六七个小时的马拉松会议后，终于决定做一个线上的WebIDE。这个过程非常劳累，但是从后期成果来看又是非常值得的，这个项目做到了独特性和技术性共存。在这一阶段，我学习到的就是需求分析极其极其重要，而且它的作用是后期各阶段都无法弥补的。软件工程中在这一阶段无论投入多少精力都是值得的。
-
设计
功能设计文档和技术规格文档非常重要。在项目alpha阶段，对项目的全貌和使用的技术都不是很熟悉，在完成当下部分之后就不知道接下来该怎么做了。而技术规格文档就可以作为一个指引。在完成项目的大部分内容后功能设计文档就可以起到一个查漏补缺未实现功能的作用。与软件测试时团队成员发现的bug要及时记录下来，供所有团队成员查看使用一样，是为了防止有漏网之鱼，纸面记录一定比脑子更可靠。
-
实现
每日例会非常重要。每日例会可以鞭策团队成员及时完成当天的任务，可以根据项目的实际完成情况，及时调整项目计划，还可以提高团队的活跃度，调动团队成员之间积极地进行交流，这些都能极大地提高工作效率。
-
测试
我是前端开发人员，主要的测试方法则是把自己当成客户实际使用。但这里出现了比较大的问题，问题产生的主要原因是没有想到用户在第一次使用软件时的使用习惯，预设用户知道各种功能按钮的使用方法、预设不会出现非法行为。这一经验让我深刻地体会到，有时候完善已有功能的异常处理比实现一个新功能更为重要。
-
发布
其实发布也是一个测试的过程，进行大规模的发布也就是进行了充分的测试。在alpha阶段我们因为一直担心服务器的负载能力，没有努力进行充分的发布。而在beta阶段我们调整了后端设计，进行了相对规模较大的发布，得到了许多好的反馈，有许多反馈来自我们之前完全想象不到的角度。
-
维护
根据发布后得到的用户反馈，进行bug修复和调整。其实在这一阶段积累的经验是：并没有必要在收到反馈后第一时间去修复并重新上线，而是可以等待积累一段时间的反馈后，重新上线一个优化力度较大的版本。可能因为我们制作的是Web应用，重新上线非常便捷，如果制作的是需要下载的离线软件那么这个问题可能会更加突出。
对课程的理解和心得
-
个人项目
在个人项目中收获最大的可能是知道了git的使用方法和标准commit信息的写法以及单元测试的思想。在后期的团队项目中我使用了vue框架，它有自己单元测试的框架，因此和之前学到的东西关联不大。
-
结对项目
在结对项目中，一个收获是明白了沟通的重要性。在之前各种课程上的团队作业中，其实并没有太多“团队协作”的成分，基本上都是把任务直接切割各自为阵。而这一次的软件工程课上，在结对项目和团队项目中则真正体会到了什么叫做“团队协作”。要推进团队协作，充分有效的沟通交流必不可少，每个团队成员必须对自己的任务负责，并且受其他团队成员的监督。另一个收获就是努力写出了规范“优美”的代码。因为写出的代码不仅是给自己看的，更要让其他的团队成员理解。在结对项目中的这一习惯也影响到了团队项目。
-
团队项目
这可能是我大学里印象最深的课程之一。如上文所述，这是我在学习过程中第一次参与到真正充分的“团队协作”，体验在一个时期内高效工作、做出一个有生命力的完整产品的过程。在需求分析、技术学习、项目管理等等方面的问题在上面已经谈论了许多。总结一下就是：软件开发技术并不是软件工程的全部，许多软件工程和敏捷开发的理论并不是纸上谈兵，而是在实际的应用中都能发挥出巨大的作用。
经过这次经历，我也发现了我学习方法上的一些问题。我的表达能力、展示能力、组织能力并不好，但我觉得只要埋头把技术学好就可以弥补不足。但是通过这次团队项目，我发现表达能力就是技术能力的一部分，头脑清晰、善于交流、善于质疑，这些都是技术能力强的人的共同特点。我不应该再把“我花了时间去学习”当作表达能力差的借口，只有正视缺点才能取得进步。
