学习软件编程的学习心得心得体会_1

学习软件编程的学习心得心得体会篇一：软件开发心得总结 有感于网盘开发过程 有感于网盘开发过程 . 1 一、软件开发个人体会： . 2 二、做软件开发我觉得要明白： . 2 三、在开发中遇到问题应该怎么去解决？ . 2 四、怎么样才能提高自身的能力？. 2 五、怎么样才能做好软件开发？ . 2 六、文档的重要性 . 3 七、我的收获 . 3 八、网盘项目开发的最大体会 . 4 九、软件测试（单体测试和连接测试） . 4 一、软件开发个人体会： 1. 软件领域中的知识在于积累。 2. 做软件开发，就类似算数学题和世界杯足球赛一样：重在结果，而不在乎过程。 3. 软件服务于人类，软件是在解决一些生活中的问题和错误，问题决定解决方案。 二、做软件开发我觉得要明白： 1. 职业的乐趣： (A) 用自己的智慧去创建新事物的快乐 (B) 开发对别人有用的东西 (C) 不断学_来充实自己 2. 职业的苦恼: (A) 总是追求完美 (B) 所有要实现的功能由他人而定 (C) 概念设计计是有趣的，但找Bug总是很苦恼的 三、在开发中遇到问题应该怎么去解决？ 1. 2. 3. 4. 不明白就多问，不要自已一直去琢磨。 一个问题如果30分钟还没有解决就应该考虑是不是问问别人。 一个问题在没有用过3种以上的方法解决过就不要去问别人。 解决问题思路是关键： 相信问题总归有解决的办法，就算连技术上都没法实现的问题，相信通过良好的沟通终究也会有解决的方法。 5. 解决问题的前提是：理解别人的意思，理解别人的需求，多沟通，及时给客户反馈信息。 四、怎么样才能提高自身的能力？ 1. 程序员怎么样进步最快？ 理论结合实践 2. 不要怕出错，不怕遇到错误，有错误就有挑战，这样才可以进步，但不要让同一个石头 把你绊倒2次。 五、怎么样才能做好软件开发？ 1. 首先要明白解决的问题是什么，理解问题，其次再决定怎么解决这个问题 2. 碰到很复杂的问题，我们就简单想，把问题简单化，细化到能够实现为止 3. 出了问题，我们要先分析问题，然后知道引起问题的原因，最后并想出问题的解决办法 4. 我们应该从2个方面去把握一个项目：从业务角度和项目的关键问题上去把握一个项目 (A) 从不同的系统场景 (B) 从不同的用户角色（充当什么角色） (C) 从不同的系统使用角度（拥有那些权限） 5. 其实我觉得开发人员说实在应该要比使用系统的人更了解系统需求，只有真正彻底的了 解了项目的业务需求，我们才能做真的做好这个项目 六、文档的重要性 记得我当初刚开发项目的时候都是写个大致的需求说明书，做一个E-R图，画几个大致的数据流程图，然后建立数据字典和表结构关系。 再接着搭建一个开发环境，配置几台服务器，划分一下模块，分工，我们就可以Coding了，一直到项目结束了，也没有完整的设计文档，更没有完整的测试文档，虽然这样的确是很快的完成了Coding工作，感觉上好像节省了好多成本和开发时间，但后期的维护和Bug 就是经常出现的事。 小项目没有文档关系不大，但如果遇到一个大项目的时候，那这样的开发方式就很有问题很危险的。 大项目没有文档： 首先维护就很麻烦，也很乱，写的代码，过几天都不知道它是完成什么功能的了，其次系统的稳定性和可靠性也让人怀疑，扩展性就不用说了。 七、我的收获 A.程序员大多都不喜欢写文档,我们以前也是特讨厌,记得以前都是系统开发完了，为了应付项目验收，就匆匆忙忙的一组人在那里补文档。在我们的思想里,所谓的文档就是一些废话,一句话硬是用十句话来代替的无聊透顶。 B.代码风格要规范 以前做项目，我们都是不怎么去注意代码风格和写代码的规范，都是稍微想一下就直接开始写代码了。注释也很少用，总感觉我们自己写的代码，我们怎么会不知道它做了些什么事呢 ？总觉得我们自己写的代码我们怎么会不知道它是用来做什么的呢。一直都不相信这是个事实，但事实上，项目验收后，系统刚开始使用的人少，也就不会出现潜在的错误，随着时间的增加，久而久之，当大量用户并发访问的时候，系统的Bug 就暴漏出来了，那时你再用熟悉的Eclipse打开整个项目的源码时，再去看自己写的代码的时候，真的发现，我们定义的这个变量名是什么意思啊 ？ 我们的这个Flag 是用来判断什么的啊 ？我们的if（）中条件不知道是判断什么？ Function （） 也忘记是什么功能了？ 想想好可怕啊。 难道真的都忘记了吗 ？回答是肯定的： 真的忘了。 C.心得体会: 通过做该网盘项目，在这2年的锻炼中，我们才真的体会到，良好的文档是正规研发流程中非常重要的环节,一个好的程序是先写好设计文档再进行编程的，在设计文档的指导下，才能写出安全的代码。如果你不写文档，一开始就写程序，这样你就不会按已设计好的路线走，而是想到哪写到哪。小功能还好说，要是大功能，就容易混乱. 刚开始我们还很不_惯这一系列的编程风格，很多的规范，尤其是命名，方法和注释，都有这着很多限制，让我们觉得真罗唆，写个程序完成功能不就可以了吗，明明1小时做完的事情非得让人用3、4个小时去做，我们现在真的明白这样做的好处了，我们已经_惯这样的编程风格了，这也养成了我们的一个编程_惯了，深有体会啊。 最忙的时候就是我们成长和收获最多的时候。 八、网盘项目开发的最大体会 我们觉得项目开发的开始时候，应该由项目负责人很好的对项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题，以及里面用到的很多专有名词做个细致的说明，而不是从一开始就分几本式样书，给个静态Html 的Demo看看，然后搭建好开发环境就按照式样设计书来开发。 九、软件测试（单体测试和连接测试） 我们首先认为，编写程序的时候不要想出了问题再解决，而是要想如何不会出现问题，要根据经验来预测可能出现的问题，然后避免出现。 测试，说的直接点就是给软件找错误。 很多人认为发现错误是软件测试的唯一目的,查找不出错误的测试就是没有价值的测试,实际上我们不这么认为。 我们觉得对开发人员来说，我们要把测试出来的Bug都应该做个分析，知道错的原因之后，我们就应该在下个项目中防止类似的错误发生，而真正来提高我们开发的效率。 篇二：软件开发良好_惯(学_心得) 学好JAVA的十大良好_惯 国家队每一次踢球失败后都要说这么一句:我们回去后要好好总结,下次会打得更好! 总结不代表就能改过原有的不足,也不代表就能进步了 (一)充分利用MSDN因为我个人觉得它胜过任何一本编程参考书 MSDN是 Microsoft 当前提供的有关编程信息的最全面的资源，它包含微软最新的技术数据库，加上易学易用的全文检索功能，让您迅速找到任何您需要的技术参考数据 (二)加强自我管理,善于作自我总结,分析自已的优点及缺点 中国境内百分之八十以上的领导人在百分之八十以上的场合的讲话中都有类似的观点,所以在这里我是不多说了,反正这一条用在什么行业什么地方都不会有错的,人生最大的敌人不是就是自已吗 (三)养成良好的文档_惯 良好的文档是正规研发流程中非常重要的环节,一个好的程序是先写好设计文档再进行编程的，在设计文档的指导下，才能写出安全的代码。如果你不写文档，一开始就写程序，这样你就不会按已设计好的路线走，而是想到哪写到哪。小功能还好说，要是大功能，就容易混乱甚至失控.那么如何写文档呢?其实我认为没有统一的标准,虽然国家及一些NB的人总结了很多的模板,但每个人的_惯不同,如果你不加以修改或创新,就套用某个标准,我相信写起来会很吃力及说不清的难受,因此我觉得只要能将你的设计思想及实现算法或步骤描述清楚就是好的文档,我强烈建议广大程序员朋友们在写文档时要善于用图表来说明你的思想,我们不是作家,也可能作文都经常性地不及格,写出五官端正的文章对我们来说可能不容易啊!好好地利用VISIO,ROSE或别的工具来表达你的思想吧! (五)代码风格要规范，严谨，效率要高。 (六)掌握好跟踪调试技巧. 跟踪调试程序是一件繁琐而又复杂的事情，所以掌握必要的调试策略及技巧却可以使这些工作变得轻松起来.强烈建议你去看一下老美Everett N.McKay及Mike Wooding写的书Debugging Windows Programs,你一定受益匪浅. (七)养成自我测试的_惯 测试工作应由测试工程师来做,但在你写完一个模块或一个软件时,还是要自已先测试一下,保证不要出现一些低级的错误. (八)善于交流善于沟通,特别是经常与一些高手交流一下学_的心得体会 有人说,程序员的性格大多内向不喜欢说话,其实是有些误会了,不是不喜欢而是话不投机,我的脑袋一天到晚都在不停地转,函数,数据,算法啊充满了我的世界,我那还有时间与你谈一些无聊的话题,话要找对人了,才容易谈下去,书上说过听君一席话,胜读十年书,你要找的就是这种豁然开朗！ (九)阶段性地做一下专题总结 知识要温故而知新,因此我程序员要养成阶段性地做专题总结的_惯,比如你这个月学_或在做与多线程有关的模块或项目,那么在你做完后,你就可以好好地总结一下所有与多线程相关的技术,包括理论知识,实践方法以及各种技巧及优秀文章等等,这对你各种能力的提高将有很大的帮助,你试过了吗,如果没有,那就快点行动吧! (十)要有持之以恒的精神 我只是想说明要学好任何一门技术,最好要有持之以恒精益求精的精神,特别是学一些比较抽象比较难的技术,除了思考一下你的学_方法以外,还必须坚定你的目标及信念! 篇三：大型软件开发心得 大型软件开发心得 最近做的一个项目从需求分析到上线绵延了四个月之久，这也是目前接手过功能点最繁复，产品线对接最多的一个项目。从中得到的一些关于设计较大型产品的心得，拿出来跟大家分享。 立项前 1、统一元素设计需考虑周全 也许是初创团队的缘故，我不得不感叹团队对产品经理要求之严格之缜密，项目全程只有一个人负责，所以大到产品线对接，小到一句提示的位置和展示形式都需要一一推敲。 哪些元素应该做到统一？ a、提示方面：统一的操作成功/失败提示；统一的弹窗形式；提示语言采用较统一的句型；为空情况的友好提醒；溢出情况的友好提醒；表单实时验证的提醒形式等。 b、文字方面：是否有统一的段落前“”号；统一的链接状态；统一的字体、间距、行高等。 c、图片方面：调取图片的统一尺寸；如果是上传图片类的操作，需要考虑周全全站的调取情况，以及考虑是否统一预览图的尺寸等。 d、细节交互：未激活功能的按钮做“灰色”处理（例如用户没有勾选信息时批量删除按钮不可使用）；按钮点击的状态统一（例如增加“提交中”的按钮状态，以防止网速慢用户狂点某一按钮的情况）；特殊控件的统一等。也许会有朋友说，上面有些是交互设计师需要做的事，但我一直认为作为一个产品经理考虑周全一些，没坏处。这些“统一”同样可以用在验收阶段，要知道，即使一个像素也可以改变整个产品的感觉。 2、原有功能的去留 我一直觉得升级已有产品比开发新产品难一些。这就像栽培植物一样，新种下一棵果树无非需要选对了土地，然后刨个坑种下去，然而成长期的去病枝、打顶等各种修剪所消耗的精力往往更多。 改进已有产品常常需要面对一个最棘手的问题：原有功能是去是留？原功能去掉的话是不是会影响部分用户使用？是否需要通过公告、站内信、界面引导等方式友好地告知用户？怎样把对用户的伤害降至最低？ 原功能留下的话是不是可以优化完善？听到了什么用户群怎样的声音？是否要在这次升级中做调整？ 这些问题当接到项目的时候，产品经理就应该考虑周全了。特别需要注意的是，如果这个产品之前不是自己设计的，那么最好找到prd说明文档细细研究一遍，对把握不准的功能点找到原负责人确认，毕竟树苗是ta摘的，别把将来最能结果的枝干给砍了。 3、产品线上下游的对接 昨天有跟朋友聊起淘宝强势之处，就是产品与产品紧密捏合，线上线下、跨平台跨行业形成了一个盘根错节、根深蒂固的根基，无可撼动。 所以把握产品线上下游和产品周边很重要，即使一个看似简单的新闻展示页面修改也会牵扯到编辑后台、广告位管理、帮助中心，甚至是访问统计、数据需求的变更。 这要求在产品设计开始前，需要把该产品“连根拔起”，仔细梳理相关脉络，如果产品线够长，一个清晰的产品线结构图很有必要。 项目中 1、项目期间来自相关产品线调整的影响 学_软件编程的学_心得