大型软件开发心得

第一篇：大型软件开发心得

最近做的一个项目从需求分析到上线绵延了四个月之久，这也是目前接手过功能点最繁复，产品线对接最多的一个项目。从中得到的一些关于设计较大型产品的心得，拿出来跟大家分享。

立项前

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

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

哪些元素应该做到统一？

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

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

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

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

也许会有朋友说，上面有些是交互设计师需要做的事，但我一直认为作为一个产品经理考虑周全一些，没坏处。这些“统一”同样可以用在验收阶段，要知道，即使一个像素也可以改变整个产品的感觉。

2、原有功能的去留

我一直觉得升级已有产品比开发新产品难一些。这就像栽培植物一样，新种下一棵果树无非需要选对了土地，然后刨个坑种下去，然而成长期的去病枝、打顶等各种修剪所消耗的精力往往更多。

改进已有产品常常需要面对一个最棘手的问题：原有功能是去是留？

原功能去掉的话是不是会影响部分用户使用？是否需要通过公告、站内信、界面引导等方式友好地告知用户？怎样把对用户的伤害降至最低？

原功能留下的话是不是可以优化完善？听到了什么用户群怎样的声音？是否要在这次升级中做调整？

这些问题当接到项目的时候，产品经理就应该考虑周全了。特别需要注意的是，如果这个产品之前不是自己设计的，那么最好找到prd说明文档细细研究一遍，对把握不准的功能点找到原负责人确认，毕竟树苗是ta摘的，别把将来最能结果的枝干给砍了。

3、产品线上下游的对接

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

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

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

项目中

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

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

项目里有一个通用模块，产品设计到一半，这个通用模块改了；项目里有一个流程，产品做到一半，这个流程废弃了；最要命的是已经立项开发了，你不得不硬着头皮跟程序员说：“因为一些不可抗拒原因，这个需求咱不做了。”

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

a、严重体验性问题：例如某个流程遭到大量用户的不满，为防止用户流失，不得不做临时调整，而倒霉的是，你也在用这个流程。

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

c、老板的突然决定：不举例。

最终的解决方法不外乎三种：立即调整、延期调整、不调整。个人的处理原则一般是对a种情况进行立即调整，对b、c情况讨论并选择性延期。

为什么这么做呢？a情况是必须要改的，时间早晚问题，长痛不如短痛，b、c两种情况必须坐下来细细讨论。需了解这个需求为什么要改？是长期对策还是临时决定？能否延期，记录需求等下一版本再开发？如果b、c情况提出来的需求没过两天又有改变，那与你配合的前端和程序员也太没有安全感了。

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

2、需求变更

承上，需求变更是每个程序员、产品经理、设计师等都会遇到的情况。产品经理不是神，项目组也不可能是开了无敌状态抵挡任何外界的影响。

当遇到不得不变更需求的时候，产品经理应该怎样处理呢？下面是个人的四条建议：

a、积极处理。往往，当一个设计愈是趋于完成，人们愈是倾向于局部调整，而不是做重新设计。当一个需求因为众所周知的原因不得不调整的时候，作为产品经理需要做的第一件事便是积极面对问题，积极处理。

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

b、保持沟通。“说话容易，沟通很难。很多事除非对方自己想明白，劝是没有用的。所以，很多时候，沟通是个自己挣扎的过程”这话没错。需求变更直接会影响到下一道工序，产品经理需要将需求变更的细节和原因传达给相关人员，包括视觉、前端、程序、测试等。

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

个人认为所有沟通的障碍都源于思想的不统一，如果让大家觉得这个需求修改是在浪费时间，那么沟通上的不畅快在所难免。项目不是这样算的，需求既然更改一定有所目的，产品经理需要将这个原因讲明白，不做修改或节约沟通时间导致的返工，后果往往更严重。

第二篇：软件开发心得

软件开发心得体会

08软件（1）班 陈会敏 24号

岁月流转，时光匆匆，转眼间我的大学生活已经接近了尾声。回首往昔，有太多美好的，也有太多艰辛。我的大学生活的主旋律还是学习，我所选学的专业是软件技术，在这条道路上走了那么久，也有一些小小的感悟与体会。

还记得上初中时，英语课本上有一篇关于比尔盖茨的文章，当时真的很佩服比尔盖茨，也就是那时我才第一次接触到软件一词，学过那篇文章后我有个想法，就是也要做个比尔盖茨，可是由于家庭条件的限制，那也只能是个美好的梦想。后来上了高中，再报考时我就选择了软件技术这个专业，这样我想就向那个遥远而又美好的梦想迈进了一点点吧。

