软件开发实习心得

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

软件开发实习心得

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

软件开发实习心得1

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

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

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

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

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

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

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

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

软件开发实习心得2

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

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

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

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

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

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

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

中去不断深入地理解。

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

软件开发实习心得3

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

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

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

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

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

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

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

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

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

软件开发实习心得

一直以来期望从事自己喜欢的事业的我，对软件开发有者及大的兴趣，可由说种种原因使我从事工作以来走了好几年弯路，心中的梦想迟迟不能得以实现，可程序员的梦想从来没有从我的心中抹去，但这扇大门好像并没有向我敞开，今天，贵公司给了我敲开这扇大门的机会，让我真实体验了程序员的诞生过程。早就听说，程序员的前几个月是最苦的，可从来没有感受到，海马实习基地让我提前感受到了刚刚进入软件行业的压力和困惑，再也没有在自己家里随便写段小程序后的那种“自豪”感了。要面对每天必须面对的问题，再也不可能以“逃避”而了之了。也让我感觉到做为一个程序员所应该具备的基本素质在这不到一个月的实习过程中也让我深深体会到了作为一个合格的程序员应该具备的基本素质。

团队精神和协作能力是程序员应该具备的基本素质，最近的工作中让我深深休会到了这一点，由于小组成员配合不好，使本来很方便的cvs给自己的工作带来的及大的麻烦，一不小心自己写的的东西就会被小组别的成员在上传文件的时候给覆盖掉，一整天的工作可能就这样被反工，我们小组这次就是因为协作不好，导致各模块之间不法连接，给工作带来了及大的麻烦，消耗了大量的劳动力还没有提高工作效率。这使我深深的体会到：一个成功商业性软件的开发必须有一个有强大凝聚力的团队，个人的力量是有限的，团队精神和良好的协作会使我们做出优秀的软件。

良好的文档是正规研发流程中非常重要的环节，作为代码程序员，30％的工作时间写技术文档是很正常的，缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。这次的这个小小的项目，就因为文档上的一点点理解错误让我们花了很大的工夫去改代码，改页面。很庆幸的是，这是一个小项目，要是大项目，这种问题可能就会导致大量的代码修改，可见文档在一个项目中起者巨大的做用。

此外，良好的代码编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。作为一个程序员，对需求的理解能力也是很重要的，只有真正理解了一个模块的作用，才会写出高效率的代码，才能使整个软件项目作出来更加优秀，具备更好的安全性和稳定性，我在写代码的过程中就遇到了需求理解上的问题，使得写出来的代码功能不全，幸好不是给客户发现在，要不，这个软件的商业价值可能就会打折扣了。单元测试对于一个程序员来说是不可不做的一项工作，不做好测试就会给后期的集成工作带来麻烦，往往为了一个小问题会让我们查找好多模块，给后期工作带来很大麻烦。

这一段时间的工作也让我明白了一点：一个优秀的程序员必须不断的学习，随时总结，找到自己的不足，这样逐步提高，才能让自己很快的成长起来。建站侠客 发表于 2008-4-28 10:19

对软件开发的一点心得体会

一、前期规划：

我理解的前期规划是：在市场人员们汇总一个需求提交给产品专家带领的产品经理团队，然后经过这个团队根据公司具体情况再次分析和规划出一个最终需求文档。

这个需求文档应当首先提交给技术研发部门的负责人以及核心开发人员。由开发团队对其进行技术和风险分析。如果对此需求统一有异议的地方，需要返回给产品团队，重新修正需求。反复如此，直至需求完善准确，细致，清晰。

前期规划就像高楼的地基，如果马马虎虎，就算是一块砖块没摆好都可能导致整个高楼建设的失败。在规划中我认为，交流永远是需要双方积极主动，能认真听取每个人的建议。前期工作思维不慎重，不细致，不认真，不够完善，将产生连锁效应直接导致整个工程和项目的失败。

这种失败可能表现为：第一种，软件按需求实现但是功能根本不能满足用户需要。第二种，功能都有了，软件没有达到可用性、易用性。

对于第一种，当然是因为前期规划疏漏了某些细小功能，没能把需求文档做完善。应该是规划工作做的还不够认真和细致。

对于第二种情况，我认为更多是在产品设计规划方面经验还不够成熟。这种问题应该是很难避免的。因为每种新产品对产品团队来说都很陌生。即使以前做过类似的东西，也难免面面俱到。这只能通过不断努力和认真的态度来弥补。

前期规划的交流涉及了市场、产品和技术研发等多个团队之间。需要的不仅是团队内部的交流，更多需要协调好团队之间的交流。可能有时候需要公司高层和中层参与协调。

