怎么样写程序可以不出bug

程序员遇到bug是在正常不过的事情了，就算非常资深的程序员也无可避免bug的存在，一般来说，除非你写一辈子 Hello World。
不过世界上的确存在一些凤毛麟角天才的程序员，他们差不多能做到这一点。接到任务之后，思考，冥想，在笔记本上画出数据结构或某个算法片段，腹稿打的差不多了就开 始编程，用 Vim、Emacs 或 IDE 工具，大部分时候能够一气呵成，然后构建代码，构造测试数据，运行程序，在反复调试中修复几个编程过程中没有考虑到的问题，就可以提交到代码库了。
他们的 代码交给测试和其他开发者，少有人能挑出 bug，因为他们对代码有敏锐的感觉，能够在别人忽略的地方发现代码的坏味道，并给出巧妙而优雅的解决方案。
他们是天生的代码创造者，这样的人往往效率高 而且少有错误，以至于会被一些平庸的团队忽略，因为技术领导总是会下意识的去关注那些最容易出事的环节，但这些人才是团队真正的脊梁，不是那些四处救火者。

这个怎么说呢，经验多了一些容易避开的bug当然是能避免的；但业务逻辑五花八门，总有出现bug的时候，资深程序员追求的不应该是一味的避免bug，而应该是处理bug的能力。

可以避免绝大部分bug，因为已经踩过的坑不会再掉进去。

　一、 沟通设计先行
　　为避免需求或业务逻辑理解的不完全或偏差， 或者设计上存在较大的缺陷， 导致后期不必要的返工， 耗费宝贵的时间和精力， 编程开发遵循的首要准则是沟通设计先行： 与需求方、业务方和工作伙伴多多沟通交流， 进行设计评审， 能够有效地减少因为需求、业务理解偏差导致的逻辑错误和个人经验不足导致的设计错误。 编程与交流活动的适当调节， 也非常有益于延长程序员的寿命。
　　软件工程师应下决心下功夫锻炼和提升自己的表达能力与语言沟通素养。
　　二、 尽可能复用
　　编写和测试可复用代码， 尽可能复用经过严格测试的可靠公共库。 代码复用、组件复用、框架复用、 接口规范复用、设计模式复用、开发架构复用、 甚至应用模板复用； 复用使得可以从 40% ， 甚至 60% 快速起步， 而不是从 0% 开始。工作量的压力小了， 很大程度上会消减因为进度压力导致的代码质量低下的问题。
　　创建一个应用工程模板， 将你在实际工作项目中所学习到的、所探索到的和所创造的重要知识、技术和经验聚合到这个系统， 让它成为你工作中的百宝箱。
　　三、 做的更多
　　之前对参数校验、前置条件、 结果校验是不是做得不充分， 补上吧！ 之前对错误和异常考虑是不是不够周全， 补上吧 ！ 之前的单元测试、 接口测试是不是基本没怎么做， 补上吧！
　　哇！ 也许你会说， 工作量增大了好多！ 有时间去做这么多工作吗？ 这就要应用到第三条法则： 做得更少。
　　四、 做得更少
　　“做得更少”有三层含义：
　　（1） 尽可能自动化， 减少手工操作， 凡是操作不方便的、信息需要记忆的， 就要集成到程序中自动化完成， 避免不必要的脑力消耗； 比如查看日志排查问题， 《使用getopt解析命令行一例》， 就编写了一个脚本， 能够获取所有应用服务器的日志并按照内容关键字进行筛选展示， 而不需要手动逐个登陆应用服务器去查看日志了， 也不需要记忆日志地址， 做到最简化， 还学到了新技能。 脑力应该思考最重要的事情， 尤其是判断和决策相关；
　　（2） 要尽可能创造新的技术和方法， 将耗时繁琐的工作变成轻松的工作； 比如编写单元测试是比较“没技术含量”的事情， 能不能编写程序自动化生成可执行的测试用例呢？ 这不就转换成“很有技术含量”的事情了。 《Jtester+unitils+testng：DAO单元测试文件模板自动生成》 展示了一个例子。
　　（3） Write Less and Do More. 《编程语言与可复用性》展示了 Python 是如何用一行代码来解决一个可复用性很强的小功能的。 日常编程中， 也应多思， 提炼出问题的核心概念及交互， 用更少的代码实现更多的功能。这是软件开发中最具创造力的地方。
　　所有繁琐的、没有“技术含量”的活， 都可以转化成非常需要创造力的、富有“技术含量”的挑战。 取决于做事思路的转换。
　　五、 创造“编程心流”
　　“心流”是做一件事非常流畅自如且非常享受的状态。 当处于“心流”状态时：
　　（1） 感觉时间过得很快， 不知不觉；
　　（2） 全身心投入， 热情创造；
　　（3） 专注、娴熟自如地做事；
　　（4） 如果有些事情不懂， 会努力去学会它。
　　六、 严格的程序测试
　　严格的程序测试可以找出很多常见的编程错误， 应充分信任程序测试的作用， 充分而严格地测试程序。
　　通过严格的程序测试， 将使编写代码的信心大增， 能够更大胆地重构， 尝试新技术， 拓展新领域。

