大型软件开发心得精选多篇Word格式.docx
《大型软件开发心得精选多篇Word格式.docx》由会员分享，可在线阅读，更多相关《大型软件开发心得精选多篇Word格式.docx（15页珍藏版）》请在冰豆网上搜索。
2、原有功能的去留
我一直觉得升级已有产品比开发新产品难一些。
这就像栽培植物一样，新种下一棵果树无非需要选对了土地，然后刨个坑种下去，然而成长期的去病枝、打顶等各种修剪所消耗的精力往往更多。
改进已有产品常常需要面对一个最棘手的问题：
原有功能是去是留？
原功能去掉的话是不是会影响部分用户使用？
是否需要通过公告、站内信、界面引导等方式友好地告知用户？
怎样把对用户的伤害降至最低？
原功能留下的话是不是可以优化完善？
听到了什么用户群怎样的声音？
是否要在这次升级中做调整？
这些问题当接到项目的时候，产品经理就应该考虑周全了。
特别需要注意的是，如果这个产品之前不是自己设计的，那么最好找到prd说明文档细细研究一遍，对把握不准的功能点找到原负责人确认，毕竟树苗是ta摘的，别把将来最能结果的枝干给砍了。
3、产品线上下游的对接
昨天有跟朋友聊起淘宝强势之处，就是产品与产品紧密捏合，线上线下、跨平台跨行业形成了一个盘根错节、根深蒂固的根基，无可撼动。
所以把握产品线上下游和产品周边很重要，即使一个看似简单的新闻展示页面修改也会牵扯到编辑后台、广告位管理、帮助中心，甚至是访问统计、数据需求的变更。
这要求在产品设计开始前，需要把该产品“连根拔起”，仔细梳理相关脉络，如果产品线够长，一个清晰的产品线结构图很有必要。
项目中
1、项目期间来自相关产品线调整的影响
项目期间相关产品线的调整是我最不愿意遇到的情况，这就像你在通往目的地的道路上高速行驶，就快要到达终点了，突然一个人告诉你：
你走错路了。
项目里有一个通用模块，产品设计到一半，这个通用模块改了；
项目里有一个流程，产品做到一半，这个流程废弃了；
最要命的是已经立项开发了，你不得不硬着头皮跟程序员说：
“因为一些不可抗拒原因，这个需求咱不做了。
”
对于一个耗时较长的项目来说，这种情况难以避免，事出原因私自总结有三：
a、严重体验性问题：
例如某个流程遭到大量用户的不满，为防止用户流失，不得不做临时调整，而倒霉的是，你也在用这个流程。
b、相关项目的影响：
包括并行项目和新项目。
例如你的同事在设计另一个产品，你们的产品相互牵扯较多，所以需求分析时做过很多沟通，但有一天，同事告诉你，ta的一个需求做临时调整了会影响到你，怎么办？
c、老板的突然决定：
不举例。
最终的解决方法不外乎三种：
立即调整、延期调整、不调整。
个人的处理原则一般是对a种情况进行立即调整，对b、c情况讨论并选择性延期。
为什么这么做呢？
a情况是必须要改的，时间早晚问题，长痛不如短痛，b、c两种情况必须坐下来细细讨论。
需了解这个需求为什么要改？
是长期对策还是临时决定？
能否延期，记录需求等下一版本再开发？
如果b、c情况提出来的需求没过两天又有改变，那与你配合的前端和程序员也太没有安全感了。
这个时代能耐心阅读完xx枚汉字的人越来越少，较大型项目的产品工作心得[下]未完待续，欢迎交流……
2、需求变更
承上，需求变更是每个程序员、产品经理、设计师等都会遇到的情况。
产品经理不是神，项目组也不可能是开了无敌状态抵挡任何外界的影响。
当遇到不得不变更需求的时候，产品经理应该怎样处理呢？
下面是个人的四条建议：
a、积极处理。
往往，当一个设计愈是趋于完成，人们愈是倾向于局部调整，而不是做重新设计。
当一个需求因为众所周知的原因不得不调整的时候，作为产品经理需要做的第一件事便是积极面对问题，积极处理。
项目开发往往是一个紧张的过程，每半天甚至每几个小时就有若干个功能点开发完成，当一个需求变更传达出现“延迟”，这个变更对项目的正常进程的“破坏力”就会更大一些。
b、保持沟通。
“说话容易，沟通很难。
很多事除非对方自己想明白，劝是没有用的。
所以，很多时候，沟通是个自己挣扎的过程”这话没错。
需求变更直接会影响到下一道工序，产品经理需要将需求变更的细节和原因传达给相关人员，包括视觉、前端、程序、测试等。
这是很多产品经理表示非常痛苦的过程，因为可能会遭到数落和冷眼，日本有一个礼仪原则是“不要给别人添麻烦”，但是在项目中，这不可避免。
个人认为所有沟通的障碍都源于思想的不统一，如果让大家觉得这个需求修改是在浪费时间，那么沟通上的不畅快在所难免。
项目不是这样算的，需求既然更改一定有所目的，产品经理需要将这个原因讲明白，不做修改或节约沟通时间导致的返工，后果往往更严重。
第二篇：
软件开发心得体会
受某文化公司委托，开发一款用于视频和图像处理的软件，开发难度高，高到从未搞过，开发周期长，长到是我以前项目监控最长开发周期的两倍，开发成本之底，让我觉得程序员成了高级打字员。
首先是需求分析书、产品规格说明书、设计说明书、代码规范说明书、测试计划，光文稿就不知道熬了多久才做完。
紧接着，遇到一系列问题，首先是语言选择，vc++和c#都是可以保证开发完成的选择，但是vc++内存容易报错，界面很难修改，而客户要求的界面质量甚至比程序的功能更严格，没办法，客户就是上帝，上帝做事一定有他的道理。
c#语言易于开发，而且图形界面绘制也易于修改，可以做出客户体验很好的界面，但是在资源的消耗上，让我很吃惊。
做到第二个月，大概的界面已经完成时，出现界面刷新的问题，刷新时开始卡，界面不流畅。
没办法，改。
开会，总结，技术骨干找问题，拿出解决方案，力争第一次做软件把它做好：
重新做软件开发进度计划和软件测试计划，并且让独立功能demo制作和测试先行；
用directdraw、direct3d或者opengl中的一个替代c#本身的gdi绘图，将在接下来的开发任务中加入进去。
事无巨细，当我满意的看着界面流畅，功能也已实现时，发现软件在低分辨率或者小本上根本乱到没法看，甚至是界面功能按钮错位，重叠等等。
毕竟软件的多分辨率兼容和操作系统兼容是必须要做的。
接下来一大堆的麻烦找了上来，软件出现各种各样想都想不到的问题，总算是按时将第一个版本发布出去，并且开始接下来的升级开发任务。
最后，给刚刚接手软件开发项目的朋友一些忠告：
一、相关的文档不是给别人看的，而是给自己看的，相关文档一定要齐备，而且让所有涉及开发的人员都清楚的知道你文档里所要表达的意思；
二、一定要注意多做demo，多做实验，一个demo程序员几个钟头就可以完成，甚至更少，但是不做demo，核心程序没有做实验，其他的东西都围绕核心程序做了上去，到时候耽误的可不是几个钟头
三、程序设计要注重用户体验，当初客户对我要开发软件提出近乎苛刻的要求时我不在意，但是当我自己反复使用软件时有了很多体会，流畅美观的界面带给人心理的快感的确能替代一些尚未开发完整的功能带给用户的遗憾。
四、测试计划多次进行，分批进行，不要全部开发完成再对软件做测试。
还要坚持三个月，软件马上发布，希望大家的支持，谢谢！
！
软件开发心得体会
（2）：
作为ｐｍ，有时需要招聘软件开发人员。
这几年也一直在想，如何能在短短的30分钟或1小时内，快速识别出，坐在你对面的应聘人员，是否适合你的team。
这几年也一直在观察和反思，经历过的team和现在team中的软件开发人员。
有几点小的心得。
1.倾向于招什么样的软件开发人员
-经历过历练的人
吃过苦的，比如以前工作，经常被外派出差，又如曾在业内都知道以加班多而著称的公司呆过，还有些，留过学，但都是自己边打工边读书的，等等。
这些人员，入职后，通常都是能干活，能作为骨干。
-思路清晰，思想活跃的人
让谈谈自己现在的产品，如果能清晰表述，有条理，会发散，但又能适当控制住，并收回到原话题。
谈到技术问题和解决过的难题时，眼中有光芒：
）
这些人员，今后工作中，学习能力强，对解决难题有帮助，能作为中坚。
-坦诚、坚定、平和的人
面试中，坦诚，目光坚定。
有时坦诚到甚至于显得有点木讷：
我曾经遇到一个，面试下来，我最后介绍我们产品中用到的技术，他对这些技术知之不多，最后他说，“我可能不是非常适合，我知道一个朋友，他可能更适合。
”我综合评估后，最后还是选了他，事实证明，他后来做的很不错。
坦诚坚定的人，会有恒心去学习，去解决问题。
这些人员会作为team的基石。
-有缺陷的人才
这是一个朋友（lance）的想法，我认为还是有道理的。
大公司，会看重综合素质，而如果是小公司，可以考虑选择一些有缺陷的人才。
所谓有缺陷，是指，比如他英语很差，或沟通不清晰，但他能用程序员该有的思维去思考问题。
这样的人员，通常进不了大公司，故会相对踏实地呆在一家公司，做好自己的工作。
2.谨慎（请关注）考虑这样的开发人员
-太活泼，太易兴奋
太易兴奋，说到投机处，“是是是是，对对对对。
。
”，又蹦又跳，还时不时来点，“ohyeah,youareright“，然后还摆个v手型。
讨论问题，不易固守在技术问题本身，时常跑到“我们产品中用到的技术（或第3方产品）很强，我挺他们，不可能有问题”，又或者“我们对客户要强势，我们要坚持我们的产品没问题”。
软件开发工作本身，显得比较沉闷，优秀的技术人员，都略显有些内向，因为解决问题，很多时候需要耐得住寂寞，时刻保持相对冷静。
太活泼的人，会在遇到问题之初，表现出很强的冲劲，但当长时间不能解决时，会表现出没有耐心，会经常抱怨（对team、管理、产品、流程等），非常情绪化。
有些女程序员还会吵，会哭，这时项目经理只能放下手中的活，下去给她买点零食来哄哄，“莫哭，这里有你最爱吃的猫哆哩。
”一边擦着鼻涕、眼泪，一边嘴里塞满东西，鼓鼓啷啷“这是酸角口味的，那个西番莲口味的才叫好吃...”
这些通常不太容易在面试时表现出来，在试用期时，要观察。
第三篇：
软件开发心得总结
有感于网盘开发过程
有感于网盘开发过程............................1
一、软件开发个人体会：
......................2
二、做软件开发我觉得要明白：
........................2
三、在开发中遇到问题应该怎么去解决？
................2
四、怎么样才能提高自身的能力？
.....................2
五、怎么样才能做好软件开发？
六、文档的重要性...........................3
七、我的收获............................3
八、网盘项目开发的最大体会.....................4
九、软件测试（单体测试和连接测试）....................4
常熟理工学院sig小组3/28/2014
1.软件领域中的知识在于积累。
2.做软件开发，就类似算数学题和世界杯足球赛一样：
重在结果，而不在乎过程。
3.软件服务于人类，软件是在解决一些生活中的问题和错误，问题决定解决方案。
1.职业的乐趣：
（a）用自己的智慧去创建新事物的快乐
（b）开发对别人有用的东西
（c）不断学习来充实自己
2.职业的苦恼:
（a）总是追求完美
（b）所有要实现的功能由他人而定
（c）概念设计计是有趣的，但找bug总是很苦恼的
1.
2.
3.
4.不明白就多问，不要自已一直去琢磨。
一个问题如果30分钟还没有解决就应该考虑是不是问问别人。
一个问题在没有用过3种以上的方法解决过就不要去问别人。
解决问题思路是关键：
相信问题总归有解决的办法，就算连技术上都没法实现的问题，相信通过良好的沟通终究也会有解决的方法。
5.解决问题的前提是：
理解别人的意思，理解别人的需求，多沟通，及时给客户反馈信息。
1.程序员怎么样进步最快？
－理论结合实践
2.不要怕出错，不怕遇到错误，有错误就有挑战，这样才可以进步，但不要让同一个石头
把你绊倒2次。
1.首先要明白解决的问题是什么，理解问题，其次再决定怎么解决这个问题
2.碰到很复杂的问题，我们就简单想，把问题简单化，细化到能够实现为止
3.出了问题，我们要先分析问题，然后知道引起问题的原因，最后并想出问题的解决办法
4.我们应该从2个方面去把握一个项目：
从业务角度和项目的关键问题上去把握一个项目
（a）从不同的系统场景
（b）从不同的用户角色（充当什么角色）
（c）从不同的系统使用角度（拥有那些权限）
5.其实我觉得开发人员说实在应该要比使用系统的人更了解系统需求，只有真正彻底的了
解了项目的业务需求，我们才能做真的做好这个项目
六、文档的重要性
记得我当初刚开发项目的时候都是写个大致的需求说明书，做一个e-r图，画几个大致的数据流程图，然后建立数据字典和表结构关系。
再接着搭建一个开发环境，配置几台服务器，划分一下模块，分工，我们就可以coding了，一直到项目结束了，也没有完整的设计文档，更没有完整的测试文档，虽然这样的确是很快的完成了coding工作，感觉上好像节省了好多成本和开发时间，但后期的维护和bug就是经常出现的事。
小项目没有文档关系不大，但如果遇到一个大项目的时候，那这样的开发方式就很有问题很危险的。
大项目没有文档：
首先维护就很麻烦，也很乱，写的代码，过几天都不知道它是完成什么功能的了，其次系统的稳定性和可靠性也让人怀疑，扩展性就不用说了。
七、我的收获
a.程序员大多都不喜欢写文档,我们以前也是特讨厌,记得以前都是系统开发完了，为了应付项目验收，就匆匆忙忙的一组人在那里补文档。
在我们的思想里,所谓的文档就是一些废话,一句话硬是用十句话来代替的无聊透顶。
b.代码风格要规范
以前做项目，我们都是不怎么去注意代码风格和写代码的规范，都是稍微想一下就直接开始写代码了。
注释也很少用，总感觉我们自己写的代码，我们怎么会不知道它做了些什么事呢？
总觉得我们自己写的代码我们怎么会不知道它是用来做什么的呢。
一直都不相信这是个事实，但事实上，项目验收后，系统刚开始使用的人少，也就不会出现潜在的错误，随着时间的增加，久而久之，当大量用户并发访问的时候，系统的bug就暴漏出来了，那时你再用熟悉的eclipse打开整个项目的源码时，再去看自己写的代码的时候，真的发现，我们定义的这个变量名是什么意思啊？
我们的这个flag是用来判断什么的啊？
我们的if（）中条件不知道是判断什么？
function（）也忘记是什么功能了？
想想好可怕啊。
难道真的都忘记了吗？
回答是肯定的：
真的忘了。
c.心得体会:
通过做该网盘项目，在这2年的锻炼中，我们才真的体会到，良好的文档是正规研发流程中非常重要的环节,一个好的程序是先写好设计文档再进行编程的，在设计文档的指导下，才能写出安全的代码。
如果你不写文档，一开始就写程序，这样你就不会按已设计好的路线走，而是想到哪写到哪。
小功能还好说，要是大功能，就容易混乱.
刚开始我们还很不习惯这一系列的编程风格，很多的规范，尤其是命名，方法和注释，都有这着很多限制，让我们觉得真罗唆，写个程序完成功能不就可以了吗，明明1小时做完的事情非得让人用3、4个小时去做，我们现在真的明白这样做的好处了，我们已经习惯这样的编程风格了，这也养成了我们的一个编程习惯了，深有体会啊。
最忙的时候就是我们成长和收获最多的时候。
八、网盘项目开发的最大体会
我们觉得项目开发的开始时候，应该由项目负责人很好的对项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题，以及里面用到的很多专有名词做个细致的说明，而不是从一开始就分几本式样书，给个静态html的demo看看，然后搭建好开发环境就按照式样设计书来开发。
九、软件测试（单体测试和连接测试）
我们首先认为，编写程序的时候不要想出了问题再解决，而是要想如何不会出现问题，要根据经验来预测可能出现的问题，然后避免出现。
测试，说的直接点就是给软件找错误。
很多人认为发现错误是软件测试的唯一目的,查找不出错误的测试就是没有价值的测试,实际上我们不这么认为。
我们觉得对开发人员来说，我们要把测试出来的bug都应该做个分析，知道错的原因之后，我们就应该在下个项目中防止类似的错误发生，而真正来提高我们开发的效率。
第四篇：
软件开发实习心得
一直以来期望从事自己喜欢的事业的我，对软件开发有者及大的兴趣，可由说种种原因使我从事工作以来走了好几年弯路，心中的梦想迟迟不能得以实现，可程序员的梦想从来没有从我的心中抹去，但这扇大门好像并没有向我敞开，今天，贵公司给了我敲开这扇大门的机会，让我真实体验了程序员的诞生过程。
早就听说，程序员的前几个月是最苦的，可从来没有感受到，海马实习基地让我提前感受到了刚刚进入软件行业的压力和困惑，再也没有在自己家里随便写段小程序后的那种“自豪”感了。
要面对每天必须面对的问题，再也不可能以“逃避”而了之了。
也让我感觉到做为一个程序员所应该具备的基本素质在这不到一个月的实习过程中也让我深深体会到了作为一个合格的程序员应该具备的基本素质。
团队精神和协作能力是程序员应该具备的基本素质，最近的工作中让我深深休会到了这一点，由于小组成员配合不好，使本来很方便的cvs给自己的工作带来的及大的麻烦，一不小心自己写的的东西就会被小组别的成员在上传文件的时候给覆盖掉，一整天的工作可能就这样被反工，我们小组这次就是因为协作不好，导致各模块之间不法连接，给工作带来了及大的麻烦，消耗了大量的劳动力还没有提高工作效率。
这使我深深的体会到：
一个成功商业性软件的开发必须有一个有强大凝聚力的团队，个人的力量是有限的，团队精神和良好的协作会使我们做出优秀的软件。
良好的文档是正规研发流程中非常重要的环节，作为代码程序员，30％的工作时间写技术文档是很正常的，缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。
这次的这个小小的项目，就因为文档上的一点点理解错误让我们花了很大的工夫去改代码，改页面。
很庆幸的是，这是一个小项目，要是大项目，这种问题可能就会导致大量的代码修改，可见文档在一个项目中起者巨大的做用。
此外，良好的代码编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。
作为一个程序员，对需求的理解能力也是很重要的，只有真正理解了一个模块的作用，才会写出高效率的代码，才能使整个软件项目作出来更加优秀，具备更好的安全性和稳定性，我在写代码的过程中就遇到了需求理解上的问题，使得写出来的代码功能不全，幸好不是给客户发现在，要不，这个软件的商业价值可能就会打折扣了。
单元测试对于一个程序员来说是不可不做的一项工作，不做好测试就会给后期的集成工作带来麻烦，往往为了一个小问题会让我们查找好多模块，给后期工作带来很大麻烦。
这一段时间的工作也让我明白了一点：
一个优秀的程序员必须不断的学习，随时总结，找到自己的不足，这样逐步提高，才能让自己很快的成长起来。
建站侠客发表于2014-4-2810:
19
对软件开发的一点心得体会
一、前期规划：
我理解的前期规划是：
在市场人员们汇总一个需求提交给产品专家带领的产品经理团队，然后经过这个团队根据公司具体情况再次分析和规划出一个最终需求文档。
这个需求文档应当首先提交给技术研发部门的负责人以及核心开发人员。
由开发团队对其进行技术和风险分析。
如果对此需求统一有异议的地方，需要返回给产品团队，重新修正需求。
反复如此，直至需求完善准确，细致，清晰。
前期规划就像高楼的地基，如果马马虎虎，就算是一块砖块没摆好都可能导致整个高楼建设的失败。
在规划中我认为，交流永远是需要双方积极主动，能认真听取每个人的建议。
前期工作思维不慎重，不细致，不认真，不够完善，将产生连锁效应直接导致整个工程和项目的失败。
这种失败可能表现为：
第一种，软件按需求实现但是功能根本不能满足用户需要。
第二种，功能都有了，软件没有达到可用性、易用性。
对于第一种，当然是因为前期规划疏漏了某些细小功能，没能把需求文档做完善。
应该是规划工作做的还不够认真和细致。
对于第二种情况，我认为更多是在产品设计规划方面经验还不够成熟。
这种问题应该是很难避免的。
因为每种新产品对产品团队来说都很陌生。
即使以前做过类似的东西，也难免面面俱到。
这只能通过不断努力和认真的态度来弥补。
前期规划的交流涉及了市场、产品和技术研发等多个团队之间。
需要的不仅是团队内部的交流，更多需要协调好团队之间的交流。
可能有时候需要公司高层和中层参与协调。
目前，很多开发人员深感项目的需求文档写的都很单薄。
大家可以想一想，如果没有好的开始，怎么会有好的结束呢？
需求文档单薄，不够细致，由谁来继续完善呢？
难道让程序员们自己去完善。
我想程序员也可能没有这种能力。
对于程序员能把代码写的很健壮很稳定就已经是很不容易的事情了。
二、概要设计：
我理解的概要设计步骤：
（以项目为中心的开发流程）
1〉项目经理仔细阅读项目需求文档。
2〉项目经理召集项目开发成员，开项目启动会议。
具体商议项目的开发任务和责任分配。
3〉核心开发人员开发确定，以及各模块开发人员确定。
4〉由系统分析员和核心开发人员仔细阅读需求文档，对系统整个架构分析和做技术规划。
5〉系统分析员整理和书写最终的系统架构和概要设计文档。
6〉系统分析员在文档提交日，提交给项目经理。
项目经理确认文档并审批。
7〉项目经理召集项目开发成员，开一个概要设计以及系统架构确定的会议。
向每个成员分发文档，并讨论确定最终概要设计文档。
8〉开始详细设计文档的工作
三、详细设计：
1〉项目经理组织成立各个模块的开发小组，并确定开发小组组长（程序经理）。
2〉各开发组长书写各自模块的详细设计文档，开发成员需要协助，配合。
3〉在指定提交日，开发组长提交文档给系统分析员。
由系统分析员审批。
4〉系统分析员组织召开一个详细设计文档确认的会议。
5〉然后开发组长分发各自模块的详细设计文档给程序员，程序员在指定时间内完成。
6〉程序员做内部测试。
开发组长协调并配合。
7〉确认无bug提交给开发组组长。
8〉所有模块整合工作，由整个开发组成员参与完成。
由所有开发组长和系统分析员负责主要部分工作。
程序员协助和配合。
9〉对整合后工程做详细测试。
10〉确认测试通过后，开发组
升级会员 