【软工】week17-个人作业-提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2022年北航敏捷软件工程 |
| 这个作业的要求在哪里 | 个人作业-提问回顾与个人总结 |
回答提问
Question 1
章节：
第一章 概论
1.1 软件 = 程序 + 软件工程
原文：
上面这些和软件开发活动（构建管理、源代码管理、软件设计、软件测试、项目管理）相关的内容，是软件工程的核心部分。广义上的软件工程也包括用户体验、用户界面设计（User Interface Design）等。
所以，一个推论是：软件 = 程序 + 软件工程。一个扩展的推论是：软件企业 = 软件 + 商业模式。
当然，软件企业还需要各方面的支持工作，例如人员的招聘、绩效评估、升迁、淘汰等人力资源方面的工作。弄清楚这些概念，是进行所有与程序、软件、企业等相关的讨论的基础。回到本节开头的疑惑，答案就很清楚了，程序（算法、数据结构）是基本功，但是在算法和数据结构之上，软件工程决定了软件的质量；商业模式决定了一个软件企业的成败。软件从业人员和软件企业的道德操守会极大地影响软件用户的利益。
疑问：（经验印象）商业模式真的有这么重要吗？
企业生长都遵循了这样的逻辑：发现需求——找到解决方案——形成产品和服务——建立商业模式——规模复制。（from 胡斌Steven）
因为需求是企业的起点，但是以往的认知中，总结一个刚需提出创新性的解决方案才是一个企业立足之本、做大做强的凭借资本。
回答：
企业的差异化优势主要有产品、服务、品牌、模式四个方面。发现需求、制作产品固然重要，但是在同样的需求市场中，同类产品将如何获取竞争优势呢？
模式的重要性体现在，同样的产品在好模式的运营下，会迅速整合资源，满足消费者需求，有效解决消费者信任。商业模式是企业经营的“枢纽”。没有好的商业模式，技术、产品、品牌再好，也没有好的前途。“21世纪企业间的竞争，已经不是产品与价格之间的竞争，甚至不是服务之间的竞争，而是商业模式之间的竞争。”
Question 2
章节：
第一章 概论
1.3 练习与讨论
原文：
Dijkstra曾经提到： “Software engineering， of course，presents itself as another worthy cause，but that is eye-wash: if you carefully read its literature and analyse what its devotees actually do，you will discover that software engineering has accepted as its charter ‘How to program if you can-not.” 软件工程是不是教那些不怎么会写程序的人开发软件？你怎么看？
我认为软件工程不是用于教不写程序的人开发软件的。
软件工程的原则围绕着在软件开发过程中的工程设计、工程支持以及工程管理，开发过程只是软件工程的一部分。
用自己的话说，我认为软件工程不是教不会编程的人编程，而是教会编程的人怎样“规范”地编程、“正确”地完成一个项目。
回答：
软件工程并不是教会不怎么会写程序的人开发软件，而是在教会开发者如何工程化的去完成一个完整的软件开发，让软件开发的过程规范化、系统化，增强严密性、提高效率、保证完成质量。
软件工程的主旨是用系统化的方法指导软件开发、运行及维护，指导开发者如何分析和处理问题，而不是单独细致的教我们如何编写代码。
软件工程开发的过程具体可以细分为很多步骤，包括可行性研究、需求分析、软件设计、编写代码、软件测试、软件维护等，由此可以看出编写代码只是其中的一部分。
因此回答最初的问题：不是。
Question 3
有人认为，“中文编程”，是解决中国程序员编程效率的一个秘密武器，请问它是一个“银弹”么？
我不这么认为。
所谓“英文编程”也并不是直接使用自然语言英文编程，常用的编程语言包括C、Java、Python都与日常英语语法有较大区别，甚至很多单词拼写都是创造 。而中文语法非常复杂，每个字需要用拼音打出来，为了编译器设计也需要大幅修改，大动干戈却没什么改进，得不偿失。
这里引用作者的例子：
我上班后，发现以前同事写的程序真是垃圾，根本看不懂，无法维护。我要推翻重写！后来一个老员工笑嘻嘻地告诉我，我们现在看到的程序，就是去年的新员工愤怒地推翻重写之后的结果，大家反映还没有以前的版本好用呢。
回答：
一个学期后，依然不认为稍微“中文编程”有什么革新性的意义。
与其说“中文编程”，实际上“汉字编程”更加贴切。编程语言的基本要素包括数据类型、常量、变量、运算符、表达式、标识符、关键字、数组、基本控制结构、 函数、输入和输出、解释器和编译器，而“中文编程”仅仅是将其中的标识符和保留关键字替换成中文，让母语是汉语的程序员理解这些词语的意思，但是并没有真正融入中文的语法语义，关键的编译和优化也没有较大影响。所以我不看好“中文编程”。
Question 4
章节：
第二章 个人技术和流程
2.2 效能分析工具
原文：
另一方面，代码注入就是将检测的代码加入到每一个函数中，这样程序的一举一动都被记录在案，程序的各个效能数据都可以被精准地测量。这一方法的缺点是程序的运行时间会大大加长，还会产生很大的数据文件，也相应增加了数据分析的时间。同时，注入的代码也影响了程序真实的运行情况（这有点像量子物理学中的“测试的光线干扰了被测物体本身”的现象）。
这个问题有点题外话，笔者指的量子物理学现象是薛定谔定律和测不准原理吗？
如果是的话，量子力学中的观察指的是“观测会使得量子从不确定的叠加态坍塌至确定态”，而不是从一种状态变成另一种状态、或者增大减小原本的某项数值，我觉得意思还是不太一样的（顶锅盖逃
Question 5
章节：
第四章 两人合作
4.2 代码风格规范
原文：
于是，我们最后选择了下面的格式，每个“{”和“}”都独占一行，即格式D：
if (condition) { DoSomething(); } else { DoSomethingElse(); }不要把多个变量定义在一行上。
Foo foo1, foo2;
还是引用作者的例子，研究表明键盘换一种布局能得到更高的打字效率，但是人们已经习惯了原来的键盘布局。
况且“风格”的定义因人而异，我认为除了一些基本的例如缩进、空格这样公认的代码风格要求，其他可以按照自己的习惯和喜好来编写。
我个人而言，if后面的{ 就更倾向于空格不换行，还有声明无需初始化的局部变量时也不换行。
如果写成：
list *i;
list *j;
list *k;
我反而会觉得看起来很不适应。
回答：
一个学期的Unity C#编程后，我屈服于 if后面的{ 换行了（笑）
但是由于Unity中，大多数C#脚本需要绑定在物体上，很多public attribute需要在Unity应用中拖拽赋值。如果一个变量占一行看起来会非常冗余，这一点我保留之前的意见。
例如：
public class DragObject : MonoBehaviour
{
public GameObject Floor, Wall;
public GameObject FloorGridCell, Wall1GridCell, Wall2GridCell, Wall3GridCell;
public LayerMask FloorGridLayer, ObjsLayer, WallGridLayer;
void start();
void update();
}
知识点实践
软件工程这门学问有很多知识点，这门课强调做中学，在实践中学习知识点。
请问你们在项目的需求/设计/实现/测试/发布/维护阶段，共6个阶段中都学到了什么知识点，每个阶段只要说明一个知识点即可。
项目需求阶段
知识点：使用NABCD分析项目的可行性
通过Need、Approach、Benfit、Competitors、Delivery五个部分，清楚简明的把项目的特点概括出来。
例如在本学期小组项目中，Need是剖析内核需求和最大吸引力，Approach进行竞品分析比较产品特有优势，Benefit既有服务用户也有自我提升，Competitors分别相较于其他元宇宙产品、其他高校生活平台、其他高校VR校园，Delivery展开推广方式并对预期发布用户量做出规划，这样整体分析了产品的可行性。
项目设计阶段
知识点：产品原型设计。
原本的软件制作中，我都是脑海中有一个大致的想法，就直接动手去写代码，后果就是前端的效果往往与想象大相径庭。
”这怎么与我想的不太一样呢？“
而绘制产品原型设计就很好的解决了这一点，在团队讨论功能和外观设计时也更加直观。
例如：
绘制逻辑流程图也能让编写代码时逻辑更加清晰：
项目实现阶段
知识点：项目协同与团队管理。
我们在实践中采用coding进行项目管理，制定工作流程和需求-任务-缺陷描述规范（详见博客：【Beta阶段】计划阶段要求 - 初始任务分配）。
每两天开一次例会，总结近两日进度，规划接下来两日要做的事情，由PM跟进保证进度并提出需求，每个功能发布测试任务根据缺陷修改，体会了项目实现过程中团队协同合作的流程。
项目测试阶段
知识点：保障软件工程质量的测试分类。
- 单元测试：对软件中的最小可测试单元进行检查和验证，覆盖性测试各个分支，部署CI/CD可以自动触发服务端单元测试
- 压力测试：测试复杂接口的系统并发数量
- 安全测试：鉴权机制，错误处理稳定性，恶意占用服务器资源，用户信息保护机制等等相关测试
- 功能测试：Unity前端逻辑需要专门的测试人员测试功能正确性
项目发布阶段
知识点：渐进发布和DevOps(Development Operations)
具体实践中，在冲刺阶段，我们也将周日晚上9点定为全体会议时间，与中传全体成员开会，发布一周的工作成果，试用产品提出建议，对接下来的一周设计实现做出规划。
项目维护阶段
知识点：复杂项目会诊
针对发布后的用户反馈，及时项目会诊修复bug更新发布版本。
例如实践中，beta发布后解决了登录问题、验证码问题、安卓32位版本问题，以及种种UI显示和兼容问题。
学期收获
在个人作业中，我通过阅读《构建之法》学习了软件工程的基本理论，经过自动持续集成部署、反馈hack找各大音乐APP的bug，算是自己动手，对软工课程有一个初步的体验。
随后结对编程，是很时间紧任务重的一周，两个人并肩作战，互相帮助，初步体会互相检测bug的优点，以及经过努力将单元测试覆盖到100%体会代码质量的重要性。有趣的是，在计网实验中也是两人一组，通常是一个人输入指令另一个人看，再次体会了结对编程的好处——很多错误让我自己看是绝对不会发现的，最后只能重启解决一切问题。
接下来就是历时比较久的Alpha和Beta阶段团队合作了，这次是真的全流程将《构建之法》理论给身体力行的实践了一遍。在团队合作中也发生过一些小摩擦，也曾针对不同设计方案各抒己见。这个过程除了让我在技术上，熟悉Unity布局和C#编程、代码风格有所提升之外，更重要的是让我意识到自己作为团队PM的很多问题，比如拿不下主意、想一出是一出、没有征求每个人意见等等。我以前多次在团队合作担任组长，然而这些问题是我从未深刻意识到过的，甚至会被我当成idea多作为优点，这给我将来团队合作一个很大的改进方向。
总体来说，这个课程整个学期下来确实比较类，几乎是学期初到现在，不是在肝代码就是在学习知识写博客，但是收获确实挺多，最后成果灵境APP也是我到现在完成度最高、实现效果最漂亮的一个产品。