从初入职场菜鸟到职场大咖，很多程序员在努力充实自己，有时候我们需要对自己进行一次能力定位，了解自己的优势和没有掌握的技术。芯学苑列出几点作为初入职场的新手评估自己，明了前进学习的方向。
1、技术能力(解决问题的能力)
这是非常重要的事;过硬的技术能让你得到面试机会，并在工作中游刃有余。当公司招聘一个Java开发人员时，是会优先考虑能力因素的。在实际的项目开发中，一个程序员的技术能力等于其解决问题的能力。
如果拿一个尺度来衡量这个能力的话，一个程序员的能力可以用能完成任务的数量和难度来衡量。一个程序员能基本无误的完成项目中的一个功能算是合格，但在此之前，他对项目的生产力为负，为他布置的任务，中间环节的沟通，修补bug的时间其实要多于自己直接完成该功能的时间的。能较好完成一个完整模块的程序员才算是较好的程序员，也是项目中的主要开发者。能独立完成整个项目才是优秀的程序员。
2、专业基础(知识的积累)
一个程序员的知识积累很大程度上决定了其解决问题的能力。知道如何编写代码是基本的技能，但是知道Java编程语言的原理，知道代码背后的算法将使你从人群中脱颖而出。
3、主流编程工具
今天，事实是，你不能成为一个样样都懂的人(杂而不精)。你必须选择你要掌握的工具。有时这是由工作的环境决定的，但是按照下面说的去做也是一个很好的选择：
构建工具：Maven或Gradle。
SCM：Git(不是GitHub。大不相同)。
构建自动化：Jenkins。
IDE：Netbeans或Eclipse——不仅用于编写代码，而且还从IDE中重构和调试代码。我遇到了很多没有如何从他们最喜欢的IDE调试的开发人员。
Bug跟踪：Bugzilla或Jira。
4、JSF的知识
应用程序服务器
所有Java开发人员应该知道如何在Apache Tomcat中部署。
当Glassfish开发停止时，下一个最好的事情是J Boss Wild Fly。
5、沟通的能力
沟通是我们做好一切事情的关键。我们必须与我们周围的环境保持互动，无论是在我们的私人还是职业生活中。一个良好的程序员知道如何在各种团体面表达自己。也许对你来说显而易见的东西在他人的角度来看并非如此。
从大的尺度(比如一个人的工作生涯)来看，一个程序员知识积累的多少只决定于其自学能力和他对编程本身的兴趣。
在一个分工明确的项目中，程序员需要理解产品，和领导沟通理解自己的任务，和同事们沟通以正确的方式进行合作。无论哪一个方面沟通出了问题都不是小事情，同时，程序员还需要正确的传达设计的实现难度，以及让别人正确的理解自己设计模块的接口。在不写文档时，正确的口头沟通非常重要，需要写文档时，良好的编辑能力也算做是沟通能力的一部分。
6、自学能力
这是一个非常重要的技能，在你自己的空闲时间学习新的技能。不要等待公司为你提供培训。你需要自己去学习新技术，提升自己在相关领域的水平。从Java后端开发到架构模式，总是有一些新事物值得学习。经常阅读博客和论坛，尝试加入本地聚会小组。你学到的东西可以帮助你的事业。知识刷新频率极快让人无法追赶的这个时代，难免会有超出自己知识范围的时候，此时你的自学能力决定了你能多快的完成任务。
7、良好的团队合作精神
无论是部分编程还是大型项目，所有开发人员都是作为团队的一部分在协同工作。你需要致力于团队的目的，或帮助新的团队成员克服障碍。不要存在这种“我只要做好我的本职工作，下班就直接回家”的态度。成为团队的一部分，帮助周围的同事，对自己的能力也是不小的提升。
就像拿破仑说的不想当元帅的士兵不是好士兵，追求参与一个大型软件系统的开发，是每个程序员的梦想。在此之前，应该学习更多的专业知识，达到优秀程序师的标准。最后希望各位程序员阅读本文后能够得到一些裨益，在这条路上走得更好。

