软件心得体会4篇_心得体会范文_

软件心得体会4篇

软件工程一

时间过的很快，转眼间已经实习将近5个月，其中有2个月是属于完全被流放的。

最先在内部系统组参与内部管理系统开发(struts+mysql+spring+hibernate)，之后是去做网络交换机软件的脚本测试。现在又回归内部系统，虽然在脚本组期间，编码能力被别人甩在后头，但至少具有了一些测试经验。

至少自己做的东西，是真正交付到了客户手上，到也稍微有些成就感。

1、浅谈测试

一直以来，我都认为测试是脱离了软件工程范围的工作，不以为屑。但在实际情况中，测试是既重要且难以精湛的.其真正的压力，在于找不到bug，责任在你，而不在于编码人员。一般的测试人员不懂编码，他们靠的是日以累计的经验总结和想象力。而要做到高级测试工程师，则一定要懂编码，因为这是你完全掌握整个系统的方方面面具体运作的前提。但占主导地位的，还是大型系统的集成测试经验。实际项目中，编码时间一般只占30%左右，真正耗费时间的是it阶段的找 bug与对应bug，此阶段基本评定了coder的编码质量。

2、程序员的困惑

有些人，以为教学视频和代码看多，自己就懂的多，实际做起来，却不知从何下手，问题在那?如何定位?如何解决?通通跟一样能力有关，debug追踪能力，也称调试。在项目组工作不愁源码资源，但问题是蛋糕摆在面前，你如何去消化?

有位同事告诉我：代码看几遍都没用，要去抄，例如一个查询模块，在此基础上去做具体记录的历史记录查询模块，你可能会觉得很简单，但实际情况却往往报一堆异常，配置问题涉及到方方面面，以及数据库段，传值问题等等，一大堆对于新人来说很郁闷的问题。但不用怕，只要学会调试，一个个问题去追踪，一个个去解决，自然而然，那段“源码”才真正属于你。

3、如何调试追踪

如果你能在短短的时间内就看到问题点在那，放下断点去追踪，出去找工作，绝对没问题。出现问题的时候，不要光看代码，要用实际行动去追踪运行期间的具体值，那是最好途径。eclipse是个很爽的ide，这点做的很好。例如页面内容显示不是自己想要的数据，我们要先从数据库查询语句去下手，设置断点，一步一步step over，让sql段(存取最终sql语句的符串)运行到有值，inspect进去看，如果还看不出来，就点击它，copy后在sql客户端去实际运行，看看实际查询出来的表是什么，如果是对的，有可能就是页面调用的错误或者action逻辑的传值问题。

页面错误的调试，基本方法是用右键点击实际网页查看源代码，copy到editplus，就能看到具体错误发生在那几行。通常有几种常见的错误，例如：缺少对象这种很多时候是有些被你调用的段有可能为空的情况出现的，可以加if(=null)语句加保护。追踪的方法基本就是用alert语句，放在有可能出错的地方。

4、一些习惯

遇到问题先自己思考，无从下手再找高手帮忙看看，注意他帮你看的思路，别在一旁闲着，看多了自己也会了，不然你一辈子都停留在那种水平，从人身上学到的东西远远比书多的多。

解决了一个问题后，要去究根问底去找到问题产生的起因，以防你下次遇到类似的问题再浪费同样的时间。

把代码写的漂亮，注释、空行、规范一样不能少，可读性是放在第一位。曾经看过一个高手写的代码，真的一看就是不同水平的人写的，几乎很完美，读起来很流畅，方便自己也方便别人。

任务完后不要呆着，去要求经理给你更有挑战性的任务，只要你肯去尝试，他们就会对你另言相看，把三天的任务一天加班搞定，效率和忠诚都有了，路也比较好走了。

软件工程实习心得体会二

在这次软件工程课程中，我学到了很多东西，第一次深刻的体会到了什么叫做用工程化的思想来编写软件，以前自己也写过一些小型软件，没有做过大型的项目，直到这次课堂我担任组长并组织组员共同完成“个人图书管理系统”这个项目，第一次和别人合作，才发现运用工程化的思想来做是如此的有必要。

