软件工程-个人总结

1,回顾你的课程计划 （第一周的计划）， 你完成的程度如何？请列出具体数据和实际例子

  我当时的计划是通过阅读软件工程的相关材料，以及软件工程课上的项目，提升自己的软件开发的相关技能，并且学习在个人编程/团队合作中的科学方法，提高自己的工程效率。我的完成程度10分满分的话我给自己打6分吧，在这门课里，我学习并实践了结对编程以及敏捷流程这些团队开发技术。在团队项目中，体验到了完整的开发流程。

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

  第16章 IT行业的创新 16.1节 创新的迷思(P350)

 

大众通常把科研和创新等同起来，这也是不准确的。以发明即时贴闻名世界的3M公司的杰弗里·尼科尔森对两者做了明确的区分，他认为"科研是将金钱转换为知识的过程"，而“创新则是将知识转换为金钱的过程”。

 

关于科研和创新的区别，杰弗里·尼科尔森的观点的前半句我是认同的，而后半句话中的“创新”我感觉有些狭隘，我觉得不是所有创新都是将知识转化为金钱的过程，有些创新本来就是需要投入大量的成本，做大量的实验后才能得到的，此处杰弗里·尼科尔森所说的“创新”应该特指将如何将新的技术转化为实际应用的过程。

 

关于这个问题，我现在和当时的观点差不太多，但确实也体会到了上面所说的科研和创新的这种区别。

 

第16章 IT行业的创新 16.1节 创新的迷思(P353)

 

微软公司的中文输入法产品曾经是Office软件的一部分，在20世纪90年代到21世纪的前10年，Office多长时间发布一次呢？平均18个月到两年。中文输入法呢？也自然一样（中间可能有一到两次发布补丁的机会）。自2005年开始，一些新的挑战者开始做中文输入法，它们的更新频率是多少？是一个月，甚至半个月。那么谁更有机会做出适合用户的改变，谁更有希望赢呢？

 

这里关于产品的“更新周期”我有一些疑问，我们应该怎么来确定产品的“更新周期”？还有“更新周期”是越短越好吗？如果更新周期太短，是否会因为每次的更新内容都没有带来实质性的变化导致用户没有兴趣进行更新甚至感到有些烦？

 

我现在觉得更新周期确实需要根据具体项目具体确定，然后可以根据上一轮的周期中的用户数据来优化产 品，进行下一轮更新。

 

第6章 敏捷流程 6.2节 敏捷流程的问题和解法（P112）

 

另一个改进是，要在每一个任务中记载我们完成这个任务还需要多少时间。

 

敏捷流程我觉得是一个很好的提高效率的做法，但是这里的关于每个任务的剩余时间的估计我有一点疑问。就是我们在一个做一个全新的/不熟悉的问题时我们怎么更好的估计完成这个任务的剩余时间？

 

在团队项目中我发现估计任务的完成时间确实是一个很难的事情，特别是对于自己不熟悉的任务，可能对于有些问题会高估完成时间，在很短时间内就解决了，甚至发现根本不是问题，但是对于有些问题，特别是有外部依赖存在的，可能一开始根本不知道有这个问题，但最后却要花非常多的时间来解决。所以我觉得在一开始的时候应该需要确认好可能会遇到的外部依赖等不确定因素，才能更好的估计完成时间。

 

第5章 团队和流程 5.2节 （P92）

 

关于“主治医生模式”，文中提到在学校中经常会退化为一个人干活的情况，这里我有一个疑问就是“主治医师”如何让所有其他人都有能动性，能主动参与进来？

 