对于c和c++，大家往往会把goto当做洪水猛兽来对待，但是我不得不说良好的goto语句确实可以简化逻辑，什么事情都不是绝对的，只要选择最适合自己的。特此强调：不滥用。

BUG对于程序员来说，简直就是噩梦一般的存在，一天天的，不想见到的人就是测试人员，每当他们出现的时候，就意味着，加班的时间到了，开启你的加班套餐模式！
而面对BUG，我们又不能不正面面对，如何提高自己的效率，赶紧回家陪女朋呢？只需要这两步：

一、如何快速的揪出BUG呢？下面这些小技巧或许能帮到你！
1. 输出语句
代码调试的首要工具就是插入可靠地、真实的输出语句。当输出语句数量庞大且不易于管理的时候，在输出语句里恰当使用记录系统，这可以说是一个等效的好方案。
2. 调试器
源代码调试器采用了输出语言方法里的逻辑推理。这样可以让程序员一行一行的单步执行代码，同时监测从变量值到底层虚拟机整个状态的一举一动。
3. Bug跟踪系统
在一些比较重大的软件项目里，使用bug跟踪系统是很有必要的。 一个简单的文本文件在项目里可以作为最初的bug跟踪系统。
4. Linter
在某些编程语言里，Linter可以执行对代码的静态分析，以便在代码编写和运行之前识别出问题区域；在一些其它编程语言里，Linter工具对于语法检查和增强风格是很有帮助的。
5. 版本控制
版本控制在代码排错里同样有着举足轻重地位，可以让程序员回滚修改较早版本的代码，尽可能在错误出现之前，在代码库里对错误进行修复。
7. 自动化测试
自动化测试就是一段代码用特殊的输入值来运行软件，以此来检测程序运行是否和预期的相符合。
二、在揪出BUG的同时，如何解决才是更为关键的一步。

下面列出一些常见的疑难BUG类型以及每种BUG的诊断方法：
1. 输出结果与预期不符。
这种BUG一般都是由于代码逻辑错误造成的，如果能在开发环境重现，一个优先解决方法就是单步调试，设定每一步代码的预期结果，然后跟踪判断实际结果是否与预期结果一致，不一致的分析原因，如果在开发环境无法重现，无法单步调试的，可以采用添加输出日志的方式判断哪一步的问题。
2. 系统异常报错。
这种情况下需要提取日志，找出错误堆栈信息，这时候重要的事情是要把堆栈信息看懂、看完整。这是很多经验不足的程序员常见的问题，就知道报错了，报的什么错，这个错代表什么一概不知。而且往往堆栈信息是一个套一个输出的，比如Java里面表象上看是一个NullPointer Exception，但是如果你看到底，就会告诉你到底是什么错误引发了这个NullPointer。
3. 系统Crash。
这个问题常见的原因是负载过高、并发过高、或者配置错误。常见的就是内存溢出。这时候要首先排除配置错误的原因，主要靠查看Crash Log来分析原因，如果Crash Log没有有用的信息，就得排查硬件、内存、网络等方面的设置，看是否有配置错误的地方。再找不到就在测试环境用开发模式进行压测和调试。
4. 系统响应缓慢。
这种问题一般是存在资源竞争或者系统资源不足的情况，先检查服务器内容、CPU、网络情况，如果服务器压力过大，排查应用系统负载情况是否异常，如果这些数据都正常，就需要排查代码中的性能瓶颈，可以采用profile工具或者直接输出时间戳的方式查看哪个操作占用时间最长。特别需要留意依赖第三方接口的情况，比如同步的方式发送邮件、发送短信、写文件等。
当然了，以上只是一些小小的总结，具体问题还是要具体分析的！

