软件开发经验总结.docx

1、软件开发经验总结软件开发经验总结篇一：个人经验-软件开发工作总结个人评定在20XX年里，整个项目组能够按照计划，并顶住各方面的压力，加班加点完成年度目标，是我对我们这个团队表示肯定和自豪的重要原因之一，在过去的一年里，我们团队实现了从新成立的一个项目组转变成为了一个高效、稳健、整体目标明确的团队，在过去的一年里，我们团队的每个成员都在不断积累着经验、分享着自己成功、展现着团队魅力，在过去一年里，我也在逐步的转变和完善着自己对团队、对目标、对效率的认识，在此，我对过去一年的付出做出四点总结：一、 看待事情的态度，在工作上，逐步习惯性的将每件事情都做上标注和批注，针对每一次提交代码，回复禅道上的问

2、题，编写日报、周报，我们都制定了相关的标准去促进团队发展，我们能够逐步认识到规范的重要性，逐渐的能够理解到在一个高效的团队中，规范标准是不可或缺的因子。二、 看待事情的角度，面对问题和困难，我们从刚开始的推脱，到寻找理由延长迭代周期，再到分析过程给出方案，到现在，我们能够理性的看待问题，前瞻性的暴露出问题，详细的规划问题的解决周期，实现了角度的转变。三、 面对面的沟通，针对于个人，在性格上的缺失，以及作为“码农”弊病，我都不善于言语和沟通，也不习惯面对面的去说明问题和交流方案，但作为表率，我强制自己去分享自己的言语，去表达问题和自己的想法，也希望能够通过这种情绪，带驱动团队内部的交流。四、 对

3、于管理，是一个日积月累的过程，有机遇、有机会、碰见相信自己领导和团队，才能够在岁月的磨练中去积累经验，我正在做的是，参照每一个组员，每一个领导，对比我与他们在处理方式上的不同，来进行取长补短，来自完善，拿别人标准来约束自己。篇二：软件开发工作汇报XX市XXXXXXXXXXX信息化平台-工作汇报XXXXXXXXX单位20XX年4月XXXXX市XXXXXXXX工作汇报目 录1 开发背景 . 12 工作目标 . 23 工作任务 . 34 工作计划 . 45 信息化平台开发执行标准 . 66 信息化平台实施完成任务情况 . 77 信息化平台自测效果 . 98 信息化平台特色 . 139 总结 . 16

4、1 开发背景根据XX市XXXXX馆XX市XXXXX管理信息化软件开发招标文件对XX信息化的建设要求，于XXXXX年X月X日对项目进行进行招标，采购项目名称为“XX市XXXXX管理信息化软件开发”，招标编号为“0XXXXXX”,XXXX信息技术有限公司（以下简称XX公司）参与竞标，并最终中标。XX信息公司根据招标文件要求，于20XX年7月开始对XX市XXXXX管理信息化软件进行开发。2 工作目标XX公司按照XX市XXXX和XXX的相关标准和业务规范，完成XX市XXXXX管理信息化平台开发，XXXX信息系统、XX市国局XXXX信息系统、电子XX移交与接收平台、XX信息服务平台和地质资料管理信息系统

5、五个系统开发建设任务。实现XXXX的规范化、标准化、信息化，实现xxxxxxX的集中管理和综合利用及全市XX信息资源共享，为促进全市国XXXXX的发展提供信息保障服务。3 工作任务 根据XX市xxx局对XXXXX管理信息化建设的要求，结合工作实际，XX市XXXXX信息化平台建设具体完成的子系统如下：1、xxxxxxxxxxxxxxxx）；2、xxxxxxxxxxxxx；3、xxxxxxxxxxxxx；篇三：大型软件开发心得大型软件开发心得最近做的一个项目从需求分析到上线绵延了四个月之久，这也是目前接手过功能点最繁复，产品线对接最多的一个项目。从中得到的一些关于设计较大型产品的心得，拿出来跟大家

6、分享。立项前1、统一元素设计需考虑周全也许是初创团队的缘故，我不得不感叹团队对产品经理要求之严格之缜密，项目全程只有一个人负责，所以大到产品线对接，小到一句提示的位置和展示形式都需要一一推敲。哪些元素应该做到统一？a、提示方面：统一的操作成功/失败提示；统一的弹窗形式；提示语言采用较统一的句型；为空情况的友好提醒；溢出情况的友好提醒；表单实时验证的提醒形式等。b、文字方面：是否有统一的段落前“”号；统一的链接状态；统一的字体、间距、行高等。c、图片方面：调取图片的统一尺寸；如果是上传图片类的操作，需要考虑周全全站的调取情况，以及考虑是否统一预览图的尺寸等。d、细节交互：未激活功能的按钮做“灰色