然而当我真正上了大学，学了这个专业，我才知道要做个比尔盖茨是多么的难，要想学好我的专业要花费很大的精力。第一学期我们开设了C语言这门课程，当时我学着真的是云里雾里、一窍不通，很是失落，学了不久之后我开始觉得自己可能并不喜欢这个专业，只是一时昏了头，错以为喜欢了。现实的打击让我有点不知所措，然而我已经选择了它，有句话说：既然选择了远方便只顾风雨兼程。我既然选择了这个专业，我便也只有硬着头皮也要走下去了。有了这样的想法之后，在之后的一段时间里，只要是没课的时候我就抱起了C语言课本，努力的看，记语法知识，语法规则，学语句、小算法等等。经过一段时间的研究学习，我发现C语言并没有我想象中的那么难

了，还是很有意思的。就这样在学与玩中我的大学第一个星期就过完了。

后来又开设了很多课程，有VB、网络、数据库、操作系统、数据结构等。在这些课程中最令我头疼的就是数据库了，老师讲的时候老是划重点，讲的很少，当时学的时候真的好难受，一学期下来啥也不会，后来看书上的操作，一步一步的操作，才终于学会了建个数据库，做下备份还原等操作。开设的那么多课程也有我很喜欢的课程，比如数据结构，这门课程理论的比较多，上机操作的很少，这门课程是很需要理解的，当然有的还是要死记的。学习这门课的时候，我觉得并不像其它课程那么吃力，可能高中是学理科的缘故吧，理解起来并不太费劲。所以当时就很喜欢这门课，然而这门课表皮的好学，但要深学起来还是很有难度的，所以期末考试的时候我的成绩并不太理想，但这些打击不了我对它的兴趣，至少我知道我所学的这个专业还是有很多我是很喜欢的。

这样走着走着就到了大二的下学期了，那个学期，我们有一门课是C++，这门课的老师很和蔼，能力也很高，从他那里我学到了很多东西。老师教给了我们很多算法，也很系统的讲解了语法知识，还教我们做小系统，有的时候他会给我门们一些小系统的代码，让我们去改写，刚开始的时候我也是不会，后来经过学习请教改写成功了，这个时候我就会很开心，很有成就感。就这样在学与玩中，在快乐和忧愁中我们迎来了我们的大三时光。

大三刚一开学，老师们就告诉我们这学期就上十二周的课，然后

就考试，就毕业了。这让我很有紧迫感，一想到毕业在即，心头就有种不舍，这儿有我美好的时光，然而我就要对这里说再见了。大三了我们的课全变成了专业课，也几乎全成了上机课，老师还给我们布置了一个程序，就是一个小组要交一个系统来算作成绩。我们这小组所选的课题是图书管理系统，针对这个系统，我们上机的时候，利用网络资源在网上查找了相关的资料，因为说实话，我们对此并不太理解，也只有通过网络来查找信息，做好需求分析，功能模块设计等工作。在这同时我们还去了学校的图书馆理解了相关的信息，这个系统并不要求功能有多么强大，关键在与一种锻炼，思维的锻炼，对所学东西的总结等。建立数据库时我们就根据需要建立几个表，里面的数据也是从我们学校图书馆里找来的。后来的界面设计，为了追求美观，我们又在网上搜了很多美丽的图片来美化界面。具体到功能的时候，有很多东西都不会，后来老师在课堂在做了讲解，我们就把它用到了我们的系统中，真的就是学一步做一步的。整个的系统做下来，我学到了很多东西，也对那么知识有了很好的应用能力。

现在这个星期也就到了期末，这短暂的校园时光也在飞速的流逝着。回首过去学习的经历，真是苦中有乐，乐中亦多苦，然而无论如何这些都已经走过去了，未来的路还要我们好好的走下去。人生本就是一个不断的学习的过程，也是一个不断完善的过程，在未来的道路上我会更加努力地学习，走出一个美好的人生。

第三篇：某大型公司软件开发管理制度

某大型公司公司软件开发管理制度 版本：1.0 SDM审批：

QA经理

[时间] CTO

[时间]

目 录

1.目的和作用 3 2.适用范围： 3 3.参考文件 3 4.适用对象 3 5.软件开发流程 4 5.1可行性研究与计划 4 5.1.1实施 4 5.1.2 文档 4 5.1.2.1 应交付的文档 4 5.1.2.2 提交步骤 4 5.2需求分析 4 5.2.1实施 4 5.2.2要求 5 5.2.3交付文档 5 5.2.4审批 5 5.3概要设计 5 5.3.1实施 5 5.3.2要求 6 5.3.3交付文档 6 5.3.4补充说明 6 5.3.5审批 6 5.4详细设计 7 5.4.1实施 7 5.4.2要求 7 5.4.3文档 7 5.4.4审批 7 5.5实现 7 5.5.1实施与要求 7 5.5.2交付文档 8 5.5.3审批 8 5.6组装测试 8 5.6.1实施 8 5.6.2要求 8 5.6.3交付文档 8 5.6.4审批 8 5.7确认测试 9 5.7.1实施 9 5.7.2要求 9 5.7.3交付文档 9 5.7.4 补充说明 9 5.7.5 审批 9 5.8发布 10 5.8.1过程 10 5.8.2 文档 10 5.8.3 审核 10 5.9 交接 10 6.附录1：项目文档清单 11