目前，很多开发人员深感项目的需求文档写的都很单薄。大家可以想一想，如果没有好的开始，怎么会有好的结束呢？需求文档单薄，不够细致，由谁来继续完善呢？难道让程序员们自己去完善。我想程序员也可能没有这种能力。对于程序员能把代码写的很健壮很稳定就已经是很不容易的事情了。

二、概要设计：

我理解的概要设计步骤：（以项目为中心的开发流程）

1〉项目经理仔细阅读项目需求文档。

2〉项目经理召集项目开发成员，开项目启动会议。具体商议项目的开发任务和责任分配。

3〉核心开发人员开发确定，以及各模块开发人员确定。

4〉由系统分析员和核心开发人员仔细阅读需求文档，对系统整个架构分析和做技术规划。

5〉系统分析员整理和书写最终的系统架构和概要设计文档。

6〉系统分析员在文档提交日，提交给项目经理。项目经理确认文档并审批。

7〉项目经理召集项目开发成员，开一个概要设计以及系统架构确定的会议。向每个成员分发文档，并讨论确定最终概要设计文档。

8〉开始详细设计文档的工作

三、详细设计：

1〉项目经理组织成立各个模块的开发小组，并确定开发小组组长（程序经理）。

2〉各开发组长书写各自模块的详细设计文档，开发成员需要协助，配合。

3〉在指定提交日，开发组长提交文档给系统分析员。由系统分析员审批。

4〉系统分析员组织召开一个详细设计文档确认的会议。

5〉然后开发组长分发各自模块的详细设计文档给程序员，程序员在指定时间内完成。

6〉程序员做内部测试。开发组长协调并配合。

7〉确认无bug提交给开发组组长。

8〉所有模块整合工作，由整个开发组成员参与完成。由所有开发组长和系统分析员负责主要部分工作。程序员协助和配合。

9〉对整合后工程做详细测试。

10〉确认测试通过后，开发组长根据开发成员表现以及提交成果填写绩效考核表。然后提交给项目经理。

11〉项目经理会召开项目总结会，同时向优秀成员颁奖。同时鼓励所有成员继续努力。对不能按时完成导致项目能按时提交，以及对导致失败的关键人员给与惩罚处理。

当然，以上只是一个简单的开发流程，一定是有很多不足的地方。希望能起到抛砖引玉的作用。大家都明白，流程和制度是死的，但人是活的，所以如何按流程做得好，关键还是在人本身了。没有一个流程和制度，一个团队也必将是一盘散沙。正所谓“无规矩无以成方圆”。这句话说得很有道理。

四、具体编码：

开发几个项目之后，对编写程序有了更进一步的了解。

好的程序应该具有: 易读性，易扩展性，容错性。

易读性: 所有变量和函数以及类名用简单易懂易记忆的命名方式。所有类和函数甚至变量都有关键的注释说明。这点很重要，也是最基础的。如果代码书写不够美观和易懂，我想自己以后也不想再看。就更别谈功能的扩展和新版本开发了。

易扩展性: 整体系统架构逻辑简单清晰。模块与模块之间尽量做到互不影响，也就是尽可能的独立。这部分工作主要体现在前期设计工作中，需要掌握好的设计经验和方法才能够做得比较好。

容错性: 对数据流和指针以及数组都做数据有效性检查；对第三方接口的调用失败的容错性。对所有代码都做调用失败后的错误处理。以及在大的工程中加入trace文件输出，把关键的数据流和关键处理部分的操作信息输出。以便对工程异常情况产生条件的定位，及时解决问题。

我觉得程序员能在这三方面做得很好就算一个优秀的programmer了。

五、调试、跟踪与测试：测试需要注意的：

对每个模块的接口做测试，数据边界的检查。在对整个模块做测试。

主要测试稳定性，效率以及功能是否正常。

确认单个模块完全正常后，再加入工程。

在系统架构设计的时候，可能会引入原型参考。要对原型做完成测试后，确认没有问题后，才可使用。可以采用VC自带Trace或者将信息输出为文本文件的方式跟踪程序并输出关键信息，以便定位程序异常的原因。对于通信模块的测试，特别注意服务端和客户端的数据流。可以针对性的写一个客户端或服务端的测试程序，检验通讯过程是否正常。在用VC做开发中，一定先要让Debug版本正常运行，保证没有任何异常，内存泄漏和Assert等调试警告信息。如果用到其他Lib,一定要保证Lib本身不存在问题。

这里只是提到一些自己容易忽略的东西，希望能对大家有所帮助，欢迎指正！谢谢。

第三篇：软件开发心得

软件开发心得体会

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

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

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

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

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

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

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

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

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

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

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

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

立项前

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

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

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

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

软件开发核心心得

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

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 尽可能多的考虑异常和错误的情况。

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