软件开发心得

第一篇：软件开发心得

软件开发心得体会

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

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

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

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

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

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

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

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

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

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

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

软件开发实习心得

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

软件开发实习心得1

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

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

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

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

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

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

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

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

软件开发实习心得2

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

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

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

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

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

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

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

中去不断深入地理解。

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

软件开发实习心得3

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

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

首先，我的自我能力得到了加强。在实习的前几天主要进行的是与JAVA有关知识的学习及预备知识的普及。在这之前由于种种原因我没有学习过JAVA，所以对于J我几乎一无所知。但我曾经学习过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

一、软件开发个人体会：.................................................................................................................2

二、做软件开发我觉得要明白：.....................................................................................................2

三、在开发中遇到问题应该怎么去解决？......................................................................................2

四、怎么样才能提高自身的能力？..................................................................................................2

五、怎么样才能做好软件开发？.....................................................................................................2

六、文档的重要性.............................................................................................................................3

七、我的收获.....................................................................................................................................3

八、网盘项目开发的最大体会.........................................................................................................4

九、软件测试（单体测试和连接测试）..........................................................................................4

常熟理工学院SIG小组

3/28/2013

一、软件开发个人体会：

1.软件领域中的知识在于积累。

2.做软件开发，就类似算数学题和世界杯足球赛一样：重在结果，而不在乎过程。3.软件服务于人类，软件是在解决一些生活中的问题和错误，问题决定解决方案。

二、做软件开发我觉得要明白：

1.职业的乐趣：

(A)用自己的智慧去创建新事物的快乐(B)开发对别人有用的东西(C)不断学习来充实自己 2.职业的苦恼:(A)总是追求完美

(B)所有要实现的功能由他人而定

(C)概念设计计是有趣的，但找Bug总是很苦恼的

三、在开发中遇到问题应该怎么去解决？

1.2.3.4.不明白就多问，不要自已一直去琢磨。

一个问题如果30分钟还没有解决就应该考虑是不是问问别人。一个问题在没有用过3种以上的方法解决过就不要去问别人。解决问题思路是关键：

相信问题总归有解决的办法，就算连技术上都没法实现的问题，相信通过良好的沟通终究也会有解决的方法。

5.解决问题的前提是：理解别人的意思，理解别人的需求，多沟通，及时给客户反馈信息。

四、怎么样才能提高自身的能力？

1.程序员怎么样进步最快？ － 理论结合实践

2.不要怕出错，不怕遇到错误，有错误就有挑战，这样才可以进步，但不要让同一个石头把你绊倒2次。

五、怎么样才能做好软件开发？

1.首先要明白解决的问题是什么，理解问题，其次再决定怎么解决这个问题 2.碰到很复杂的问题，我们就简单想，把问题简单化，细化到能够实现为止

常熟理工学院SIG小组

3/28/2013

3.出了问题，我们要先分析问题，然后知道引起问题的原因，最后并想出问题的解决办法 4.我们应该从2个方面去把握一个项目：从业务角度和项目的关键问题上去把握一个项目

(A)从不同的系统场景

(B)从不同的用户角色（充当什么角色）(C)从不同的系统使用角度（拥有那些权限）

5.其实我觉得开发人员说实在应该要比使用系统的人更了解系统需求，只有真正彻底的了解了项目的业务需求，我们才能做真的做好这个项目

六、文档的重要性

记得我当初刚开发项目的时候都是写个大致的需求说明书，做一个E-R图，画几个大致的数据流程图，然后建立数据字典和表结构关系。再接着搭建一个开发环境，配置几台服务器，划分一下模块，分工，我们就可以Coding了，一直到项目结束了，也没有完整的设计文档，更没有完整的测试文档，虽然这样的确是很快的完成了Coding工作，感觉上好像节省了好多成本和开发时间，但后期的维护和Bug 就是经常出现的事。

小项目没有文档关系不大，但如果遇到一个大项目的时候，那这样的开发方式就很有问题很危险的。

大项目没有文档： 首先维护就很麻烦，也很乱，写的代码，过几天都不知道它是完成什么功能的了，其次系统的稳定性和可靠性也让人怀疑，扩展性就不用说了。

七、我的收获

A.程序员大多都不喜欢写文档,我们以前也是特讨厌,记得以前都是系统开发完了，为了应付项目验收，就匆匆忙忙的一组人在那里补文档。在我们的思想里,所谓的文档就是一些废话,一句话硬是用十句话来代替的无聊透顶。B.代码风格要规范

以前做项目，我们都是不怎么去注意代码风格和写代码的规范，都是稍微想一下就直接开始写代码了。注释也很少用，总感觉我们自己写的代码，我们怎么会不知道它做了些什么事呢 ？总觉得我们自己写的代码我们怎么会不知道它是用来做什么的呢。一直都不相信这是个事实，但事实上，项目验收后，系统刚开始使用的人少，也就不会出现潜在的错误，随着时间的增加，久而久之，当大量用户并发访问的时候，系统的Bug 就暴漏出来了，那时你再用熟悉的Eclipse打开整个项目的源码时，再去看自己写的代码的时候，真的发现，我们定义的这个变量名是什么意思啊 ？ 我们的这个Flag 是用来判断什么的啊 ？我们的if（）中条件不知道是判断什么？ Function（）也忘记是什么功能了？ 想想好可怕啊。难道真的都忘记了吗 ？回答是肯定的： 真的忘了。C.心得体会: 通过做该网盘项目，在这2年的锻炼中，我们才真的体会到，良好的文档是正规研发流程中非常重要的环节,一个好的程序是先写好设计文档再进行编程的，在设计文档的指导下，才能写出安全的代码。如果你不写文档，一开始就写程序，这样你就不会按已设计好的路线走，而是想到哪写到哪。小功能还好说，要是大功能，就容易混乱.常熟理工学院SIG小组

3/28/2013

刚开始我们还很不习惯这一系列的编程风格，很多的规范，尤其是命名，方法和注释，都有这着很多限制，让我们觉得真罗唆，写个程序完成功能不就可以了吗，明明1小时做完的事情非得让人用3、4个小时去做，我们现在真的明白这样做的好处了，我们已经习惯这样的编程风格了，这也养成了我们的一个编程习惯了，深有体会啊。

最忙的时候就是我们成长和收获最多的时候。

八、网盘项目开发的最大体会

我们觉得项目开发的开始时候，应该由项目负责人很好的对项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题，以及里面用到的很多专有名词做个细致的说明，而不是从一开始就分几本式样书，给个静态Html 的Demo看看，然后搭建好开发环境就按照式样设计书来开发。

九、软件测试（单体测试和连接测试）

我们首先认为，编写程序的时候不要想出了问题再解决，而是要想如何不会出现问题，要根据经验来预测可能出现的问题，然后避免出现。

测试，说的直接点就是给软件找错误。

很多人认为发现错误是软件测试的唯一目的,查找不出错误的测试就是没有价值的测试,实际上我们不这么认为。

我们觉得对开发人员来说，我们要把测试出来的Bug都应该做个分析，知道错的原因之后，我们就应该在下个项目中防止类似的错误发生，而真正来提高我们开发的效率。

常熟理工学院SIG小组

3/28/2013

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

软件开发核心心得

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

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

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