学好JAVA的十大良好习惯 国家队每一次踢球失败后都要说这么一句:我们回去后要好好总结,下次会打得更好! 总结不代表就能改过原有的不足,也不代表就能进步了

(一)充分利用MSDN因为我个人觉得它胜过任何一本编程参考书 MSDN是 Microsoft 当前提供的有关编程信息的最全面的资源，它包含微软最新的技术数据库，加上易学易用的全文检索功能，让您迅速找到任何您需要的技术参考数据

(二)加强自我管理,善于作自我总结,分析自已的优点及缺点 中国境内百分之八十以上的领导人在百分之八十以上的场合的讲话中都有类似的观点,所以在这里我是不多说了,反正这一条用在什么行业什么地方都不会有错的,人生最大的敌人不是就是自已吗?管好自已认清自已,那还有什么搞不定的?

(三)养成良好的文档习惯 良好的文档是正规研发流程中非常重要的环节,一个好的程序是先写好设计文档再进行编程的，在设计文档的指导下，才能写出安全的代码。如果你不写文档，一开始就写程序，这样你就不会按已设计好的路线走，而是想到哪写到哪。小功能还好说，要是大功能，就容易混乱甚至失控.那么如何写文档呢?其实我认为没有统一的标准,虽然国家及一些NB的人总结了很多的模板,但每个人的习惯不同,如果你不加以修改或创新,就套用某个标准,我相信写起来会很吃力及说不清的难受,因此我觉得只要能将你的设计思想及实现算法或步骤描述清楚就是好的文档,我强烈建议广大程序员朋友们在写文档时要善于用图表来说明你的思想,我们不是作家,也可能作文都经常性地不及格,写出五官端正的文章对我们来说可能不容易啊!好好地利用VISIO,ROSE或别的工具来表达你的思想吧!

(五)代码风格要规范，严谨，效率要高。

(六)掌握好跟踪调试技巧. 跟踪调试程序是一件繁琐而又复杂的事情，所以掌握必要的调试策略及技巧却可以使这些工作变得轻松起来.强烈建议你去看一下老美Everett N.McKay及Mike Wooding写的书<<Debugging Windows Programs>>,你一定受益匪浅.

(七)养成自我测试的习惯

测试工作应由测试工程师来做,但在你写完一个模块或一个软件时,还是要自已先测试一下,保证不要出现一些低级的错误.

(八)善于交流善于沟通,特别是经常与一些高手交流一下学习的心得体会 有人说,程序员的性格大多内向不喜欢说话,其实是有些误会了,不是不喜欢而是话不投机,我的脑袋一天到晚都在不停地转,函数,数据,算法啊充满了我的世界,我那还有时间与你谈一些无聊的话题,话要找对人了,才容易谈下去,书上说过"听君一席话,胜读十年书",你要找的就是这种豁然开朗！

(九)阶段性地做一下专题总结

知识要温故而知新,因此我程序员要养成阶段性地做专题总结的习惯,比如你这个月学习或在做与多线程有关的模块或项目,那么在你做完后,你就可以好好地总结一下所有与多线程相关的技术,包括理论知识,实践方法以及各种技巧及优秀文章等等,这对你各种能力的提高将有很大的帮助,你试过了吗,如果没有,那就快点行动吧!

(十)要有持之以恒的精神

我只是想说明要学好任何一门技术,最好要有持之以恒精益求精的精神,特别是学一些比较抽象比较难的技术,除了思考一下你的学习方法以外,还必须坚定你的目标及信念!

第二篇：软件开发流程与规划学习心得

软件开发学习流程与规划心得

班级：软件0902 学号：090203049 姓名：杨菲

一、前期规划：

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

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

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

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

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

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

二、概要设计：

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

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

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

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

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

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

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

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

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

三、详细设计：

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

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

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

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

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

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

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

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

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

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

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

四、具体编码：

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

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

易读性: 所有变量和函数以及类名用简单易懂易记忆的命名方式。所有类和函数甚至变量都有关键的注释说明。这点很重要，也是最基础的。如果代码书写

不够美观和易懂，我想自己以后也不想再看。就更别谈功能的扩展和新版本开发了。

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

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

五、调试、跟踪与测试：

1 测试需要注意的：

1对每个模块的接口做测试，数据边界的检查。在对整个模块做测试。主要测试稳定性，效率以及功能是否正常。确认单个模块完全正常后，再加入工程。在系统架构设计的时候，可能会引入原型参考。要对原型做完成测试后，确认没有问题后，才可使用。

2 可以采用VC自带Trace或者将信息输出为文本文件的方式跟踪程序并输出关键信息，以便定位程序异常的原因。

3 对于通信模块的测试，特别注意服务端和客户端的数据流。可以针对性的写一个客户端或服务端的测试程序，检验通讯过程是否正常。

4 在用VC做开发中，一定先要让Debug版本正常运行，保证没有任何异常，内存泄漏和Assert等调试警告信息。如果用到其他Lib,一定要保证Lib本身不存在问题。

第三篇：软件开发心得总结

有感于网盘开发过程

有感于网盘开发过程 .............................................................................................................................. 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都应该做个分析，知道错的原因之后，我们就应该在下个项目中防止类似的错误发生，而真正来提高我们开发的效率。