7、”处理（例如用户没有勾选信息时批量删除按钮不可使用）；按钮点击的状态统一（例如增加“提交中”的按钮状态，以防止速慢用户狂点某一按钮的情况）；特殊控件的统一等。也许会有朋友说，上面有些是交互设计师需要做的事，但我一直认为作为一个产品经理考虑周全一些，没坏处。这些“统一”同样可以用在验收阶段，要知道，即使一个像素也可以改变整个产品的感觉。2、原有功能的去留我一直觉得升级已有产品比开发新产品难一些。这就像栽培植物一样，新种下一棵果树无非需要选对了土地，然后刨个坑种下去，然而成长期的去病枝、打顶等各种修剪所消耗的精力往往更多。改进已有产品常常需要面对一个最棘手的问题：原有功能是去是留？原功能去掉的话是

8、不是会影响部分用户使用？是否需要通过公告、站内信、界面引导等方式友好地告知用户？怎样把对用户的伤害降至最低？原功能留下的话是不是可以优化完善？听到了什么用户群怎样的声音？是否要在这次升级中做调整？这些问题当接到项目的时候，产品经理就应该考虑周全了。特别需要注意的是，如果这个产品之前不是自己设计的，那么最好找到prd说明文档细细研究一遍，对把握不准的功能点找到原负责人确认，毕竟树苗是ta摘的，别把将来最能结果的枝干给砍了。3、产品线上下游的对接昨天有跟朋友聊起淘宝强势之处，就是产品与产品紧密捏合，线上线下、跨平台跨行业形成了一个盘根错节、根深蒂固的根基，无可撼动。所以把握产品线上下游和产品周边很

9、重要，即使一个看似简单的新闻展示页面修改也会牵扯到xx后台、广告位管理、帮助中心，甚至是访问统计、数据需求的变更。这要求在产品设计开始前，需要把该产品“连根拔起”，仔细梳理相关脉络，如果产品线够长，一个清晰的产品线结构图很有必要。项目中1、项目期间来自相关产品线调整的影响篇四：软件项目总结报告项目名称 软件项目总结报告编号：-项目名称缩写-CLOSUREREPORT版本:变更记录1 项目信息2 项目说明简要描述项目背景， 可从软件需求规格说明书拷贝3 项目周期1）项目进度总结：2）偏差原因说明：若项目整体进度偏差率或项目周期偏差率超过设定的阈值，需要对偏差原因进行总结分析。3）改进措施：若项目

10、整体进度偏差率或项目周期偏差率超过设定的阈值，需要总结改进措施，。篇五：软件开发：软件工程师总结的20+条经验教训软件开发：软件工程师总结的20+条经验教训一些有关于软件开发的经验规则：开发1.从小事做起，然后再扩展无论是创建一个新的系统，还是添加功能到现有的系统中，我总是从一个简单到几乎没有任何所需功能的版本启动，然后再一步一步地解决问题，直到满意为止。我从来没有妄想过能够一步登天。相反，我一边开发一边学习，同时新掌握的信息还可以用于解决方案中。我很喜欢John Gall的这句话：“复杂系统总是源于简单系统的演化。”2.一次只改变一件事当我们在软件开发时，碰到测试失败和功能无效的情况，如果你

11、一次只研究一个问题，那将会更容易找到问题的关键。换言之，就是使用短迭代。必须确保这个问题解决之后，再转移到另一个问题上。这适用于向下提交。如果在你添加新功能之前需要先重构代码，那么先提交重构，然后再添加新的功能。3.尽早地添加日志记录和错误处理在开发新系统时，我做的第一件事就是添加日志和错误处理，因为这两者从一开始就非常有用。如果系统不能照常工作，那么你就需要知道程序中发生了什么这是日志的作用。错误处理也是如此错误和异常越早处理越好。4.每一行新代码必须至少执行一次在你真正完成一个功能之前，你必须对它进行测试。不然，你怎么知道它是不是按照你的想法在执行呢？通常情况下，最好的方法是通过自动测试，

12、但并非总是如此。不过，不管怎么说，每一行新代码必须至少执行一次。5.在整体测试之前先进行模块测试先进行部分模块测试可以节省时间。通常说来，我们在整合不同的模块时也会出现问题，例如模块之间的接口不匹配。但是如果我们能够信任各个组件的话，那么跟踪集成问题就会变得简单得多。6.所有事情所花费的时间总是比你预期的要长特别是在编程中，即使一切进展顺利，我们也很难对功能所需的时间做出正确的预算。并且，开发软件时碰到各种意想不到的问题是非常常见的。侯世达定律其实道出了真谛：做事所花费的时间总是比你预期的要长，即使你在预期中已经考虑了侯世达定律。7.先了解现有的代码大多数的编码都需要以某种方式改变现有的代码。