1.目的和作用

本流程详细规定软件开发程的各个阶段及每一阶段的任务、要求、交付文件，使整个软件开发过程阶段清晰、要求明确、任务具体，实现软件开发过程的标准化。2.适用范围：

公司的软件开发产品均适用。3.参考文件 各种文档模板 文档命名规则 交接流程 4.适用对象

软件管理人员，软件开发人员，软件维护人员 5.软件开发流程

5.1可行性研究与计划 5.1.1实施

5.1.1.1 软件开发部分析人员进行市场调查与分析，确认软件的市场需求 5.1.1.2 在调查研究的基础上进行可行性研究，写出可行性报告 5.1.1.3 评审和审批，决定项目取消或继续

5.1.1.4 若项目可行，制订初步的软件开发计划，建立项目日志 5.1.1.5 根据市场环境、公司软硬件情况预测十大风险因素 5.1.2 文档

5.1.2.1 应交付的文档 1）可行性研究报告* 2）初步的软件开发计划 3）十大风险列表* 4）软件项目日志* 5.1.2.2 提交步骤

1)适用于以后各阶段的文档提交。

2)项目相关文档用sourcesafe进行版本管理，相关书写人员可根据各文档模板形式撰写文档，正式提交的文档以存入软件管理服务器相关目录时间为准。以后每次修改都应注明修改内容。

5.2需求分析 5.2.1实施

5.2.1.1 调查被开发软件的环境

5.2.1.2 软件开发提出的需求进行分析并给出详细的功能定义 5.2.1.3 做出简单的用户原型，与用户共同研究，直到用户满意

5.2.1.4 对可利用的资源（计算机硬件、软件、人力等）进行估计，制定项目进度计划（可有相应的缓冲时间）

5.2.1.5 制定详细的软件开发计划

5.2.1.6 QA部门制订质量控制计划和测试计划 5.2.1.7 编写初步的用户手册 5.2.1.8 评审 5.2.2要求

5.2.2.1 必须以运行环境为基础 5.2.2.2 应有用户指定人员参加

5.2.2.3 需求说明书必须明确，并经过用户确认 5.2.3交付文档

1）软件需求说明书 2）用户手册(概要)* 3）更新后的软件开发计划 4）项目进度计划* 5）QA计划 6）测试计划* 7）更新后的十大风险列表* 8）软件日志* 5.2.4审批

5.2.4.1 经评审通过的各项内容形成相应的文档后，提交给项目经理审核确认 5.2.4.2 软件需求说明书经项目经理确认后再提交给CTO进行审核确认。

5.3概要设计 5.3.1实施

5.3.1.1确定目标系统的总体结构

l 对于大型系统，可按主要的软件需求划分成子系统，然后为每个系统定义功能模块及各功能模块间的关系，并描述各子系统的接口界面

l 对于一般系统，可按软件需求直接定义目标系统的功能模块及各功能模块间的关系 5.3.1.2 给出每个功能模块的功能描述，数据接口描述，外部文件及各功能模块部的关系 5.3.1.3 设计数据库或数据结构

5.3.1.4 制定各阶段开发的目标（以下称里程碑）计划 5.3.1.5 制订第一个里程碑的测试计划 5.3.1.6 评审 5.3.2要求

5.3.2.1 在设计目标系统的整体结构时，应力争使其具有好的形态，各功能模块间应满足低耦合度，而各功能模块内应满足高内聚度。功能模块的作用范围应在其控制范围之内。5.3.2.2 在设计目标系统的总体结构时，应降低模块接口的复杂性，提高目标系统的可靠性 5.3.3交付文档

1）概要设计说明书 2）数据库/数据结构设计说明书 3）更新后的用户手册* 4）更新后的项目进度计划* 5）更新后的十大风险列表* 6）更新后的软件开发计划 7）更新后的软件项目日志* 5.3.4补充说明

5.3.4.1 测试程序的编写需与项目经理协商根据开发小组和QA小组的工作量确定由QA组还是由开发组完成

5.3.4.2 每一个里程碑又可分为详细设计、实现、组装测试、确认测试、发布、交接等阶段。5.3.5审批

5.3.5.1 经评审通过的各项内容形成相应的文档后，提交给项目经理审核确认 5.3.5.2 数据库/数据结构设计说明书、概要设计说明书经项目经理确认后还须提交给CTO进行审核确认。5.4详细设计 5.4.1实施

5.4.1.1 将概要设计产生的构成软件系统的各个功能模块逐步细化，形成若干个程序模块（可编程模块）

