标签：限制 重要性 开发 模式 产生 需要 检验 团队 判断
软件工程概论这门课，在我感觉看来最其他课程有着很大的不同。这学期其他的课程，主要讲的都是知识点与高中或者以前那种学习模式大同小异，而教我们这门课的王老师则感觉更重视个人能力的提升以及观念的革新。而技术层面的知识主要依靠自己的自学能力去完成，这种方式可能对于有些同学习惯了哪些手把手教学模式的人有很大不适应，如果你跟着课程认真走，并且课下按照老师的说法做，他确实可以在很大程度上提升你的能力，这里并不指你被灌输的那种知识或技术，而是自学能力、眼界、以及局势的判断这谢无论业界发生怎样的惊天动地的变化，仍可以为一个人持续使用并且不断从中受益的能力。
在一开始，确实对这门课有过一段时间的懈怠，认为老师讲述的开发流程，团队合作，未来规划这种东西与技术问题相关联甚远，以至于谈笑而过。但后来在我日常浏览一些新闻评论后，查看了一些程序员对自己经历或者对其他人经历的一些评价，如“IT就是吃青春饭的”，“35岁被辞定律”等等这种言论，又或者“公司跳槽”这种现象的评价等等。这让我产生了一定的不知从何而来的危机感，为此我看了一些大牛的职业发展道路，或者是对新人道路的一些建议，其中与王老师讲述的课程内容有不谋而合之处。从此我开始逐渐改变自己的看法，对一个人来说，技术是一方面，除非哪些可以引导技术革新的人不愁失业与前途，而我们大部分都是普通人，想要稳定并且不错的未来，必须拥有对待发展道路的新的看法以及对自己发展道路的规划。
这些谈论概论重要性的话题暂且不谈了，接下来谈谈我在课程中所学到的，也可以说是自己的收获。
在学期之初，开课便进行了Mis系统的学科检验并会计入期末总分数，坦白来说，我是真不大会，功能基本上就完成了一半可谓凄惨。但后来经过自己在视频网站中的学习，对此掌握了，这是开课之初的收获。
在王老师四节课的后两节课都会有一些课堂小测验，对于这些测验我感觉都是让学生对技术方面，对一个工程某些方面来提起注意，用简单的实验例子来说明为什么要注意这方面，为什么要加以限制，诸如其中带小数点的计算，或者说是输入信息的建议，最简单的用户名密码的检验。而在某些课程中，王老师则会讲述一下软件流程，如在大公司一个合格的程序员每天都要做什么，忌讳哪些话，哪种行为，哪种人最容易被辞退。同样告诉我们在一个团队中如何分工，如何高效率的完成任务，对于我自己来说收获很多。其中在团队任务和软件开发流程跟我们讲述了很多，按我以前的思维来思考，一个软件功能越多就说明它越好，一个软件使用的技术越复杂高级它就越好，但在课程中我这种想法逐渐改变，把一个软件和一件商品产品联系在了一起，相比较软件本身技术开发，更要考虑用户体验，以及场景的描述，需求分析等各个方面来考虑，一个复杂完美完备的软件可能并不会大火，而一个能够实际解决用户问题，解决用户“痛点”的软件，无论多简单，它都是一款“成功”的软件。
在自己的学习过程中也遇到过很多问题，在简单的Mis系统一窍不通的情况下，查看视频来学习但如何也找不出错误经过半天查找最后成功的那种成就感，是无法用语言来描述的。让我第一次最兴奋也是最投入的一段时间就是双人结对任务的“石家庄地铁”，我在一星期内废寝忘食，利用一切空闲时间来完成它，虽然没有达到最完善最完美的地步，但当他能够正确显示，按照我的思路进行计算的时候，让我整个人都好像飞起来一样感觉自己的努力终于没有白费。
这学期的代码行数，课堂练习有2000+行，地铁项目1500+，团队项目个人3000+，日常学习3000+，不算入其他学科的话，应该有10000+的代码量。
在学期后段则是团队项目的开发，在团队项目开发过程中遇到了很多问题，首先则是团队模式“主刀医师”与“递刀医生”的模式，可能发生过一些不愉快的事情，像“打酱油”，“消极怠工”，但这种模式估计也只有在固定编制，或者在学校中才可能存在。对我自己来说，如果自己身处一个团队之中，必须要保持团队和谐，而这和谐最基础的便是自己对这个团队有一定的付出，并且有认真负责的态度，但经过一次团队项目的经历，我了解了团队分工以及最简单的绩效评估和工程流程经历，这是难能可贵的。对于团队项目有很多内容都是现成的控件，自己并不甚了解，感觉还需要继续学习，学习无止境！
以上仅为个人的感受与看法，如有错误，还请指出。
对于给老师的问题：
1.不知道老师可不可以给出一些具体的成功的软件需求的例子以开阔思路？
2.面对团队分工，产生的矛盾以及负面情绪要如何调节或处理？
3.对于现在的我来说，还不是很清楚测试工作应该如何去测试，有没有相关实例供以参考？
标签：限制 重要性 开发 模式 产生 需要 检验 团队 判断
原文地址：https://www.cnblogs.com/zlc364624/p/11033001.html
