软件开发心得体会共12页.docx

软件开发心得体会共12页.docx

《软件开发心得体会共12页.docx》由会员分享，可在线阅读，更多相关《软件开发心得体会共12页.docx（8页珍藏版）》请在冰点文库上搜索。

软件开发心得体会共12页

软件开发心得体会

[模版仅供参考，切勿通篇使用]

　　第一篇：

　　受某文化公司委托，开发一款用于视频和图像处理的软件，开发难度高，高到从未搞过，开发周期长，长到是我以前项目监控最长开发周期的两倍，开发成本之底，让我觉得程序员成了高级打字员。

首先是需求分析书、产品规格说明书、设计说明书、代码规范说明书、测试计划，光文稿就不知道熬了多久才做完。

　　紧接着，遇到一系列问题，首先是语言选择，vc++和c#都是可以保证开发完成的选择，但是vc++内存容易报错，界面很难修改，而客户要求的界面质量甚至比程序的功能更严格，没办法，客户就是上帝，上帝做事一定有他的道理。

c#语言易于开发，而且图形界面绘制也易于修改，可以做出客户体验很好的界面，但是在资源的消耗上，让我很吃惊。

做到第二个月，大概的界面已经完成时，出现界面刷新的问题，刷新时开始卡，界面不流畅。

没办法，改。

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

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

　　用directdra[]、管理、产品、流程等），非常情绪化。

有些女程序员还会吵，会哭，这时项目经理只能放下手中的活，下去给她买点零食来哄哄，“莫哭，这里有你最爱吃的猫哆哩。

”一边擦着鼻涕、眼泪，一边嘴里塞满东西，鼓鼓啷啷“这是酸角口味的，那个西番莲口味的才叫好吃..."

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

　　第二篇：

软件开发学习心得体会

　　软件开发学习心得体会

　　随着我矿“两化”融合工作的推进，软件开发方面人才显得更加缺乏，所以我选择对进一步深入学习；经过近两个月的自主学习，进一步掌握了动态网页制作的一些理论知识和基本常识，不仅要应用各种方面的知识还要对所学的知识学会变通使用，虽然会有一些成功的地方。

曾经看到网上有这么一句话，一个优秀的网络程序员不但要了解自己领域的一些专业技术，而且很多时候还要充当半个网络工程师，半个美术设计师和半个数据库管理员。

是microsoft.net战略的核心产品，凭借它丰富的控件，以及具有革命性的code-behind技术，以及良好的封装性，无疑成为业界开发activeserverpage的一门巨将。

　　是asp（微软动态服务器网页技术）的最新版本。

执行效率大幅提高：

构架是可以用microsoft（r）公司最新的产品visual开发环境进行开发，[]e[]l和简单的[]的基石。

　　有缺陷的人才

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

　　大公司，会看重综合素质，而如果是小公司，可以考虑选择一些有缺陷的人才。

有缺陷，是指，比如他英语很差，或沟通不清晰，但他能用程序员该有的思

　　维去思考问题。

这样的人员，通常进不了大公司，故会相对踏实地呆在一家公司，做好自己的工作。

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

　　太活泼，太易兴奋

　　太易兴奋，说到投机处，“是是是是，对对对对。

。

”，又蹦又跳，还时不时来点，“ohyeah,youareright“，然后还摆个v手型。

讨论问题，不易固守在技术问题本身，时常跑到“我们产品中用到的技术（或第3方产品）很强，我挺他们，不可能有问题”，又或者“我们对客户要强势，我们要坚持我们的产品没问题"。

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

　　太活泼的人，会在遇到问题之初，表现出很强的冲劲，但当长时间不能解决时，会表现出没有耐心，会经常抱怨（对team、管理、产品、流程等），非常情绪化。

女程序员还会吵，会哭，这时项目经理只能放下手中的活，下去给她买点零食来哄哄。

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

　　家境太好的人

　　家境好，可能没吃过什么苦，抗压差，并不太容易珍惜这份工作。

工作强度不大时，还好。

遇到技术难题、项目进度紧、压力大时，这些人员，可能会表现出不易妥协，难于沟通，”我反正也不在乎这么一个工作。

。

我工作不工作都可以，有什么大不了“。

　　我team中曾经有这样一个”富2代“，干了一年不到就闪了。

他在的几个月中，就像是一场闹剧，来这里，旅游观光罢了，东看看西看看，抛下几句狠话，刻下”xxx到此一游，就走了。

　　身体太差的人

　　身体常年有疾者，通常都会性格怪戾，脾气暴躁，难于跟team很好相融。