13、即使是新功能，也需要适应现有的程序。所以，在你加进去新的内容前，首先需要了解当前的解决方案。否则，你一不小心就很有可能会打破现有的功能。这意味着，阅读代码和编写代码都是必要的技能。这也是为什么看似微小的变化仍可能需要很长时间才能解决的原因之一你首先必须了解上下文。8.阅读和运行幸运的是，对于理解代码，我们有两种互补的方法。你可以阅读代码，也可以运行代码。运行代码的确是个非常棒的好方法。所以，请确保充分利用这两种方法。故障排除总是难免的我不喜欢那些宣称软件开发可以“一蹴而就”的高谈阔论。不论你再怎么费尽心机，bug总是难免的。最好能够做成可以快速故障排除、修复bug和部署修复的系统。10.解决故

14、障报告每个开发人员都应该花时间去处理来自客户的故障报告，并修复bug。这能让你更好地理解客户的意图，明白如何使用系统，知道排除故障的难易程度，了解系统的设计情况。这也是为自己的开发成果负责的好方法。11.重现问题修复bug的第一步就是重现问题。然后你得确保修复之后，问题能够彻彻底底地消失。这样一个简单的规则可以确保你不会误将非问题当作是问题，并确保解决方案真的能够奏效。12.修复已知错误，然后再看看有没有遗漏的地方有时候，可能同时存在着几个不同的问题。它们之间的互相作用，可能会让你毫无头绪，束手无策。不要纠结于搞清楚发生了什么，先去解决所有已知的问题，然后再看看还有什么不对的地方。13.没有巧

15、合在测试和故障排除时，不要相信会出现什么巧合。就像你改变了定时器的值，那么就会改变系统重启的频率。所以一切都并非是巧合。添加新功能，另一个不相干的功能变慢了？这绝对不是巧合。相反，是你应该仔细调查的内容。14.关联时间戳在故障排除时，事件的时间戳可以作为你的好帮手。寻找偶数增量。例如，如果系统重启了，并且刚刚发出过一个3000毫秒左右的请求，那么可能是触发了某个定时器，才导致出现重启的动作。团队合作15.面对面的交流最有效当我们需要讨论如何解决问题时，那么面对面的交流比视频、打电话和电子邮件都要好。16.橡皮鸭法遇到你绞尽脑汁也解决不了的问题时，不妨找一个同事，然后将问题解释给他们听。很多时候

16、，当你在叙述时，即使你的同事一言不发，你可能也会突然灵光乍现找到问题的关键。17.问问题阅读和运行代码往往非常有助于指出代码的目的和它的工作原理。但是如果你有机会咨询那些更为了解的人（例如原来的程序员），那么千万不要错过。18.共享荣誉不要贪图荣誉，该是谁的就是谁的。例如：“Marcus想出了这个主意”（如果真是他想的话），而不要说“我们想出的”。其他19.尝试如果你不知道某种编程语言功能的工作原理，那么不妨写一个小程序来理解它是如何工作的。这同样适用于测试你正在开发的系统。如果我将参数设置为-1，会发生什么？当我在重启系统时，如果服务当掉，会发生什么？以此来研究它的工作原理。20.带着问题睡

17、觉如果你正在解决一个很难的问题，那么不妨带着问题睡觉。有科学研究表明，这样做虽然你表明上并没有在主动思考，但你的潜意思却这么做了。其结果就是，第二天再去研究问题，解决方案已经呼之欲出了。21.跳槽不要害怕跳槽。和不同的人共事，开发不同的产品，感受不同的公司文化是非常有意思的。22.不断学习我们需要不断地学习和了解软件开发。你可以尝试不同的编程语言和工具，阅读软件开发的书籍，接受MOOC课程。相信我，量变才能达到质的飞跃，这些小小的学习积累，终有一天会大大地提高你的知识和能力。希望这些经验能对大家有用。如有不当之处，敬请指正。篇六：大学生大学生大学学了四年的计算机，毕业后一直从事软件开发的工作，

