个人作业4-alpha阶段个人总结

Posted 2020-11-06 wx-jum

一、个人总结

part 1

part 2（友情提示：网页放大到175%观看效果最佳...）

二、回答问题

我们在课程开始之初，曾经要求大家针对软件工程提出问题：个人阅读作业2，那么在经过alpha阶段，大家是否对软件工程有了一定的了解？请结合自己提出的问题进行回答

个人阅读作业二链接：http://www.cnblogs.com/wx-jum/p/8589499.html

• Q1:看完上述对敏捷流程的定义，仿佛对敏捷有了一点想法，我在想“敏捷是一种思想吗？”准备看书验证自己的想法，但是看完第六章，发现有敏捷流程、敏捷开发、敏捷的团队...所以我不仅没明白什么是敏捷，反而更加懵了。。。带着“到底什么是敏捷，敏捷很高大上吗？”的疑惑，我在网上看见一篇敏捷软件开发和传统软件工程概述比较，这篇博客虽说名称为两者的比较，实际上二者之间的比较倒是很少，主要是分别介绍了敏捷开发和传统开发，看完这篇博客再看书，我的理解是：敏捷就是一种思想，一种把一些相对重要和有效的做法发挥到极致的思想。如果我理解错误，还希望老师、助教或者同学可以帮我指出来，谢谢！
  A1:敏捷就是一种思想，一种把一些相对重要和有效的做法发挥到极致的思想。敏捷开发的核心思想主要是迭代式开发，将整个项目分解为数个短期的迭代周期，快速相应需求进行增量开发。

• Q2:我不是完全赞同上面的说法，我的理由是如果结对的两个人擅长的技术相似，那么结对就有可能浪费时间，其次，在和别人合作的时候，每个人表达观点的方式和思考的方式不尽相同，所以还有双方陷入争吵，甚至会导致项目停滞不前的风险。除此之外，虽然结对编程对代码的审核会比代码评审细致一些，但是结对编程的成员由于结对前期的交流，可能会使他们的思维趋势相似，这就会导致两人犯下同样的错误，或者忽略某一错误。当然结对编程也有很多好处，但是我觉得书中提到的结对编程太过于偏向它的好处，我的想法是应该也要分析一下结对可能出现的问题以及如何避免。
  A2:经过结对编程和第一阶段冲刺以后，我发现还是合作的效果比较好，对于刚开始提问所说到的思维趋势相似，最后发现只是在一些大方向上会有思维趋势相同，实际上在写代码的时候不太可能会这样，因为每个人考虑方式不同。

• Q3:我看了上面那段文字，我的问题是怎么理解“它使用了宏来进行抽象和信息隐藏。”这句话，我查了资料什么是宏，其中说宏是一种批处理的称谓。以及信息隐藏中说到 信息隐藏技术利用信源数据的自相关性和统计冗余特性，将秘密信息嵌入数字载体中，而不会影响原载体的主观质量，不易被观察者察觉。 我的理解是文学化编程可以通过某种语法替换来使信息“加密”。。不过我觉得自己的想法还是太过牵强，加黑的语句中每个词都可以理解，就是组成一句话就理解不了了。
  A3:这个可以跟宏定义结合起来理解。

• Q4:我不理解这段话第一段话最后一句话这类测试叫系统/集成测试。为什么作者在这里把系统测试和集成测试归成一类，我在知乎和百度上看到的系统测试和集成测试都是有区别的，它们的侧重点不一样，集成测试主要是针对程序内部结构进行测试，特别是对程序的各单元之间的接口进行测试，而系统测试侧重验证设计中的功能是否已经完成；上段话的问答中“场景测试是把软件作为一个整体来使用。”那么这个思想和集成测试的“对一个软件进行全面和系统的测试,以保证软件的各个模块都能共同工作”思想很相似，为什么不把集成测试和场景测试放在一起定义呢？如果这三种测试都不一样，那么他们之间的关系是什么样子的呢？
  A4:集成测试主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与其它程序部分之间的接口上可能存在的错误。系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。场景测试测试主要是针对用户不同场景需求的测试，所以这三种方法的侧重点不太一样。

• Q5:大马哈鱼洄游模型是什么模型？网络上关于“大马哈鱼洄游模型”出现的都是大马哈鱼的图片或者它的做法。。。
  A5:就像从瀑布下方一步一步上溯到源头,然后又从源头流下去的学习模式,被称之为“大马哈鱼洄游模型“。

三、再提问题

大家一定会在实践过程中产生更多问题， 结合你的读书（教材，博客，参考书）， 实践， 再提出关于软件工程的 5 个问题。

技能的反面：......“精通魔方”......一个IT专业的大学生来面试......

-- 引用自《构建之法》

• 问题一：解释“技能的反面”用一个学生面试的例子就可以解释清楚，而魔方这个例子并没有正面解释到底什么是技能的反面，所以这个例子是不是多余的？

程序员写完功能的时候，我们感觉好像项目完成了80%，殊不知后面的20%往往需要花费80%的时间。

--引用自《构建之法》

• 问题二：软件开发最重要的不是把这个软件开发出来吗？后续工作真的有必要花大量的精力去做吗？就像上次的alpha阶段中间需要连续写八天的博客，每次写博客也会花挺多时间的，如果把这些时间花在写代码上面会不会更好？
• 问题三：在alpha冲刺阶段我们遇到了一些技术上的难题，有时候遇到的问题需要花很多时间去解决，如果有这样一种情况，领导交给我们一项任务，限定我们一周内完成，但是在做的过程中发现遇到一个瓶颈，若需要解决这问题那么就肯定会超过一周，若不解决这个问题就可以按时完成工作，只是工作完成的并不完美。这时候应该怎么选择呢？

软件团队的人员也会流动，新的成员要尽快读懂已有的程序，了解程序的设计。

--引用自《构建之法》

• 问题四：第一个冲刺阶段也已经结束了，接下来我们就要考虑更换团队的成员了，一个团队已经合作大半个学期了，相互之间也越来越有默契了，如果更换队友，那团队之间可能就还需要再有一段磨合期，这不是浪费时间吗？那我们为什么一定要换队友呢？
• 问题五：在第一次团队复审的时候，有同学对我们团队项目提出的问题是“可以收藏自己想着重学习的单词吗？”这个功能之前并不在我们的计划之内，那么后续是要改变计划加入新的功能之前还需要用户调查吗？每次加入新功能之前有没有必要再做一次用户需求调查？

附加题：请将问题提交至豆瓣：https://book.douban.com/subject/27069503/， 并在博客中给出链接

在豆瓣页面的最下方 “读书笔记” 那里发言，《构建之法》的作者会亲自答复问题

• 豆瓣提问链接：https://book.douban.com/annotation/56776143/