5.4.1.2 确定各程序模块之间的详细接口信息 5.4.1.3 撰写拟定单元测试计划 5.4.1.4 评审 5.4.2要求

5.4.2.1 确定程序模块内的数据流或控制流，对每个程序模块必须确定所有输入、输出和处理功能。

5.4.2.2 规定符号的使用，确定命名规则。5.4.3文档

1)详细设计说明书 2)单元测试计划* 5.4.4审批

5.4.4.1 经评审通过的各项内容形成相应的文档后，提交给项目经理审核确认.5.4.4.2 详细设计说明书经项目经理确认后还须提交给CTO进行审核确认。

5.5实现

5.5.1实施与要求

5.5.1.1 对每个程序模块用所选定的程序设计语言进行编码，写出的程序应该是结构良好、清晰易读、且与设计一致，符合公司编码规范

5.5.1.2 单元测试：开发人员按单元测试计划对自己编写的程序进行测试

5.5.1.3 编程及单元测试过程用sourcesafe进行版本管理，主要由项目组长负责 管理。

5.5.2交付文档 单元测试报告 5.5.3审批

所有文档必须提交给项目经理审核确认。5.6组装测试 5.6.1实施

5.6.1.1 开发组单元自测完成后，填写测试申请单连同要测试产品清单交给QA 5.6.1.2 相关QA人员根据提交申请单将源程序、文档等拷贝到测试中产品目录 5.6.1.3 执行测试计划中所有要求的组装测试

5.6.1.4 对测试结果进行分析，生成当前问题列表（BUGLIST），返回项目组长 5.6.1.5 开发人员经过分析，修复并自测完毕，生成BUG修复报告，返回QA 5.6.1.6 完成：反复直至QA通过。5.6.2要求

5.6.2.1 组装测试应保证模块间无错误的连接

5.6.2.2 应对软件系统或子系统的输入/输出能力进行测试，使其达到设计要求 5.6.2.3 应测试软件系统或子系统正确能力和经受错误的能力 5.6.3交付文档

1）运行的软件系统源程序清单 2）组装测试计划* 3）当前问题列表（BUGLIST）4）BUG修复报告 5）组装测试分析报告 5.6.4审批

所有文档必须提交给项目经理审核确认。5.7确认测试 5.7.1实施

5.7.1.1 模拟的环境中进行强度测试，即在事先规定的一个时期内运行软件的所有功能，以证明该软件无严重错误

5.7.1.2 执行测试计划中的所有确认测试

5.7.1.3 使用用户手册，以进一步证实其实用性和有效性，并改正其中的错误 5.7.1.4 对测试结果进行分析，生成当前问题列表（BUGLIST）5.7.1.5 反复查找BUG原因，直到修复 5.7.1.6 对所有文件进行整理 5.7.2要求

5.7.2.1 全部系统存储量、输入及输出通道，以及处理必须有足够的余量 5.7.2.2 全部预期结果、测试结果及测试数据全部存档 5.7.3交付文档

1)确认测试计划 2)更新后的用户手册

3)更新后的项目进度计划* 4)更新后的十大风险列表* 5)更新后的软件项目日志* 6)测试产品清单

7)当前问题列表（BUGLIST）8)BUG修复报告 5.7.4 补充说明

5.7.4.1 QA部门将测试清单中缺少的文档也列入BUGLIST 5.7.4.2 对于测试中重现与未重现的BUG均要有说明 5.7.5 审批

所有文档完成后须提交给项目经理审核确认。

5.8发布 5.8.1过程

5.8.1.1 经测试合格的产品QA填写发布申请表连同发布文档一起提交给QA经理、项目经理、CTO 5.8.1.2 QA经理、项目经理、CTO审核发布申请

5.8.1.3 QA人员将发布产品（包括源程序、执行文件及相关文档）放入发布中产品目录并生成安装程序 5.8.2 文档

1)当前版本说明 2)发布文档 3)用户手册 4)安装手册

5)发布产品检查清单CHECKLIST 6)发布产品审批文档 7)更新后的软件日志* 5.8.3 审核

所有发布文档须经QA部、项目经理、CTO审核确认。

5.9 交接

参见交接流程。

注：带*号文档可根据项目大小、时间要求适当增减

6.附录1：项目文档清单

文档名称 编写 阅读 审批 项目跟踪文档

软件项目日志 项目经理 CTO 十大风险列表 项目经理 CTO 项目进度列表 项目经理 CTO 当前问题列表 测试 项目经理，QA，开发 技术工作文档