写完程序以后可以回去看一下，看看自己是否能够出现错误，毕竟谁都会犯错，谁都避免不了犯错，真的是很正常的事情，都是可以理解的，如果没有检查出错误的话就那样就好了，等以后再过一段时间回来看的时候会检查出来的。

这种事情发生的原因，其实更多的是你对自己的不自信，你可以提升自己的自信心，其次可以去多练习一些比较基础的程序，这样的话等你慢慢发现自己的程序越来越成功的话，你就不会再担心自己会有bug发生了。

软件测试心得
，而且还经常写一些工作上的事，现在感觉自己老了似的，开始转型了，会选择写一些总结而不是琐碎，也许这是我以后当领导的征兆吧。
程序员是善于思考的一个职业，做过这行的都知道，写一个程序的过程都要经过构思、设计、写代码、测试到最后运行这几个步骤。慢慢地，这个习惯也被搬到了生活中，现在我才觉得，我平时做事这么的冷静善思考原来是工作影响的原因。
象我一样，大多程序员都有一个毛病，或者说一个习惯，自己编写过的代码都不愿意测试，他们凭着自己的习惯，理论上完成了代码的编写就认为自己的工作结束了，剩下的工作应该交给测试人员了。但实际上来讲，如果代码存在BUG，造成软件在运行期出错，那么测试人员和客户肯定会发现这些BUG的，再等到测试人员或者客户把BUG反馈回来的时候代价就已经很大了，不仅仅是时间的浪费，更重要的还有1、影响了客户对产品以及公司的信任度，2、影响了程序员自己的声誉，3、影响了代码的可读性以及质量，4、增加 了DEBUG的难度，5、对程序员的心理造成一定的影响。
首先，程序员应该克服自己身上的一些缺点，这是很重要的一点，因为每个程序员都有自己的编程习惯，而且每个程序员对自己刚刚完成的程序都会信心百倍的说“绝对没问题”，实际上这种想法很正常，因为每段代码都是通过程序员认真谨慎的思考和设计之后才写出来的，在设计时已经排除了很多问题，所以程序员不会将自己认为不正确的判断写到程序里，但这仅仅是理论上的想法，但人哪有不反错的时候。其实程序员在读其他人写的程序的时候，就会很谨慎，仔细找到程序上的错误，但对自己的代码就很难这样做，如果把这种谨慎应用到自己的代码上来，BUG会减少到最少。软件工程所说的各阶段工作想必大家都清楚，前期的设计以及需求分析才是一个软件工程的重点，这里也是花费时间最多的地方，当对要写的程序有了一个清晰的轮廓之后再动手编写代码。
第二，刚刚提到的前期设计，是指在编写代码之前所作的工作，这要求程序员对系统的整个结构以及逻辑有很清楚的理解，这也要求对系统的需求做到位。我没有写过文档，所以这里不谈文档了。思路清晰很重要，但每个人并不能将系统的整个设计思路都记在脑袋里，那最好就写下来，特别是一些复杂的逻辑结构关系还有复杂的算法。
第三，代码的编写，要尽量减少拼写的错误，严禁使用关键字作为变量来使用，要尽量做到代码模块化，并且保证其正确性和可重复使用性。因为是模块组成的，写过之后可以将每个模块部分单独测试，因为代码量少了质量自然提高了。对顺序执行要求很高的函数尽量不采用调用子函数的方法，让程序按顺序走吧。
第四：代码检查以及系统功能测试，这是保证代码质量的最后一步了，我们可以写一些代码模块或者小工具来进行测试工作，跟踪变量值的变化，使用一些小技巧在这个阶段都是必要的，这里和测试人员的测试不同之处在于：仍然让程序员的注意力放在其自己的代码范围内，减小了排错的难度。
按照如上步骤来走的话，那么我想你的系统应该足够健壮了。
把对待别人代码的态度放到自己的代码上来，也就是反复的Review自己的代码检查逻辑错误也是相当好的办法。别把自己辛苦写的代码看的很值钱，在团队中尽量与别人分享、Review代码这是实际工作的经验。
作为一个优秀的程序员要具备这些习惯，看自己的代码就象对待自己的一样，爱惜、呵护是必须的，同时也要象园丁一样及时修剪多于的树枝来让自己的代码走正确的道路。