现代软件工程 课程总结

标签：alpha   地方   纠正   一起   习惯   很多   提高   职业   估计   

现代软件工程最后一周总结要求

回顾你的课程计划， 你完成的程度如何？请列出具体数据和实际例子。

在课程计划中我认为最重要的5个技能是：程序理解、代码质量、python、处理大数据、个人源码管理，计划每周拿出10小时完成软件工程课，完成情况如下：

• 程序理解，在完成团队项目的时候阅读了Tensor2tensor的代码，Tensor2tensor的代码量很大，但很多功能我们用不上，实际阅读量大约几千行。
• 代码质量，在和队友结对编程的时候，从队友身上学了很多好的编码习惯，代码可读性在结对编程的实践中也得到了提高。
• python，整个课程中大约写了2000行不到的python代码。
• 处理大数据，完成团队项目时对原始对联数据做了简单处理，由于没有深入，因此在这方面提升不是很大。
• 个人源码管理，积累了使用github的经历，软件工程课的所有项目均使用了github。
• 时间投入，黄金点游戏（15h）+ 词频统计（15h）+ 大作业（5*20=100h）+ 阅读作业 （10h）+ 案例分析（10h）= 140h，第一周博客10.17日提交，最后一周总结1.21日提交，时间跨度3个月，平均下来差不多一周10小时。

你在课程开始快速浏览了《构建之法》，提了 5 个问题， 请回顾那些问题， 自己回答它们。如果不能回答，为何软件工程课不能让你回答这些问题？

原文：
Ch04, P79, 每人在各自独立设计、实现软件的过程中不免要犯这样那样的错误。在结对编程中，因为有随时的复审和交流，程序各方面质量取决于一对程序员中各方面水平较高的那位。这样程序的错误就会少得多，程序的初始质量会高很多。
问题：
我们在第一次结对编程的debug阶段中采用了这个方法，但是发现两个人的交流有时候会掩盖问题，来自代码创作者的解释会隐藏那些不易察觉的小bug，很多隐藏的比较深的bug还是在一个人独立阅读代码的时候发现的，是因为结对编程不适用于debug阶段吗？

我觉得结对编程主要还是为了纠正逻辑的错误和偶尔的明显笔误，像一些数组越界等小错误还是要编程者自己改正。

原文：
Ch6, P112, 另一个改进是，要在每一个任务中记载我们完成这个任务还需要多少时间。
Ch6, P115, 我们感觉好像项目完成了80%，殊不知后面的20%往往要花费80%的时间。
问题：
敏捷流程的核心是基于能够估计出任务的剩余时间的。但文中又说很多时候并估计不准时间。我感觉这里似乎有一些矛盾。如果预计完成时间估的不准，那么敏捷流程跟尽全力向前推进似乎没有什么区别？还是说一般工程项目都能估计的大差不差？

在真实项目中不是线性的，要一样一样完成，而是一个流程图，一个工作开始可能依赖于多个基础工作的完成，因此要估计时间来分配资源，有点拓扑排序的感觉。

原文：
Ch8, P156, 用户在各种菜单中幽幽暗暗的反反复复的寻找某个功能，我们在单向玻璃后面替他着急……我们的界面距离“平平淡淡从从容容才是真”差太远了。
问题：
想问一个和书关系不是那么大的问题。就是现在产品的菜单和图标设计（比如word）依然很复杂，用户很难知道自己要干什么事，就能根据菜单名称大致找到地方。UI换了一版又一版，菜单设计却没有大的更新，是因为尾大不掉么？就是说为了和老版本兼容从而不能大面积修改菜单？

这个由于在软件工程课中没有涉及到，因此要等以后来回答了。

原文：
Ch16, P353, 但是绝大多数用户都不会告诉公司颠覆性的需求，就像马车夫那样，他们会希望马更快一些就好了。
问题：
我认为这个例子并不能说明问题，马车的出现和汽车的出现相差很远，起码远超一个公司产品的周期。而且马车直接变成汽车这个请求未免太颠覆性了。就像手机屏幕从按键变成触控笔再变成手指直接触控一样，是因为用户不断反映体验不好才促进了产品的升级的。用户是很难知道未来的发展趋势的，成功的公司重视用户，应该推理出公司自身会去想颠覆性的方法满足用户的需求。而不是把没做出颠覆性进展归因于用户没有提出来，这可能对用户提了过高的要求。

我保持开学的观点，认为成熟的公司重视用户和创新之间在这个例子中不为两难。

最后一个问题是建议，略去。

看看还有什么新的问题产生，请列出来，建议列出 2-3 个新问题。 可以让老师和助教来回答。

在实际编程中，我能感觉到自己对面向对象编程并没有什么概念，很多类的使用十分刻意，一些有联系的类我也很难用继承把他们组合在一起，结果并没有从面向对象编程中得到显著收益，比如让代码变得可读性更好等，想问一下是否有具体介绍程序架构设计的书籍推荐？

你看了一些软件工程的文献， 你的团队也做了一两次 “事后诸葛亮”分析， 可以再去看一遍，现在有什么新的感想？

对于一个面向用户的产品，最重要的是用户体验，首先是整个流程要能跑通（MVP），其次是流程的速度要快，再次是UI界面要美观，而后端的模型相对来说并没有那么重要，这是我大作业最大的感触。

对比一些技能评价表，你有什么提高？ 还有什么收获是不能用数字衡量的？

这部分内容大致和课程计划一样，程序理解、代码质量、python、个人源码管理的技能提高了2分，处理大数据的技能提高了1分，但还需要继续增强。

设想一年之后， 你到了你职业发展的下一个阶段（高年级， 读研，工作），回头看这门课， 你对于这门课的教学方法， 老师和助教的工作，和其他课程的衔接，有什么意见和建议？

我觉得这门课总体来说设计的很好了，在有限的课程时间里让学生完成一个完整的项目，两个冲刺阶段的设计提高了时间利用效率。
一个小建议是文献阅读作业可以早一点发布（Alpha阶段前），晚一点结束（Beta阶段后），这样阅读的时间更充分，而且学生也更加有感悟。

现代软件工程 课程总结

标签：alpha   地方   纠正   一起   习惯   很多   提高   职业   估计   

原文地址：https://www.cnblogs.com/ustcscallion/p/10297805.html