　　第四篇：

分享软件开发小心得体会——（厦门ios开发培训）

　　分享软件开发小心得体会——（厦门ios开发培训）

　　如何能在短短的30分钟或1小时内，快速识别出，坐在你对面的应聘人员，是否适合你的team。

厦门博看文思来支招：

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

　　-经历过历练的人

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

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

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

　　让谈谈自己现在的产品，如果能清晰表述，有条理，会发散，但又能适当控制住，并收回到原话题。

谈到技术问题和解决过的难题时，眼中有光芒：

）

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

　　-坦诚、坚定、平和的人

　　面试中，坦诚，目光坚定。

有时坦诚到甚至于显得有点木讷：

）

　　我曾经遇到一个，面试下来，我最后介绍我们产品中用到的技术，他对这些技术知之不多，最后他说，“我可能不是非常适合，我知道一个朋友，他可能更适合。

”我综合评估后，最后还是选了他，事实证明，他后来做的很不错。

　　坦诚坚定的人，会有恒心去学习，去解决问题。

这些人员会作为team的基石。

　　-有缺陷的人才

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

　　大公司，会看重综合素质，而如果是小公司，可以考虑选择一些有缺陷的人才。

所谓有缺陷，是指，比如他英语很差，或沟通不清晰，但他能用程序员该有的思维去思考问题。

这样的人员，通常进不了大公司，故会相对踏实地呆在一家公司，做好自己的工作。

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

　　-太活泼，太易兴奋

　　太易兴奋，说到投机处，“是是是是，对对对对。

。

”，又蹦又跳，还时不时来点，“ohyeah,

　　youareright“，然后还摆个v手型。

讨论问题，不易固守在技术问题本身，时常跑到“我们产品中用到的技术（或第3方产品）很强，我挺他们，不可能有问题”，又或者“我们对客户要强势，我们要坚持我们的产品没问题"。

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

　　太活泼的人，会在遇到问题之初，表现出很强的冲劲，但当长时间不能解决时，会表现出没有耐心，会经常抱怨（对team、管理、产品、流程等），非常情绪化。

有些女程序员还会吵，会哭，这时项目经理只能放下手中的活，下去给她买点零食来哄哄，“莫哭，这里有你最爱吃的猫哆哩。

”一边擦着鼻涕、眼泪，一边嘴里塞满东西，鼓鼓啷啷“这是酸角口味的，那个西番莲口味的才叫好吃..."厦门博看文思指出，这些通常不太容易在面试时表现出来，在试用期时，要观察。

　　第五篇：

大型软件开发心得

　　最近做的一个项目从需求分析到上线绵延了四个月之久，这也是目前接手过功能点最繁复，产品线对接最多的一个项目。

从中得到的一些关于设计较大型产品的心得，拿出来跟大家分享。

　　立项前

　　1、统一元素设计需考虑周全

　　也许是初创团队的缘故，我不得不感叹团队对产品经理要求之严格之缜密，项目全程只有一个人负责，所以大到产品线对接，小到一句提示的位置和展示形式都需要一一推敲。

　　哪些元素应该做到统一？

　　a、提示方面：

统一的操作成功/失败提示；统一的弹窗形式；提示语言采用较统一的句型；为空情况的友好提醒；溢出情况的友好提醒；表单实时验证的提醒形式等。

　　b、文字方面：

是否有统一的段落前“·”号；统一的链接状态；统一的字体、间距、行高等。

　　c、图片方面：

调取图片的统一尺寸；如果是上传图片类的操作，需要考虑周全全站的调取情况，以及考虑是否统一预览图的尺寸等。

　　d、细节交互：

未激活功能的按钮做“灰色”处理（例如用户没有勾选信息时批量删除按钮不可使用）；按钮点击的状态统一（例如增加“提交中”的按钮状态，以防止网速慢用户狂点某一按钮的情况）；特殊控件的统一等。

　　也许会有朋友说，上面有些是交互设计师需要做的事，但我一直认为作为一个产品经理考虑周全一些，没坏处。

这些“统一”同样可以用在验收阶段，要知道，即使一个像素也可以改变整个产品的感觉。

　　2、原有功能的去留

　　我一直觉得升级已有产品比开发新产品难一些。

这就像栽培植物一样，新种下一棵果树无非需要选对了土地，然后刨个坑种下去，然而成长期的去病枝、打顶等各种修剪所消耗的精力往往更多。

　　改进已有产品常常需要面对一个最棘手的问题：

原有功能是去是留？

　　原功能去掉的话是不是会影响部分用户使用？