从这里，我才真正的意识到实施一个软件工程并不是说简单的会编码就能够解决问题的，我们更多的精力不是放在编码上，编码只是一个很小的模块，只占到那么小的一个部分。这个事实在很大程度上颠覆了我以前的思想，在我以前的认识中，似乎整个软件就是编码，除此无它，还好有老师的指导，不然真的会出现老师所说的，撞得头破血流之后才想起来用软件工程的思想来完成这个工作。

刚真正开始工作之前，我们费了很多的时间来完成一些前端工作，如需求分析和可行性分析，这块工作在别人看来可能是相对无关紧要，甚至是多于的，其实，换做在以前，我也会这么认为。可是，我现在算是深深地明白了磨刀不误砍柴工的道理，这些工作的完成太有必要了，太重要了，要想你的软件有用有市场，能被别人接受和认可，在进行过程中不会出现崩溃性的问题，这些工作缺一不可。

还有就是接下来的一些设计模块，此模块与软件编码涉及比较紧密，主要是解决一些参数传递和接口通讯的问题，此模块对我的触动远没有上两个模块对我的影响大，因此再次也不做过多的介绍。

在整个活动的完成过程中，作为组长，我收获很多，我发现，要是组里有个人不怎么想做事情时，他对于整个组织的影响是毁灭性的，正所谓“一颗老鼠屎，能坏一仓谷”，以后我的组织里要是出现这样的人，我绝不会给他继续留下来的机会，我会在第一时间将他清除出去。还有就是，作为组长，你要做的最重要的事情，不是发挥自己的聪明才智，而是创造出一个平台，让别人去发挥，你所要做得，出了保证这个平台的完整性和公平性外，还有就是协调好各组员之间的关系。

这就是我的实习感想。

受某文化公司委托，开发一款用于视频和图像处理的软件，开发难度高，高到从未搞过，开发周期长，长到是我以前项目监控最长开发周期的两倍，开发成本之底，让我觉得程序员成了高级打员。首先是需求分析书、产品规格、设计说明书、代码规范说明书、测试计划，光文稿就不知道熬了多久才做完。

紧接着，遇到一系列问题，首先是语言选择，vc++和c#都是可以保证开发完成的选择，但是vc++内存容易报错，界面很难修改，而客户要求的界面质量甚至比程序的功能更严格，没办法，客户就是上帝，上帝做事一定有他的道理。c#语言易于开发，而且图形界面绘制也易于修改，可以做出客户体验很好的界面，但是在资源的消耗上，让我很吃惊。做到第二个月，大概的界面已经完成时，出现界面刷新的问题，刷新时开始卡，界面不流畅。没办法，改。

开会，总结，技术骨干找问题，拿出解决方案，力争第一次做软件把它做好：

重新做软件开发进度计划和软件测试计划，并且让独立功能demo制作和测试先行；

用direct draw、direct 3d或者opengl中的一个替代c#本身的gdi绘图，将在接下来的开发任务中加入进去。

事无巨细，当我满意的看着界面流畅，功能也已实现时，发现软件在低分辨率或者小本上根本乱到没法看，甚至是界面功能按钮错位，重叠等等。没办法，改。毕竟软件的多分辨率兼容和操作系统兼容是必须要做的。

接下来一大堆的麻烦找了上来，软件出现各种各样想都想不到的问题，总算是按时将第一个版本发布出去，并且开始接下来的升级开发任务。

最后，给刚刚接手软件开发项目的朋友一些忠告：

一、相关的文档不是给别人看的，而是给自己看的，相关文档一定要齐备，而且让所有涉及开发的人员都清楚的知道你文档里所要表达的意思；

