第一篇：大型软件开发心得
最近做的一个项目从需求分析到上线绵延了四个月之久，这也是目前接手过功能点最繁复，产品线对接最多的一个项目。从中得到的一些关于设计较大型产品的心得，拿出来跟大家分享。
立项前
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、保持沟通。“说话容易，沟通很难。很多事除非对方自己想明白，劝是没有用的。所以，很多时候，沟通是个自己挣扎的过程”这话没错。需求变更直接会影响到下一道工序，产品经理需要将需求变更的细节和原因传达给相关人员，包括视觉、前端、程序、测试等。
这是很多产品经理表示非常痛苦的过程，因为可能会遭到数落和冷眼，日本有一个礼仪原则是“不要给别人添麻烦”，但是在项目中，这不可避免。
个人认为所有沟通的障碍都源于思想的不统一，如果让大家觉得这个需求修改是在浪费时间，那么沟通上的不畅快在所难免。项目不是这样算的，需求既然更改一定有所目的，产品经理需要将这个原因讲明白，不做修改或节约沟通时间导致的返工，后果往往更严重。
第二篇：软件开发心得体会
受某文化公司委托，开发一款用于视频和图像处理的软件，开发难度高，高到从未搞过，开发周期长，长到是我以前项目监控最长开发周期的两倍，开发成本之底，让我觉得程序员成了高级打字员。首先是需求分析书、产品规格说明书、设计说明书、代码规范说明书、测试计划，光文稿就不知道熬了多久才做完。
紧接着，遇到一系列问题，首先是语言选择，vc++和c#都是可以保证开发完成的选择，但是vc++内存容易报错，界面很难修改，而客户要求的界面质量甚至比程序的功能更严格，没办法，客户就是上帝，上帝做事一定有他的道理。c#语言易于开发，而且图形界面绘制也易于修改，可以做出客户体验很好的界面，但是在资源的消耗上，让我很吃惊。做到第二个月，大概的界面已经完成时，出现界面刷新的问题，刷新时开始卡，界面不流畅。没办法，改。
开会，总结，技术骨干找问题，拿出解决方案，力争第一次做软件把它做好：
重新做软件开发进度计划和软件测试计划，并且让独立功能demo制作和测试先行；
用direct draw、direct 3d或者opengl中的一个替代c#本身的gdi绘图，将在接下来的开发任务中加入进去。
事无巨细，当我满意的看着界面流畅，功能也已实现时，发现软件在低分辨率或者小本上根本乱到没法看，甚至是界面功能按钮错位，重叠等等。没办法，改。毕竟软件的多分辨率兼容和操作系统兼容是必须要做的。
接下来一大堆的麻烦找了上来，软件出现各种各样想都想不到的问题，总算是按时将第一个版本发布出去，并且开始接下来的升级开发任务。
最后，给刚刚接手软件开发项目的朋友一些忠告：
一、相关的文档不是给别人看的，而是给自己看的，相关文档一定要齐备，而且让所有涉及开发的人员都清楚的知道你文档里所要表达的意思；
二、一定要注意多做demo，多做实验，一个demo程序员几个钟头就可以完成，甚至更少，但是不做demo，核心程序没有做实验，其他的东西都围绕核心程序做了上去，到时候耽误的可不是几个钟头
三、程序设计要注重用户体验，当初客户对我要开发软件提出近乎苛刻的要求时我不在意，但是当我自己反复使用软件时有了很多体会，流畅美观的界面带给人心理的快感的确能替代一些尚未开发完整的功能带给用户的遗憾。
四、测试计划多次进行，分批进行，不要全部开发完成再对软件做测试。
还要坚持三个月，软件马上发布，希望大家的支持，谢谢！！！
软件开发心得体会（2）：
作为ｐｍ，有时需要招聘软件开发人员。这几年也一直在想，如何能在短短的30分钟或1小时内，快速识别出，坐在你对面的应聘人员，是否适合你的team。这几年也一直在观察和反思，经历过的team和现在team中的软件开发人员。有几点小的心得。
1. 倾向于招什么样的软件开发人员
- 经历过历练的人
吃过苦的，比如以前工作，经常被外派出差，又如曾在业内都知道以加班多而著称的公司呆过，还有些，留过学，但都是自己边打工边读书的，等等。
这些人员，入职后，通常都是能干活，能作为骨干。
- 思路清晰，思想活跃的人
让谈谈自己现在的产品，如果能清晰表述，有条理，会发散，但又能适当控制住，并收回到原话题。谈到技术问题和解决过的难题时，眼中有光芒：）
这些人员，今后工作中，学习能力强，对解决难题有帮助，能作为中坚。
- 坦诚、坚定、平和的人
面试中，坦诚，目光坚定。有时坦诚到甚至于显得有点木讷：）
我曾经遇到一个，面试下来，我最后介绍我们产品中用到的技术，他对这些技术知之不多，最后他说，“我可能不是非常适合，我知道一个朋友，他可能更适合。”我综合评估后，最后还是选了他，事实证明，他后来做的很不错。
坦诚坚定的人，会有恒心去学习，去解决问题。这些人员会作为team的基石。
- 有缺陷的人才
这是一个朋友（lance）的想法，我认为还是有道理的。
大公司，会看重综合素质，而如果是小公司，可以考虑选择一些有缺陷的人才。所谓有缺陷，是指，比如他英语很差，或沟通不清晰，但他能用程序员该有的思维去思考问题。这样的人员，通常进不了大公司，故会相对踏实地呆在一家公司，做好自己的工作。
2. 谨慎(请关注)考虑这样的开发人员
- 太活泼，太易兴奋
太易兴奋，说到投机处，“是是是是，对对对对。。。”，又蹦又跳，还时不时来点，“oh yeah, you are right“，然后还摆个 v 手型。讨论问题，不易固守在技术问题本身，时常跑到“我们产品中用到的技术（或第3方产品）很强，我挺他们，不可能有问题”，又或者“我们对客户要强势，我们要坚持我们的产品没问题"。
软件开发工作本身，显得比较沉闷，优秀的技术人员，都略显有些内向，因为解决问题，很多时候需要耐得住寂寞，时刻保持相对冷静。
太活泼的人，会在遇到问题之初，表现出很强的冲劲，但当长时间不能解决时，会表现出没有耐心，会经常抱怨（对team、管理、产品、流程等），非常情绪化。有些女程序员还会吵，会哭，这时项目经理只能放下手中的活，下去给她买点零食来哄哄，“莫哭，这里有你最爱吃的猫哆哩。”一边擦着鼻涕、眼泪，一边嘴里塞满东西，鼓鼓啷啷“这是酸角口味的，那个西番莲口味的才叫好吃..."
这些通常不太容易在面试时表现出来，在试用期时，要观察。
第三篇：软件开发心得总结
有感于网盘开发过程
有感于网盘开发过程 ............................ 1
一、软件开发个人体会： ...................... 2
二、做软件开发我觉得要明白： ........................ 2
三、在开发中遇到问题应该怎么去解决？ ................ 2
四、怎么样才能提高自身的能力？..................... 2
五、怎么样才能做好软件开发？ ........................ 2
六、文档的重要性 ........................... 3
七、我的收获 ............................ 3
八、网盘项目开发的最大体会 ..................... 4
九、软件测试（单体测试和连接测试） .................... 4
常熟理工学院sig小组3/28/2014
一、软件开发个人体会：
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都应该做个分析，知道错的原因之后，我们就应该在下个项目中防止类似的错误发生，而真正来提高我们开发的效率。
第四篇：软件开发实习心得
软件开发实习心得
一直以来期望从事自己喜欢的事业的我，对软件开发有者及大的兴趣，可由说种种原因使我从事工作以来走了好几年弯路，心中的梦想迟迟不能得以实现，可程序员的梦想从来没有从我的心中抹去，但这扇大门好像并没有向我敞开，今天，贵公司给了我敲开这扇大门的机会，让我真实体验了程序员的诞生过程。早就听说，程序员的前几个月是最苦的，可从来没有感受到，海马实习基地让我提前感受到了刚刚进入软件行业的压力和困惑，再也没有在自己家里随便写段小程序后的那种“自豪”感了。要面对每天必须面对的问题，再也不可能以“逃避”而了之了。也让我感觉到做为一个程序员所应该具备的基本素质在这不到一个月的实习过程中也让我深深体会到了作为一个合格的程序员应该具备的基本素质。
团队精神和协作能力是程序员应该具备的基本素质，最近的工作中让我深深休会到了这一点，由于小组成员配合不好，使本来很方便的cvs给自己的工作带来的及大的麻烦，一不小心自己写的的东西就会被小组别的成员在上传文件的时候给覆盖掉，一整天的工作可能就这样被反工，我们小组这次就是因为协作不好，导致各模块之间不法连接，给工作带来了及大的麻烦，消耗了大量的劳动力还没有提高工作效率。这使我深深的体会到：一个成功商业性软件的开发必须有一个有强大凝聚力的团队，个人的力量是有限的，团队精神和良好的协作会使我们做出优秀的软件。
良好的文档是正规研发流程中非常重要的环节，作为代码程序员，30％的工作时间写技术文档是很正常的，缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。这次的这个小小的项目，就因为文档上的一点点理解错误让我们花了很大的工夫去改代码，改页面。很庆幸的是，这是一个小项目，要是大项目，这种问题可能就会导致大量的代码修改，可见文档在一个项目中起者巨大的做用。
此外，良好的代码编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。作为一个程序员，对需求的理解能力也是很重要的，只有真正理解了一个模块的作用，才会写出高效率的代码，才能使整个软件项目作出来更加优秀，具备更好的安全性和稳定性，我在写代码的过程中就遇到了需求理解上的问题，使得写出来的代码功能不全，幸好不是给客户发现在，要不，这个软件的商业价值可能就会打折扣了。单元测试对于一个程序员来说是不可不做的一项工作，不做好测试就会给后期的集成工作带来麻烦，往往为了一个小问题会让我们查找好多模块，给后期工作带来很大麻烦。
这一段时间的工作也让我明白了一点：一个优秀的程序员必须不断的学习，随时总结，找到自己的不足，这样逐步提高，才能让自己很快的成长起来。建站侠客 发表于 2014-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了。
五、调试、跟踪与测试：
1 测试需要注意的：
对每个模块的接口做测试，数据边界的检查。在对整个模块做测试。
主要测试稳定性，效率以及功能是否正常。
确认单个模块完全正常后，再加入工程。
在系统架构设计的时候，可能会引入原型参考。要对原型做完成测试后，确认没有问题后，才可使用。
2 可以采用vc自带trace或者将信息输出为文本文件的方式跟踪程序并输出关键信息，以便定位程序异常的原因。
3 对于通信模块的测试，特别注意服务端和客户端的数据流。可以针对性的写一个客户端或服务端的测试程序，检验通讯过程是否正常。
4 在用vc做开发中，一定先要让debug版本正常运行，保证没有任何异常，内存泄漏和assert等调试警告信息。如果用到其他lib,一定要保证lib本身不存在问题。
这里只是提到一些自己容易忽略的东西，希望能对大家有所帮助，欢迎指正！谢谢。
第五篇：软件开发核心心得
软件开发核心心得
在一个有效的组织中，必定拥有杰出的一线人才。软件设计也是一样的，一线人才的素质决定了软件的质量。从敏捷的观点来看，代码是检验软件过程是否有效的最终标准。目前为止，以及在短时间的未来，我们都不太可能完全脱离代码进行软件设计。所以，软件过程中的任何一个活动都是为了能够产出优秀的代码。所以，代码才是核心。
1. 代码是软件开发的基础
编码是软件开发过程中最基本、最底层的技艺，然而也是最重要的技艺。任何一个领域的专家都需要花费大量的时间来进行基本技艺的锻炼，木匠需要花费大量的时间来锻炼他们对各种工具的掌握，厨师则需要练习刀工和火候。程序员也是一样的，对我们来说，语言的各种特性必须要了然于胸。而对软件的管理也需要从代码做起。
从2014年到现在，国内兴起了一股软件工程热，需求管理、配置管理、甚至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 尽可能多的考虑异常和错误的情况。
写出一个功能并没有什么，但是要把这个功能写的非常的完善那就很难了，因为你需要考虑各种各样的情况，正常的、非正常的。所以，写完一个类的定义应该是，完成编码和稳定，并通过原定的测试。本文摘自惠集网
精彩范文吧