软件心得体会范文4篇

我应该是对maya第一阶段的学习有一个初步的认识了，在接maya之前一直觉得这个软件很神秘，当栩栩如生的三维动画就是用它制作出来的，我又对这个软件产生了几分“爱意”。带着这份“爱意”我到清美报名了，接待的老师很热情，教学老师也很认真负责，这里不累赘阐述。下面就我第一阶段的学习作一个简单的学习心得汇报：

maya软件的主要有四个模块：maya建模、maya动画角色建模、maya材质灯光、maya角色动画、maya后期特效。我首先接触到的就是建模，想学好三维动画，当然要把这个maya角色建模学好啦。三维动画的建模主要有：a、nurbs曲面建模技术。b、polygons多边形建模技术。c、subdiv细分建模技术。当李老师给我们上完第一堂课后，我对maya的“爱意”就全消了，因为软件基本都是英文，而我又是一个英语盲，除了简单“thank you”之外估计就说不出完整的第二句，加上翻了一下教材，难度之大完全触及了我的底线。

当然“爱意”顿时消退，可是我还是很认真地去学，鉴于我个人的职业发展方向的需求和动漫产业的朝阳性，我的学习动力依旧，老师也很负责地在教授。由于写速度慢，又写得不好，所以上课做的龙飞凤舞的笔记也只有我自己看的懂，乱七八糟的圈圈叉叉中蕴涵着大致内容和操作步骤，整个上午所要学的东西很多很繁琐，动手操作时脑袋时常会混淆一些东西，导致步骤混乱，所以做我做起东西来会很慢。好在我们上课的时候都人手一机，可以及时消化，在不至于打乱仗。

经过老师多天来的孜孜不倦的教诲，以及自己的勤学苦练。一个月后自己终于可以动手做出完整的模型了，嘿嘿……虽然做出的东西还比较粗糙和幼稚。经过几天的鏖战，最终做出了机器猫，那个得瑟劲不知道大家能否体会，让我也有了无比的成就感。当然现实是残酷的，在我得瑟完毕静下心来，把自己做的模型和参考的图片进行比较时，我才认识天壤之别是什么意思。这种差距源自于两者的创作意图，源自于时间的磨砺，源自于经验，文化和技术的沉淀，快餐和速成文化对我们这代人的影响等等等等。这些都是我从两幅作品的对比中体会到的。作品本身不会说话，却可以感染我这样去想。

于是我此时此刻深信一句话“学习是没有捷径可言的，唯一的捷径就是不断的学习和练习，只有这样才能学到真功夫”。我学maya还只迈出了第一步，路漫漫其修远兮，吾将更加努力。我也相信在李老师的教导下，我在清美一定能学到更多的东西。以后的学习心得我会慢慢更新，希望有同样经历的朋友能够多多交流!

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

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

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

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

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

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

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

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

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

二、一定要注意多做demo，多做实验，一个demo程序员几个钟头就可以完成，甚至更少，但是不做demo，核心程序没有做实验，其他的东西都围绕核心程序做了上去，到时候耽误的可不是几个钟头

三、程序设计要注重用户体验，当初客户对我要开发软件提出近乎苛刻的要求时我不在意，但是当我自己反复使用软件时有了很多体会，流畅美观的界面带给人心理的快感的确能替代一些尚未开发完整的功能带给用户的遗憾。

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

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

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

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

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

- 经历过历练的人

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

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

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

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

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

- 坦诚、坚定、平和的人

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

我曾经遇到一个，面试下来，我最后介绍我们产品中用到的技术，他对这些技术知之不多，最后他说，“我可能不是非常适合，我知道一个朋友，他可能更适合。”我综合评估后，最后还是选了他，事实证明，他后来做的很不错。

坦诚坚定的人，会有恒心去学习，去解决问题。这些人员会作为team的基石。

- 有缺陷的人才

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

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

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

- 太活泼，太易兴奋

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

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

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

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

经过潘老师讲授软件工程实践后，感觉对软件工程这门学科有了深一层的认识。软件工程是一门重视实际操作的科学。对于软件产品，无非是产品定义、设计代码、调试维护几个步骤，看似简单，可是实际操作却复杂困难，它不比其它行业产品可预见可触及，所以学好软件工程能为以后从事软件开发行业打好基础。