可行性研究报告 分析 项目经理，开发，QA，测试，维护项目经理，CTO 软件需求说明书 开发 项目经理，开发，QA，测试，维护项目经理，CTO 用户手册 QA 项目经理，QA，测试，维护，用户项目经理，QA经理，CTO 概要设计说明书 开发 项目经理，开发，QA，测试，维护项目经理，CTO 数据库设计说明书 开发 项目经理，开发，QA，测试，维护 项目经理，CTO 详细设计说明书 开发 项目经理，开发，QA，测试，维护项目经理，CTO BUG修复报告 开发 项目经理，开发，QA，测试，维护 项目经理 测试分析报告 测试 项目经理，开发，QA，测试，维护 项目经理 项目计划

软件开发计划 项目经理 CTO 质量控制计划 QA 项目经理，开发，QA，测试，维护 项目经理，QA经理 测试计划 开发，测试 项目经理，开发，测试，维护 项目经理

配置管理计划 项目经理 项目经理，开发，QA，测试，维护项目经理，CTO 项目交付文档

当前版本说明 QA 项目经理，QA，CTO，用户 项目经理，QA经理，CTO 发布文档 QA 项目经理，QA，CTO，用户 项目经理，QA经理，CTO 安装手册 QA 项目经理，QA，CTO，维护 项目经理，QA经理，CTO 发布产品检查清单 QA 项目经理，QA，CTO 项目经理，QA经理，CTO 发布审批文档 QA 项目经理，QA，CTO 项目经理，QA经理，CTO

第四篇：软件开发实习心得

软件开发实习心得

参加软件开发实习的同学，你们从中收获了哪些实习心得?不妨分享一下吧!以下是软件开发实习心得，欢迎阅览!

软件开发实习心得1

不知不觉，在XX实习的日子快过去半个月了，记得刚来XX的头几天，感觉非常不适应。首先是环境：这里吃的东西很贵，而且这里的物价很高。其次是XX人：XX人办事的效率很高，这就是铁人的精神吧。

对于以上种种，待了3，4天基本就适应了，难怪一些长辈老是说：习惯了，就好了。

来的第一天，我们听了付X萍老师讲了一节课，可以说完全不知所云，但还是可以听到一些东西的，譬如：工作环境的适应，人与人之间的交际，处理各种事情的能力，其中最重要的就是养成良好的工作习惯。有良好的工作习惯，才会被上司，老板和同事认可，将来也会比同辈有着更快更多的升职机会，而且一个良好的工作习惯，无论你从事哪个行业，都是受用终生的。然后，就是认识我们的董亮老师了，一个可亲可爱的老师，传说中他们一个月会赚十几万呢!天文数字，望尘莫及啊。

在随后的一段时间里，我们被分为了八组，每组六七个人，有一个组长带领。我们组织作一个项目论坛，在第二，第三个礼拜感觉没有刚来时那么拘谨了，我更明显感觉到自我计划，制定目标的重要性了。在我们犯错误的时候，老师会惩罚我们，陈发的方式很另类唱歌或者讲笑话，不算是体罚大事可以达到对我们的约束。然而，歇息期间有组织我们做游戏，看似很简单的游戏其实是想培养我们合作意识。

在实习的过程中，我深刻的体会到了三点：第一，项目是以迎合客户和使用者为目的的，不可能像教师那样为我们制定一套教学计划。想要知道些什么，渴望懂得些什么，全要靠你自己想学，你自己不问，没人会主动来告诉你。第二，纸上得来终觉浅，绝知此事要躬行!在短暂的实习过程中，让我深深的感觉到自己在实际运用中的专业知识的匮乏，在行业中的经验真的很重要。

第三，能更早的接触你所在行业的真实情况。不出来自己转一圈，根本不知道自己学的一些专业知识，哪些是十分重要，十分实用的。就比如说英语。以前听老师说过，听朋友也说过，将来工作了，英语相当有用，外企就更不用说了。当时没什么感觉，但当我频繁的看到一打打英文资料手册、帮助文档时，我已经切身地，的的确确地感受到英语的重要性。

这次实训让我学到的东西太多，使我受益非浅，它让我知道了工作上的辛

苦，让我知道工作并不像在学校里学习一样轻松。不过，虽然辛苦了点，但能让我学到不同的东西、很充实，我心里还是高兴的。人非生而知之，要学得知识，一靠学习，二靠实践。没有实践，学习就是无源之水，无本之木。以上就是我在成都的进行实训的心得和感受。不到半年的时间就将步入社会的我们，面临是继续深造，还是就业的压力，我想我们更应该把握住最后的一段时间，充实、完善自我，争取做一名出色的大学生!对于这次实习，我很珍惜也很怀念。

软件开发实习心得2

本人自XX年9月份参加工作至今, 六个月的实习时间已经结束。在这段时间里, 在领导和同事们的悉心关怀和指导下, 通过自己的不懈努力, 在各方面都取得了进步。

实践让我的技能不断增长, 工作能力不断加强。刚开始工作的时候, 发现自己以前在学校学习的知识很死, 知识

