软工总结
一、链接到以前提问题的博客
第一次博客作业
二、请尝试对自己曾经提出的问题进行解答,并阐明,是如何通过看书,实践,或者讨论弄清楚的。
1.在**“好看的GPA”**与**“完整的知识体系”**中,势必要有所侧重,但这个侧重的度究竟是怎样的?**GPA**与**知识体系**两者在未来对自身的影响究竟是怎样的?
对于这个问题,通过这个学期的软件工程课程以及其他课程的学习,笔者已经有了自己的认识:这两者其实并不是那么冲突——构建了完整的知识体系后,自然会对这一学科的学习有较为全面的认识,成绩自然也不会太差;而即使是通过刷题、突击的方式来争取一个不错的成绩,那么在这个过程中,其实也已经了解到了这一门课程的重点、难点究竟是什么,以及如何攻克它们。
2.对于一些初学者来说,他甚至不知道哪些问题是不可以绕过的,哪些问题是可以解决的,哪些问题是很难解决的。那么对于不同的人来说,究竟该如何走出或者从根本上避免陷入类似的误区呢?
在本学期的两次开发过程中,我对这一问题的认识尤为深刻。开发过程中用到的所有知识几乎都是要通过自学完成的,难免会遇到障碍。这一知识如何应用到这一问题上?切入的角度是否正确?甚至该不该用到这上面来?当然,可以通过咨询他人的方法来解决。但最主要的,我当初提出的这个问题本身其实就是一种能力,培养这种能力在未来的学习生活中是及其必要的。
3.虽然摆脱国外操作系统“垄断”,对于我们民族的伟大复兴来说,是很有意义的一步,但究竟应该如何做到呢?从更小的规模来说,如果创新者的研究方向恰好是已经几近于成熟的,那他的创新还有意义么?
经过一学期的学习,我对这个问题的看法已经有所改变。诚然,创新不可能一帆风顺,而其有很大的风险会面临着失败。然而与第二个问题类似的是,创新者如何评估创新的风险。综合考量创新的成果、失败的风险,来决定是否走上创新之路是每个you这想法的人必须要做的工作。即,不打无准备之仗,大胆的创新并不意味着大胆地决策,相反,倒需要决策者有一定的远见。
4.我们究竟该如何**在小的创新被整合之前**,发现这些小的创新的价值?如果不对这些小的创新给与相应的激励,最终会不会形成一种不愿有人当**创新者**,都想去当**“整合者”**的风气?
提出这个问题时,我可能对于软件开发相关的领域了解不是深入,其次,个人的侧重点也有所偏颇。其实这一领域还是相当开放的,并不存在那么多铜臭味的纠葛,相反,大多数人都是为了有所贡献而贡献,比如开源。
5.在一些学生遇到难题时,如何避免“高动力低能力”的学生,逐渐变为“低动力低能力”或者是“高能力低动力”的学生?谁来担当这个“领导者”的角色?有哪些有效的举措呢?
这个问题可能因人而异,毕竟每个人的经历都不一样。但就我自己而言,这个问题至今依旧没有一个明确的答案。
三、是否原来的问题还不明白?如果有,请分析。
- 见(二)5.
四、是否产生了新的问题?如果有,请提出。
- 无,倒是有很多收获。
五、请问你们在项目的 需求/设计/实现/测试/发布/维护阶段(一共6 个阶段)中都学到了什么“知识点”,每个阶段只要说明一个知识点即可。
阶段 | 收获 |
---|---|
需求 | 需求本身对项目效果的影响真的很大,但由于我们组是指定命题,因此基本不涉及这一问题 |
设计 | 好的设计能够在实现阶段省去很多烦恼,也许需要设计者对实现的相关技术有一定的了解,而不是像一个甲方 |
实现 | 对于新手而言,学习的效率基本上决定了实现阶段的成果好坏 |
测试 | 测试本身应该是穿插在实现过程中的,而非线性的承接于实现过程 |
发布 | 发布不会影响产品本身的好坏,但会影响甚至决定大众对产品了解与认可程度,即销量 |
维护 | 我认为维护就是实现的对立面,实现的好,维护的工作就轻松;实现的差,维护的工作就困难 |
六、结合自己在个人项目/结对编程/团队项目的经历,谈谈自己的理解或心得
- 由于同组的老哥们都十分好说话,而且基本不存在拖拉的情况,都是尽力而为,因而很少会因为对别人的工作不满意。
- 对于每个人各自的工作,应该是六分靠学习,三分靠实践,一分靠沟通。虽然课程尽可能地模仿真实的开发流程,但毕竟还是有很大的区别。产品需求、发布时间等等无法自行把控,可能有些遗憾。
- 最后针对个人项目与结对编程,希望课程组能够对结果有一定的反馈,而不是仅仅回复一下博客、打个分数就结束了。否则我会认为这两个环节意义不大。