在软件实践这门课中，讲到了有效利用现有资源进行软件编程的方法。提到软件开发也可以像练习书法一样，采用临贴的方式，借鉴他人的优秀代码资源。临摹优秀软件是学习软件开发的一个重要方法。正如一首诗中说的：“熟读唐诗三百首，不会写来也会吟”。软件开发也是一个道理。为了真正地掌握软件开发的技巧，“临贴”是个不错的起步方法。

以前总是觉得，既然编写一个程序，就应该完全靠自己，那样写出来才有成就感，才算是自己的程序，可是这门课程教会我原来适当地借鉴别人的东西，也不算抄，相反，还可以提高效率，节省时间。这可真是与以往的观点不一样了。具体如下：

“软件编程，拿来主义的作用很大：

1、源代码交换方便。

2、可行的例程序用处大。

3、借鉴现成少走弯路。”

不过借鉴别人的东西可是有说法的，可不是盲目地抄袭，下面是一些提到的途径：

1、既有系统：借鸡下蛋，买来就用;

2、书本例子：简单修改、直接使用;

3、联机或联网帮助：帮助文档、官方支持;

4、开放软件源代码：linux apache eclipse …

5、互联网资源:论坛、搜索引擎、新闻组

借鉴过来后，还要多方面综合考虑，比如说代码的具体作用，完整性，还要考虑每个借鉴过来的东西的好坏。这些都要多方面考虑，可不能因为前面说软件编程可以借鉴别人的，就盲目地抄袭。到时候代码弄一堆凑在一块儿，谁也不知道它们会不会好好工作。弄不好乱了程序计划是小，公司的损失可不是哪个人都能承受得起的。

课程还提到，应该用一个小项目先从头到尾地练完，这样，有个整体性的了解，可以增加不少开发经验。看来，不学习此门课程，还不能深入地解读软件工程的奥义。这门课程为我们深入地了解软件工程这个庞大的前沿学科起到了推动性的作用。以上是我就此门课中提到的众多方法的一小段做的一些浅谈，更多的知识还在于我们自己去学习体会。

下面简单谈谈我的几点体会：

体会一：软件测试在整个软件周期中的重要性。

它存在于整个项目周期，在项目开始之初需求调研的时候就开始了，在形成需求规格说明书的时候就需要针对文档进行测试。这个环节在后续整个项目中占了很大的比重，能主导整个项目的走向，成败与否全在于开始阶段的决策。

体会二：软件测试的真正意义在于发现错误，而不在于验证软件是正确的。

再严密的测试也不能完全发现软件当中所有的错误，但是测试还是能发现大部分的错误，能确保软件基本是可用的，所以在后续使用的过程中还需要加强快速响应的环节。结合软件测试的理论，故障暴露在最终客户端之前及时主动的去发现并解决。这一点就需要加强研发队伍的建设。

体会三：在系统性能测试方面需要重视。

经过这次培训中多个案例的讲解，让我了解到系统在上线之后会有很多不能预知的性能问题，需要在上线之前实现进行模拟，以规避风险，包括大数据量访问，高并发数等等。

当然也有很多应对手段，没有哪种手段可称为最完美，只有最合适的，需要灵活掌握，综合运用以达到最优程度，这是个很值得研究的领域。

下面是本人的几点想法：

想法一：加强系统上线前的性能测试。

目前我们在项目建设过程中对性能压力测试的重视程度还不太高，厂家也很少有雇佣第三方的测试机构。而是在现网进行试用，遇到问题再解决，可能会产生滞后问题，影响客户使用。希望以后能在性能测试方面提高重视程度，加大人力投入，以保证系统上线后能够稳定运行。

想法二：适当介入相关项目研发

对于快速响应这块，我们不能一味依赖厂家，而希望自己就能快速响应，及时将问题解决。这也是一个比较长远的问题，需要加强研发力量的投入。

我个人是做开发出身，有此类经验，当时是在客户现场，因为了解系统内部结构，能够在第一时间排查解决客户所反馈问题。

现在系统完全由厂家开发，很难了解内部结构，或许会造成后期维护困难。所以，是否应该针对某些项目介入厂家研发工作，比如请厂家提供源代码等相关要素，以增进维护人员对系统的了解。

最后再次感谢公司提供的平台，感谢领导的信任，让我有机会得到更深层次的学习以及展示自己能力的机会，我也会尽我所能来完善工作的系统，提高整体工作效率，为南方电网的发展建设提供更坚实，优秀的支撑服务平台。