| 这个作业属于哪个课程 | 2020春北航计算机学院软件工程(罗杰 任健) |
|---|---|
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 增强软件开发能力，增强沟通表达能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 总结回顾本学期软工之旅 |
| 以前提问题的博客地址 | 个人博客作业 |
对自己曾经提出的问题进行解答
-
问题：
在结对编程模式下，一对程序员肩并肩地、平等地、互补地进行开发工作。两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起单元测试，一起集成测试，一起写文档等。
诚然，在公司的开发人员中使用结对编程是一个大大提高效率的方法，但是我对在大学课堂中使用结对编程的方法持怀疑态度，因为大学中同学水平差异更大，特别是在编码能力方法，大部分 人并没有经过特殊训练，在结对编程之后，很有可能出现水平较差同学被水平高的同学完全拖着走，或是两个水平都不好的同学浑水摸鱼。
解答：
课堂中使用结对编程不失为一种很好的工作方法，但没有必要强制结对。因为结对编程的效率往往建立在结对双方能力的匹配和一定的默契。我在结对编程项目中体验并不理想，就是因为和队友的不了解，以及在编程能力上有所差异。强制结对就会带来这样的问题，当双方从零结对，并且工作时期只有一周的时候，结对所带来的工作形式上的强制性可能成为一种累赘，导致效率的变低，因为我和结对伙伴需要在短时间内磨合，并且用一种没有使用过的方式进行工作，对我这种相对慢热并且适应能力一般的人来说，实在是有些困难。而神奇的是，在团队项目开展时，我们小组常常会使用结对编程方式，并且这种工作形式大大提高了我们小组的工作效率。这就是建立在我们小组成员之间的熟悉以及能力的匹配基础上。通过一人代码，另一人或者其它多人观看的方式，可以快速发现代码问题并解决，提高效率。因此，我认为强制的结对有所不妥，而应该以推荐结对的方式，并且让团队在工作展开时能有所选择的应用这种工作方式。
-
问题：
不妥，我们宁可从小部分人出发，要非常明确地定义谁是我们的用户。
为何我们宁可从小部分人出发，是更好的可以先开展工作吗？明确定义了谁是用户，是否会对项目的未来发展过于局限呢？
解答：
我理解的小部分人强调的并不是人数的小，而是为了强调我们的软件不是为所有人服务的，而是为有需求的人服务的。因此，我们在定义典型用户时，要从对我们软件有需求的人出发，并将这群人归类成为一个个典型的用户，同时这种定义需要是明确的。例如在我们团队在开发博客园时，将典型用户定义为了学生、助教、教师、从业程序员，而每个用户他有自己的需求，例如学生需要的是查看作业的功能，助教需要查看每个学生的博文，老师需要创建班级、添加成员，从业程序员可以浏览首页博客、查看闪存博文。同时，这些需求的定义需要进一步拆解，这就体现出定义的明确性。例如单单可以浏览博客这样的需求是模糊的，我们需要进一步拆解：先进入首页可以看到博客列表，点入可以查看博客详情，返回可以退回到首页，明确的需求才能让我们对任务进行划分，并将任务转化为代码。明确的定义用户可能会忽略一些潜在用户，但是它是我们初期工作开展的基础，连基础都没有做好，就更不用说未来的发展了。
-
问题：
很多开发人员还以自己写了多少代码为骄傲，枝叶繁茂, 是不错, 但是这些代码是否能有机地结合起来, 解决客户的问题?
这个情况和我十分相似，每次课设大作业代码量十分巨大，但是功能却差大佬百行出头的代码十万八千里，因此，我们是否不应该用代码量去评判工作多少，而是用实现的功能量去评判？那么功能量又是用什么方式去度量的？
解答：
就拿我们团队博客园开发的工作量评判标准举例，github的issue确实是一个很好的定义工作量的机制。 可以将自己所要做的任务定义为issue，而issue自带的标签又可以定义该任务量的大小，我们团队就是依靠issue的个数、大小、难度系数来定义每一个人的任务量，并通过一定的比例这算出每个人的贡献值，这样可以相对公平的度量工作量。
新的问题
-
问题：
对转会的同学，我们小组会分配给他较轻的工作量，但除此之外只是让他自己阅读代码进行学习和融入，由于我们项目开发难度并不高并且该组员对相关知识有一定了解，因此融入还算不错。但如果项目难度大，相关知识要求高，有什么方法能快速的让该组员学习并参与开发？
-
问题：
我们小组的博客园开发并不是基于上一届博客园进行的增量开发，幸运的是，我们基本实现了上一届的功能并新增了许多功能。但是这种重头再来的开发方式是有风险的，如何权衡这种风险，选择增量开发还是推翻重来？
实践过程中学习到的知识点
-
需求
学会了用NABCD模型分析用户需求，找到用户需求是开发的前提。
学会了典型用户的定义，进一步将需求细化，并舍弃了一些实则不存在的需求，例如并不会有同学在博客园app中写博客，因此我们将此功能舍去。
-
设计
UI的设计有学问，用户界面和用户体验有时比起功能更为重要。
我们将Nielsen的启发式十条原则作为我们UI设计原则 ：
1.可视性原则 2. 系统界面符合显示惯例 3. 用户有自由控制权 4. 一致性和标准化 5. 预防用户出错 6. 减少记忆负担 7. 使用效率和灵活性 8. 易读性 9. 帮助用户识别，诊断并修复错误 10. 提示和帮助文档
-
实现
每完成一个任务要及时push，这有助于项目的跟进以及对版本的管理。
-
测试
回归测试是必要的，其作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。由于我们博客园开发很大比重为前端开发，因此进行自动化的回归测试比较困难，我们通常在实现一定规模功能后对旧功能进行覆盖性手动测试以验证其功能正常。
-
发布
软件发布平台需要尽早确定，由于在各大发布平台上注册时间晚，其审核时间大大超过我们预期，并且还需要各种额外的材料，最后我们只能在百度云上进行发布。
-
维护
及时处理用户的反馈。我们开发的博客园app在alpha阶段收到了很多关于UI设计的反馈，因此我们在beta阶段全面改进了app的UI，并受到了好评。同时在beta阶段结束后我们也收到了许多关于app上的bug，我们也进行了修复。
自己的心得体会
-
个人项目
第一次如此细致的开发一个包含源代码管理、性能分析、单元测试、异常处理等内容的项目，可以说是麻雀虽小，五脏俱全。第一次体会到项目开发的严谨性和全面性。
-
结对项目
接触了结对编程这样新的工作方式。但是强制的结对编程体验并不理想，时间的紧促、与队友不熟悉、对流程的不熟悉导致整个结对效率较低。结对编程对能力的匹配以及一个良好的结对环境要求较高（疫情环境下并不能很好的展开）。
-
团队项目
完整的经历了一个团队项目的开发流程，收获很多。从仅仅作为一个螺丝钉，只完成自己那部分任务，到能为团队提出意见，为团队整体服务，这是我在团队中的成长，也是团队本身的成熟。一个团队不是个人能力的简单加，而是一个会发生化学反应的复杂组合，并且会在合作过程中成长抑或是崩溃，它需要领导，更需要每个人的投入和付出。
感谢软工课以及课程组所有人员的付出，也感谢我的队友们。