18、多多少少也累积了一些经验。很多人学习编程总是很努力地去钻研计算机高深的难题，或花很多的精力去追随新产生的技术宠儿，执着好奇的我们往往认为这样非常有成就感。其实有这样一颗上进的心是可喜可贺的，但是绝大多数的我们都是平凡人，精力总是有限的不可能成为一个计算机全才，即便是，全才两字的含金量也不高。学习了这么多的新技术，解决过如此多的技术难题，很有成就感一点没错，但是在实际的工作中你运用到他们了吗？我想未必吧！就拿我自己来说，刚开始的时候我还在java和.net之间徘徊究竟该何去何从呢？索性我就两种都学习这样周一学java、周二学.net让我很是费神，结果临近毕业的时候发现两者没有一样精通的。去求职的

19、时候总是被拒之门外，甚至还有面试官说你究竟想搞java还是.net。最后工作终于搞定了，却是一个与.net只沾点边的工作，苍天啊！工作大半年后对.net倒是越来越熟悉了，但是之前学的java知识早已忘的差不多了。决定了从事.net方面的工作后，我还在继续学习，总是顶礼膜拜那些新技术、那些自己还没有接触过的领域。什么wpf、wf、silverlight、webservice之类的、也都统统走马观花式地学习了一遍，说实话这对于当时的我来说好难啊，但是我乐意总以为这样出去就能谋求一份更好的工作。辞了第一份工作，开始了我的第二步，原本以为我在这里能学习和运用这些新潮技术，过了一段时间我发现我错了。我们

20、大部分的工作都是做一些难度不是很高的任务，最难的也就是架构下小系统而已。后来也和同行们交流过，甚至那些拿高薪的。他们的工作也不是一味地追去新技术，他们的选择是以客户为导向的，只要软件能满足客户的需求哪怕是实现1+1那样的小儿科他们都愿意。话又说回来其实掌握那些高端技术是需要基础知识和经验的，当你的水平到达了一个层次时再来学习就不会那样的难了，水到渠成嘛。这就是我的经验总结，就像做人一样要一步一个脚印，不要走马观花跨越式地学习，这样下去只会让你的能力永远停滞不前。篇七：软件开发心得体会软件开发心得体会一直以来期望从事自己喜欢的事业的我，对软件开发有者及大的兴趣，可由说种种原因使我从事工作以来走了

21、好几年弯路，心中的梦想迟迟不能得以实现，可程序员的梦想从来没有从我的心中抹去，但这扇大门好像并没有向我敞开，今天，贵公司给了我敲开这扇大门的机会，让我真实体验了程序员这个岗位。开发一款用于视频和图像处理的软件，开发难度高，高到从未搞过，开发周期长，长到是我以前项目监控最长开发周期的两倍，开发成本之底，让我觉得程序员成了高级打字员。首先是需求分析书、产品规格说明书、设计说明书、代码规范说明书、测试计划，光文稿就不知道熬了多久才做完。紧接着，遇到一系列问题，首先是语言选择，vc+和c#都是可以保证开发完成的选择，但是vc+内存容易报错，界面很难修改，而客户要求的界面质量甚至比程序的功能更严格，没办

22、法，客户就是上帝，上帝做事一定有他的道理。c#语言易于开发，而且图形界面绘制也易于修改，可以做出客户体验很好的界面，但是在资源的消耗上，让我很吃惊。做到第二个月，大概的界面已经完成时，出现界面刷新的问题，刷新时开始卡，界面不流畅。没办法，改。重新做软件开发进度计划和软件测试计划，并且让独立功能demo制作和测试先行;用direct draw、direct 3d或者opengl中的一个替代c#本身的gdi绘图，将在接下来的开发任务中加入进去。事无巨细，当我满意的看着界面流畅，功能也已实现时，发现软件在低分辨率或者小本上根本乱到没法看，甚至是界面功能按钮错位，重叠等等。没办法，改。毕竟软件的多分辨

23、率兼容和操作系统兼容是必须要做的。接下来一大堆的麻烦找了上来，软件出现各种各样想都想不到的问题，总算是按时将第一个版本发布出去，并且开始接下来的升级开发任务。最后，给刚刚接手软件开发项目的朋友一些忠告：一、相关的文档不是给别人看的，而是给自己看的，相关文档一定要齐备，而且让所有涉及开发的人员都清楚的知道你文档里所要表达的意思;二、一定要注意多做demo，多做实验，一个demo程序员几个钟头就可以完成，甚至更少，但是不做demo，核心程序没有做实验，其他的东西都围绕核心程序做了上去，到时候耽误的可不是几个钟头三、程序设计要注重用户体验，当初客户对我要开发软件提出近乎苛刻的要求时我不在意，但是当我