面很窄, 以前做的练习项目的实用性也不是很好。在开始的几周公司给我们实习员工培训了xxxx平台的使用, 通过这次培训使我认识到xxxx平台的优势, 可以大大提高软件开发效率

随后我就加入到xxxxx税源控管系统项目的开发中, 成为开发小组中的一员。在项目开发过程中一边是同事们的悉心指导, 一边是自己反复琢磨与理解, 几个月下来大大提高了自己业务和技术两方面的技能, 已经能够比较熟练的掌握基本的工作方法和一些技巧, 而且能够独立完成一些模块的开发。

通过实践, 我解决实际问题的能力得到了很好的锻炼。工作中也遇到了很多的以前没有遇到过的新技术, 面对技术难题我总是直接面对, 没有逃避, 也因此自学了好多新的技术, 大大提高了自己的自学能力, 也加深了对自己工作要负责的信念。在项目开发过程中也遇到了一些自己确实无法解决的困难, 在经理和同事的帮助下也顺利的解决了，在此表示感谢。

在开发团队中, 加强了自己的团结精神和集体感, 对工作认真负责, 对团队认真负责。通过这个项目不仅学习到了很多技术也了解了整个项目的大体流程, 从需求分析、数据库设计、详细设计、代码编写、测试、项目维护等方面, 使自己不仅从一个代码编写人员的角度还从一个整体的角度来看整个项目开发, 加深了软件开发概念的理解。

不断学习使我对工作有了更进一步的认识和了解。不懂就学、就问, 是一切进步取得的前提和基础。因为有大学专业课的底子和参加过专门的java培训使我在工作过程中遇到的技术知识能更快的理解和掌握。工作中时常遇到新的问题, 就需要查阅相关资料, 请教同事和经理, 一个问题一个问题的解决, 一个困难一个困难的克服, 不仅将原有知识温习巩固, 产生新的理解, 而且学到很多新知识, 有了许多新的认识。但某些认识都还是肤浅的, 还需要我在实践当

中去不断深入地理解。

现场开发与维护使我不仅从一个开发人员的角度而且从客户的角度去思考问题。在项目的开发后期, 也就是项目即将上线的阶段我与其他几位同事被派往现场去开发与维护项目。以前的开发都是根据需求分析来进行, 功能要求一般在分析里面都写的很清楚, 但是在现场开发直接面对客户, 客户提出的需求一开始只是一个大体的功能描述, 如何将这个只是语言描述的功能转化为技术实现需要很强的抽象能力和对业务的深入理解, 这个过程大大锻炼了自己的综合能力。在第一时间接触客户的需求, 从客户的角度思考问题, 只有更了解客户需求才能更合理的设计软件的结构, 功能。

软件开发实习心得3

短短两周的很快就过去了，在xx的实习马上就要过去了。虽然只有短短的两周，但我学会了很多知识，熟悉了软件开发的流程，也很好的增强了自己 的动手能力。

我是一名即将大四的学生，纵观现在的就业形势，国家高校的扩招，世界金融危机的横扫，大学生应该有一种居安思危的紧迫感，特别是对已经度过两年大学的我来说，毕业并不是一个遥远的词汇。宝剑锋从磨砺出，梅花香自苦寒来，缺少了平时的锻炼，没有厚积当然不能有薄发。首先我得有思想上的紧迫感，在学校学习的都是理论知识，实践经验则是少之又少。综合能力强的人才才是这个社会需要的，成长成为社会需要的人才是我的个人奋斗目标。有了强大的精神动力，有了坚如磐石的毅力，相信成功并不遥远。

首先，我的自我能力得到了加强。在实习的前几天主要进行的是与JAVA有关知识的学习及预备知识的普及。在这之前由于种种原因我没有学习过JAVA，所以对于J我几乎一无所知。但我曾经学习过C++，所以对语言的理解和接受能力还不算太慢，尽管老师讲解

速度较快但我还是尽量跟上老师的速度。在这个过程中我学会一种自学方法可以在第一遍时不求甚解，先了解知识框架，之后再在使用的过程中不断加强对知识的理解，从而较快的学会知识并应用于实践。

其次我的实际的操作能力得到了加强。知识讲解告一段落后我们就进入了紧张而又短暂的项目中。但不得不说刚开始就碰了一鼻子灰代码书写总是出错。由于对原理理解不够透彻，语言使用缺乏足够经验所以进度极慢。在经过多次的讨论后我们对项目理解逐渐深入，所以在此投入的过程就比较顺利了。在这个过程中我明白了实践和理论的差距及二者不可分割的关系。

最后是团队协作能力的提高。在整个过程中团队协作发挥着不可替代的作用。从在刚拿到项目时对项目进行分析，然后进行分工，之后就开始工作，既各干各的又不失默契的合作。在这个过程中我们谁遇到问题会互相帮助解决提高