是否需要通过公告、站内信、界面引导等方式友好地告知用户？

怎样把对用户的伤害降至最低？

　　原功能留下的话是不是可以优化完善？

听到了什么用户群怎样的声音？

是否要在这次升级中做调整？

　　这些问题当接到项目的时候，产品经理就应该考虑周全了。

特别需要注意的是，如果这个产品之前不是自己设计的，那么最好找到prd说明文档细细研究一遍，对把握不准的功能点找到原负责人确认，毕竟树苗是ta摘的，别把将来最能结果的枝干给砍了。

　　3、产品线上下游的对接

　　昨天有跟朋友聊起淘宝强势之处，就是产品与产品紧密捏合，线上线下、跨平台跨行业形成了一个盘根错节、根深蒂固的根基，无可撼动。

　　所以把握产品线上下游和产品周边很重要，即使一个看似简单的新闻展示页面修改也会牵扯到xx后台、广告位管理、帮助中心，甚至是访问统计、数据需求的变更。

　　这要求在产品设计开始前，需要把该产品“连根拔起”，仔细梳理相关脉络，如果产品线够长，一个清晰的产品线结构图很有必要。

　　项目中

　　1、项目期间来自相关产品线调整的影响

　　项目期间相关产品线的调整是我最不愿意遇到的情况，这就像你在通往目的地的道路上高速行驶，就快要到达终点了，突然一个人告诉你：

你走错路了。

　　项目里有一个通用模块，产品设计到一半，这个通用模块改了；项目里有一个流程，产品做到一半，这个流程废弃了；最要命的是已经立项开发了，你不得不硬着头皮跟程序员说：

“因为一些不可抗拒原因，这个需求咱不做了。

”

　　对于一个耗时较长的项目来说，这种情况难以避免，事出原因私自总结有三：

　　a、严重体验性问题：

例如某个流程遭到大量用户的不满，为防止用户流失，不得不做临时调整，而倒霉的是，你也在用这个流程。

　　b、相关项目的影响：

包括并行项目和新项目。

例如你的同事在设计另一个产品，你们的产品相互牵扯较多，所以需求分析时做过很多沟通，但有一天，同事告诉你，ta的一个需求做临时调整了会影响到你，怎么办？

　　c、老板的突然决定：

不举例。

　　最终的解决方法不外乎三种：

立即调整、延期调整、不调整。

个人的处理原则一般是对a种情况进行立即调整，对b、c情况讨论并选择性延期。

　　为什么这么做呢？

a情况是必须要改的，时间早晚问题，长痛不如短痛，b、c两种情况必须坐下来细细讨论。

需了解这个需求为什么要改？

是长期对策还是临时决定？

能否延期，记录需求等下一版本再开发？

如果b、c情况提出来的需求没过两天又有改变，那与你配合的前端和程序员也太没有安全感了。

　　这个时代能耐心阅读完xx枚汉字的人越来越少，较大型项目的产品工作心得[下]未完待续，欢迎交流……

　　2、需求变更

　　承上，需求变更是每个程序员、产品经理、设计师等都会遇到的情况。

产品经理不是神，项目组也不可能是开了无敌状态抵挡任何外界的影响。

　　当遇到不得不变更需求的时候，产品经理应该怎样处理呢？

下面是个人的四条建议：

　　a、积极处理。

往往，当一个设计愈是趋于完成，人们愈是倾向于局部调整，而不是做重新设计。

当一个需求因为众所周知的原因不得不调整的时候，作为产品经理需要做的第一件事便是积极面对问题，积极处理。

　　项目开发往往是一个紧张的过程，每半天甚至每几个小时就有若干个功能点开发完成，当一个需求变更传达出现“延迟”，这个变更对项目的正常进程的“破坏力”就会更大一些。

　　b、保持沟通。

“说话容易，沟通很难。

很多事除非对方自己想明白，劝是没有用的。

所以，很多时候，沟通是个自己挣扎的过程”这话没错。

需求变更直接会影响到下一道工序，产品经理需要将需求变更的细节和原因传达给相关人员，包括视觉、前端、程序、测试等。

　　这是很多产品经理表示非常痛苦的过程，因为可能会遭到数落和冷眼，日本有一个礼仪原则是“不要给别人添麻烦”，但是在项目中，这不可避免。

　　个人认为所有沟通的障碍都源于思想的不统一，如果让大家觉得这个需求修改是在浪费时间，那么沟通上的不畅快在所难免。

项目不是这样算的，需求既然更改一定有所目的，产品经理需要将这个原因讲明白，不做修改或节约沟通时间导致的返工，后果往往更严重。