24、自己反复使用软件时有了很多体会，流畅美观的界面带给人心理的快感的确能替代一些尚未开发完整的功能带给用户的遗憾。四、测试计划多次进行，分批进行，不要全部开发完成再对软件做测试。还要坚持三个月，软件马上发布，希望大家的支持，谢谢!以上这篇是软件开发心得体会。就为您介绍到这里，希望它对您有帮助。如果您喜欢这篇文章，请分享给您的好友。篇八：一位软件工程师的经验总结一位软件工程师的经验总结又是一年毕业时，看到一批批学子离开人生的象牙塔，走上各自的工作岗位想想自己也曾经意气风发、踌躇满志，不觉感叹万千本文是自己工作6年的经历沉淀或者经验提炼，希望对所有的软件工程师们有所帮助，早日实现自己的人生目标。 【查

25、看详情】1、“学历代表过去、能力代表现在、学习力代表未来。”其实这是一个来自国外教育领域的一个研究结果。相信工作过几年、十几年的朋友对这个道理有些体会吧。但我相信这一点也很重要：“重要的道理明白太晚将抱憾终生!”所以放在第一条，让刚刚毕业的朋友们早点看到哈!2、一定要确定自己的发展方向，并为此目标制定可行的计划。不要说什么“我刚毕业，还不知道将来可能做什么”、“跟着感觉走，先做做看”，因为这样的观点会通过你的潜意识去暗示你的行为无所事事、碌碌无为。一直做技术，将来成为专家级人物向管理方向走，成为职业经理人先熟悉行业和领域，将来自立门户还是先在行业里面混混，过几年转行做点别的这很重要，它将决定你

26、近几年、十年内做什么事情才是在做正确的事情。3、软件开发团队中，技术不是万能的，但没有技术是万万不能的!在技术型团队中，技术与人品同等重要。在软件项目团队中，技术水平是受人重视和尊重的重要砝码。无论你是做管理、系统分析、设计、编码，还是产品管理、测试、文档、实施、维护，多少你都要有技术基础。4、详细制定自己软件开发专业知识学习计划，并注意及时修正和调整（软件开发技术变化实在太快）。请牢记：“如果一个软件开发人员在1、2年内都没有更新过自己的知识，那么，其实他已经不再属于这个行业了。”不要告诉自己没有时间。来自时间管理领域的著名的“三八原则”告诫我们：另外的那8小时如何使用将决定你的人生成败!本

27、人自毕业以来，平均每天实际学习时间超过2小时。5、书籍是人类进步的阶梯，对软件开发人员尤其如此。书籍是学习知识的最有效途径，不要过多地指望在工作中能遇到“世外高人”，并不厌其烦地教你。拥有书籍并不表示拥有知识拥有知识并不表示拥有技能拥有技能并不表示拥有文化拥有文化并不表示拥有智慧。只有将书本变成的自己智慧，才算是真正拥有了它。6、不要仅局限于对某项技术的表面使用上，哪怕你只是偶尔用一、二次。“对任何事物不究就里”是任何行业的工程师所不应该具备的素质。开发Windows应用程序，看看Windows程序的设计、加载、执行原理，分析一下 PE文件格式，试试用SDK开发从头开发一个Windows应用程

28、序用VC、 Delphi、Java、.Net开发应用程序，花时间去研究一下MFC、VCL、J2EE、.Net它们框架设计或者源码除了会用J2EE、 JBoss、Spring、Hibernate等等优秀的开源产品或者框架，抽空看看大师们是如何抽象、分析、设计和实现那些类似问题的通用解决方案的。试着这样做做，你以后的工作将会少遇到一些让你不明就里、一头雾水的问题，因为，很多东西你知其然且知其所以然。7、在一种语言上编程，但别为其束缚了思想。“代码大全”中说：“深入一门语言编程，不要浮于表面”。深入一门语言开发还远远不足，任何编程语言的存在都有其自身的理由，所以也没有哪门语言是包治百病的“灵丹妙药”。编程语言对开发人员解决具体问题的思路和方式的影响与束缚的例子俯拾皆是。我的经验是：用面对对象工具开发某些关键模块时，为什么不可以借鉴C、C51、汇编的模块化封装方式用传统的桌面开发工具（目前主要有VC、Delphi）进行系统体统结构设计时，为什么不可以参考来自 Java社区的IoC、AOP设计思想，甚至借鉴像Spring、Hibernate、JBoss等等优秀的开源框架在进行类似于实时通信、数据采集等功能的设计、实现时，为什么不可以引用来自实时系统、嵌入式系统的优秀的体系框架与模式为什么