了工作效率。由于各种原因，我们这组也存在些问题(自己编)。

这次实习拉近了我就和社会的距离，也让自己在实践中开拓了视野，增长了才干。社会和大学一样也是受教育和学习的地方，在(写实习地)的实习我收获颇丰，再次感谢实习期间各位老师的指导教诲，你们给我的知识财富将让我受益终生。但是我知道学无止境，仅仅这段时间的学习还是不够的，在以后的生活中我会继续努力学习，培养自己能力，进一步完善自己。

第五篇：软件开发核心心得

软件开发核心心得

在一个有效的组织中，必定拥有杰出的一线人才。软件设计也是一样的，一线人才的素质决定了软件的质量。从敏捷的观点来看，代码是检验软件过程是否有效的最终标准。目前为止，以及在短时间的未来，我们都不太可能完全脱离代码进行软件设计。所以，软件过程中的任何一个活动都是为了能够产出优秀的代码。所以，代码才是核心。

1.代码是软件开发的基础

编码是软件开发过程中最基本、最底层的技艺，然而也是最重要的技艺。任何一个领域的专家都需要花费大量的时间来进行基本技艺的锻炼，木匠需要花费大量的时间来锻炼他们对各种工具的掌握，厨师则需要练习刀工和火候。程序员也是一样的，对我们来说，语言的各种特性必须要了然于胸。而对软件的管理也需要从代码做起。

从2000年到现在，国内兴起了一股软件工程热，需求管理、配置管理、甚至CMM。面对纷至沓来的各种方法学、UML、OOA，大家似乎已经热衷于这些概念本身了，却往往忽略了软件开发中最基本的元素:代码。在和很多软件组织的接触过程中，我们认为大多数组织急切需要的并不是这些工程理论，不是说这些理论不重要，而是这些组织的症结不在于此。很多的组织连代码的质量都管理不好，又何谈其它呢？代码管理是基础的基础，从管理的角度上来看，任何一个组织的管理都需要一个从上至下的管理过程，有基层的管理人员，也有高层的管理人员。对代码的管理就是软件开发中的基层管理，它起到的作用就是能够把需求、设计的思路贯彻到最终的代码中。

“管理无大事”。对软件的管理也是一样，大部分的问题都是由于很小的原因引起的。例如，一个产品如果后期在debug上花费了大量的时间，那么，这种现象是由于什么原因引起的？一种可能的原因是前期的代码设计中对代码质量的把握不严。每一次代码功能的演化并不会产生太多的问题，但是当代码累积越来越多的时候，问题也就慢慢出现了。那么如何解决呢？可以加强QA的力量，也可以引入复审，还可以引入单元测试。总之，要有一种方法对代码进行控制。

软件的开发过程就象是一部精密的机器，任何一个环节的变化，都会对其它的环节产生影响。把软件过程按照瀑布的形式进行划分是一种分解的处理思路，但同时我们还应该看到不同活动之间的相互影响。软件开发中的生命周期模型也是一个层次模型，从业务建模一直到软件实现，需要跨越数个层次，同样会出现执行不力的情况，例如，代码设计偏离需求、偏离设计的情况比比皆是。

如何避免这种情况呢？这就需要我们从源代码的角度，反思其上游的实践活动，是否足

以约束代码设计？就拿XP来说，他解决这个问题的方式是尽快的进入代码开发阶段，从代码开发中发现问题，并在下一轮的开发中解决。这种思路是正确的，但XP毕竟是方法论，他不会告诉你过于细节的东西，尽管XP已经提供了大量面向代码的实践。因为方法论的抽象级别比较高，使得他必须舍弃部分的细节。而这篇文章告诉你的，就是这些细节。就像我们在下一节中讨论的例子，需要在代码中加入对异常的处理，那么，异常的源头在哪里呢？是需求，在需求中，我们发现了一些业务的非正常的处理序列，发现了一些业务实体的限制性的要求，所以在代码实现中，就需要有相应的异常处理。在例如，一个优秀的异常处理，还需要让客户端程序员了解可能发生的异常，以保证不同代码间正确的集成。

2.面向对象的代码

面向对象的代码已经在现在的软件开发中占据了主流的位置，面向对象的思路也有其优势所在，就像后文所讨论的，面向对象代码有着非面向对象代码的很多优势，而软件业中很多新的思潮的产生，也都是基于面向对象语言的，所以我们关注的代码将是面向对象代码。

面向对象的思想来自于抽象数据类型。对于面向对象来说，它最重要的改进就是把世间万物都描述为对象，而类则描述了同一种对象的特征，而不是像传统的开发方法那样，按照机器指令的执行顺序来进行设计。当然，面向对象代码最终仍然是要按照时序来执行的，但是从程序员的角度看来，面向对象代码更侧重于对象之间的交互，多个对象各司其职，相互协作以完成目标。而面向对象技术的发展，也是朝着更加贴近我们世界观的方向发展。从这点来看，有人说完全没有程序设计经验的人学习面向对象可能会更加的容易，因为他不需要从原先的时序程序的桎梏中摆脱出来，但这未必是事实。面向对象决不是一种简单的程序设计思路。这是我们的观点，也会在下文中反复的论证。