二、一定要注意多做demo，多做实验，一个demo程序员几个钟头就可以完成，甚至更少，但是不做demo，核心程序没有做实验，其他的东西都围绕核心程序做了上去，到时候耽误的可不是几个钟头 三、程序设计要注重用户体验，当初客户对我要开发软件提出近乎苛刻的要求时我不在意，但是当我自己反复使用软件时有了很多体会，流畅美观的界面带给人心理的快感的确能替代一些尚未开发完整的功能带给用户的遗憾。

四、测试计划多次进行，分批进行，不要全部开发完成再对软件做测试。

还要坚持三个月，软件马上发布，希望大家的支持，谢谢

软件开发心得体会（2）：

作为pm，有时需要招聘软件开发人员。这几年也一直在想，如何能在短短的30分钟或1小时内，快速识别出，坐在你对面的应聘人员，是否适合你的team。这几年也一直在观察和反思，经历过的team和现在team中的软件开发人员。有几点小的心得。

1. 倾向于招什么样的软件开发人员

- 经历过历练的人

吃过苦的，比如以前工作，经常被外派出差，又如曾在业内都知道以加班多而著称的公司呆过，还有些，留过学，但都是自己边打工边读书的，等等。

这些人员，入职后，通常都是能干活，能作为骨干。

- 思路清晰，思想活跃的人

让谈谈自己现在的产品，如果能清晰表述，有条理，会发散，但又能适当控制住，并收回到原话题。谈到技术问题和解决过的难题时，眼中有光芒：）

这些人员，今后工作中，学习能力强，对解决难题有帮助，能作为中坚。

- 坦诚、坚定、平和的人

面试中，坦诚，目光坚定。有时坦诚到甚至于显得有点木讷：）

我曾经遇到一个，面试下来，我最后介绍我们产品中用到的技术，他对这些技术知之不多，最后他说，“我可能不是非常适合，我知道一个朋友，他可能更适合。”我综合评估后，最后还是选了他，事实证明，他后来做的很不错。 坦诚坚定的人，会有恒心去学习，去解决问题。这些人员会作为team的基石。

- 有缺陷的人才

这是一个朋友（lance）的想法，我认为还是有道理的。

大公司，会看重综合素质，而如果是小公司，可以考虑选择一些有缺陷的人才。所谓有缺陷，是指，比如他英语很差，或沟通不清晰，但他能用程序员该有的思维去思考问题。这样的人员，通常进不了大公司，故会相对踏实地呆在一家公司，做好自己的工作。

2. 谨慎考虑这样的开发人员

- 太活泼，太易兴奋

太易兴奋，说到投机处，“是是是是，对对对对。。。”，又蹦又跳，还时不时来点，“oh yeah, you are right“，然后还摆个 v 手型。讨论问题，不易固守在技术问题本身，时常跑到“我们产品中用到的技术（或第3方产品）很强，我挺他们，不可能有问题”，又或者“我们对客户要强势，我们要坚持我们的产品没问题"。

软件开发工作本身，显得比较沉闷，优秀的技术人员，都略显有些内向，因为解决问题，很多时候需要耐得住寂寞，时刻保持相对冷静。

太活泼的人，会在遇到问题之初，表现出很强的冲劲，但当长时间不能解决时，会表现出没有耐心，会经常抱怨（对team、管理、产品、流程等），非常情绪化。有些女程序员还会吵，会哭，这时项目经理只能放下手中的活，下去给她买点零食来哄哄，“莫哭，这里有你最爱吃的猫哆哩。”一边擦着鼻涕、眼泪，一边嘴里塞满东西，鼓鼓啷啷“这是酸角口味的，那个西番莲口味的才叫好吃..."

这些通常不太容易在面试时表现出来，在试用期时，要观察。

通过实训中心老师的课堂讲解与企业化标准的培训，使我加深了对自己专业的认识。从而确定自己以后的努力方向。要想在短暂的实训时间内，尽可能多的学到东西，就需要我们跟老师或同学进行很好的沟通，加深彼此的了解。只有我们跟老师多沟通，让老师更了解我们，才能跟真切的对我们进行培训工作。由此，班级的文化“共享”