关于团队合作的模式，在团队项目中我也体验到了一些，我觉得需要通过PM来协调大家的时间和任务，并且通过每日例会等团队讨论来确保每个人都能明确自己的当前任务，从而不会退化到所谓的一个人干活的情况。

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

  我有一个问题是在一个软件开发项目的初期，如何更好地确认这个项目需要哪些外部的依赖，以及对于这些外部依赖，怎么更好的估计它所需要花费的时间？

 

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

  我又看了一遍我们的团队项目的alpha阶段的总结，当时就提出了我们的软件在alpha阶段的两个最为致命的问题：速度和UI，这也成为了我们beta阶段的主要解决的问题，我体会到了在团队开发中，“事后诸葛亮”分析这样的阶段性的总结反思还是非常有必要的，它能让你明确下一阶段的目标和努力方向。

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

  除了技能评价表上体现出来的，还学会了如何进行结对编程，如何进行团队项目的合作

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

  我觉得到了下一个阶段中，到时回头来看这门课，可能这门课产生的影响已经潜移默化的改变了自己平时的科研和开发的流程。关于建议，我觉得在团队项目中有些项目可以基于前几年别人的项目继续开发，从而收获到继续开发别人项目的一些经验，也可以让团队项目的成果可以持续维护下去。

首先总结一下，大二下学期匆匆走过，留下了很多心酸，也有很多欢乐，喜乐交加，走完了一学期，在这学期里，，对于软件工程这门课，我最大的感受就是特殊，特里，经历了大二上学期的java语言，我感受到了不会写代码的绝望，那是因为我没有去多敲代码，现在下学期也过完，我依旧能感受到不会写代码的绝望，但是这次确是一个大的Android项目，从一开始啥也不会到一点点改错，可能有了点进步，但是依旧是代码世界的盲人，可是老师曾经说过，毕业了实习期代码不是问题，问题事经验和思想，所以我们现在积累一些经验也是好的，虽然代码依旧不会敲，题目依旧不会写，但是我们有经验累积，积少成多，终会有成功的一天

     想起第一周我们每周都有总结的任务，这个总结不为别的，就是为了我说过的经验，每周写点自己干了啥，学会了啥，等大学四年结束，回头看看博客园，就能知道自己大学四年学到点啥，所以我跟随着每周写总结，已经过去14周了，也总结了好多东西，只为自己以后能知道大学生活没有荒废。

     随之想起的是我们的课堂测试，每们课可能都有课堂测试，但是我们的课堂测试却是最不一样的测试，可以用手机，可以上网，拿到老师的题目之后自己写代码（网上搜不到的代码），写完测试就结束了，就可以下课了，多么特殊的一种测试，虽然说给的题目自己不会写，每次都会痛苦的恨自己为什么没有多敲代码，现在就不至于啥也不会了，但是目前的状况无法改变，只能默默的一点点敲自己会的代码，看着别人一点点去验收，而我自己却还在查语法该怎么写，感觉很难受，只怪自己当初没有好好学java语法，最基本的一些语法写出来还会报错，现在也只能看着别人验收，而自己无能为力。

     接下来就是我们的考核方式了，能写在卷子上的考试都不算考试，所以我们的考核方式不涉及卷子，从学期的上机考试到这学期的提交app考试都是我们的期末考核方式，对于本学期的app，我只能说零基础的我们想要编出来一个app简直难于上青天，前期冲刺的我们兴致勃勃，每天去学习android语法，一点点做功能，一步一步稳扎稳打，但是换来的却是不同人写的功能不能融合到一起，这让我们接近绝望，所以在第二阶段冲刺的时候我们换了方式，算是有些抄袭别人的作品，看了被人的完整的代码，然后看看和自己的需求有什么区别，然后去一点点根据自己的功能进行更改，最后改出自己想要的东西，我们的作品终于做完了，当然前提是有别人的代码为基础，虽然是这样的方式做出来的，但是我们也学到了很多知识，改代码的过程就是学习的过程，只可惜最后还有bug无法解决，不过我们努力过，也算对期末的软件有个交代。

   最后就是应老师的要求对老师提出三个建议，首先一个就是作业太多了，真的太多了，有的时候做不完的时候不得已只能去复制别人的代码，第二个就是感觉这门课的学习压力特别大，感觉自己啥也不会，第三个就是希望对于开学要考的东西，暑假能多给一些学习资料，这样能多了解一些该学习的东西。