和所有的职业一样，程序员，或者是面向对象程序员，始终坚持的一点就是严谨。你会看到各种各样优秀的代码，但那决不是一次能够写成的，要不断的尝试，不断的改进。为什么重构和测试优先是敏捷方法中很重要的一项实践？因为程序员不是神，他们需要慢慢改进他们的代码。虽然罗马不是一天能够建成的，但是在编写面向对象代码的过程中，有一些实践是需要坚持的，它体现了我们所说的严谨。

3.编写并管理面向对象的代码

编写优秀的面向对象代码并不是一件容易的事情，优秀的OO代码如行云流水，糟糕的OO代码让人觉得浑身起鸡皮疙瘩。编写优秀的OO代码要求程序员有一定的自我修养，能够以抽象的思路看待问题，找到问题的核心并对问题域进行分解。它强调的是一种解题的思路，但这个解不是唯一的。

典型的例子是设计模式，设计模式确实给了我们以很大的启发，通过它，我们能够了解到优秀的代码是如何用于解决实际问题的。但是是不是你必须在软件中照搬设计模式呢？如果你这么做，那么你对设计模式的理解仍然不够。我曾和在建筑行业的朋友聊起Christopher Alexander的建筑的永恒之道。他很兴奋的告诉我，那确实是一本很好的书，能够引发人很深的思考，但是现在也有另外的一种观点，认为美仍然是无形的，应该发自建筑师的内心。对这句话我思考了很久，其实建筑是给人使用的，因此最重要的是它能都给人带来的价值，隐含在其中的那种活生生的气质，这是建筑师文化底蕴的外在表露。所以，Christopher Alexander在那本书中的目的，也是为了找到一种总结自己观点的方法，来总结自己对人文的认识。至于现在大家对他的思路提出了质疑，那也是一件好事，这说明大家对建筑之道的认识到了新的高度。建筑是这样，软件中的模式也是一样的，我也曾热衷于研究模式的使用，直到某一天我猛然惊醒，与其沉迷于模式的表面形式，为什么不去研究隐藏在它背后的文化底蕴呢？武侠小说中常说无招胜有招，模式的应用也应当到达这个境界，你如果可以在不经意间应用模式的思想，那又何必拘泥于模式的形式呢？

编写优秀OO代码虽难，但还有更难的事情，就是让整个开发团队都产出优秀的OO代码。我们刚才说了，OO对问题的解不是唯一的，但各个不同的优秀解汇集到一起，可能就是一个糟糕的解，这是风格和架构的问题。你如何在团队中制定制度，营造氛围，让优秀OO代码成为团队最终的成果？这些问题，在我看来，要比CMM难得多，这个问题并不是靠花钱就能够解决的。如果能够解决这个问题，这个团队的创造力一定是惊人的。

4.面向对象软件开发过程

普通的软件开发过程和面向对象开发过程有着很大的不同。回想我们在非面向对象中开发过程中，最经常采用的任务分配方法就是以软件模块为单位，这样的好处是分配简单，不同任务之间耦合程度低，容易操作。坏处是几乎无法做到重用，也缺乏整体性的设计。而面向对象软件开发则不同，它是以类、类集合作为基本单位的。类之间关系错综复杂（虽然我们提倡低耦合的设计，但类之间的关系仍然是相对复杂的）。这种情况下程序员之间相互协作的要求就非常之高，这种关系如果处理恰当，则能够完全体现出面向对象的威力，否则，那将会是一场大灾难，面向对象的软件开发过程要养成一些好的习惯：

4.1 尽量简化和稳定客户端。

个人编程可以是一种享受，但团队开发始终是一项严谨的职业活动，因此多考虑别人，不要设计复杂的接口，虽然你省事了，但这会给理解和使用你的接口和人造成障碍。

4.2 准备一份简洁的文档，并保持更新。

随便一种形式的稳定，可以是代码，可以是UML图，也可以是纯粹的文字（估计没几个程序员喜欢这种形式）。只要它能够传达你的代码的目的，那就足够。记住，更新代码后，同时更新你的文档。过期的文档不仅是废纸这么简单，它会给其它人造成麻烦。切记！

4.3 尽可能多的考虑异常和错误的情况。

写出一个功能并没有什么，但是要把这个功能写的非常的完善那就很难了，因为你需要考虑各种各样的情况，正常的、非正常的。所以，写完一个类的定义应该是，完成编码和稳定，并通过原定的测试。本文摘自惠集网