程序员平时有必要记录debug吗

程序员平时有必要记录debug，

1.什么是debug

debug是一种运行模式，用来跟踪程序的走向，以及跟踪程序运行过程中参数的值的变化。

2.debug的作用

debug一般用来跟踪代码的运行过程，通常在程序运行结果不符合预期或者出现异常的情况下使用。所以使用debug模式可以很好的跟踪问题，帮助程序员处理bug。对每个程序员而言，基本上每天都要用到debug功能。

3.debug的使用

各种开发工具的debug基本上都大同小异，下面以Intellij Idea的debug使用为例。

1：团队精神和协作能力

把它作为基本素质，并不是不重要，恰恰相反，这是程序员应该具备的最基本的，也是最重要的安身立命之本。把高水平程序员说成独行侠的都是在呓语，任何个人的力量都是有限的，即便如linus这样的天才，也需要通过组成强大的团队来创造奇迹，那些遍布全球的为linux写核心的高手们，没有协作精神是不可想象的。独行侠可以作一些赚钱的小软件发点小财，但是一旦进入一些大系统的研发团队，进入商业化和产品化的开发任务，缺乏这种素质的人就完全不合格了。

2：文档习惯

说高水平程序员从来不写文档的肯定是乳臭未干的毛孩子，良好的文档是正规研发流程中非常重要的环节，作为代码程序员，30％的工作时间写技术文档是很正常的，而作为高级程序员和系统分析员，这个比例还要高很多。缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。

3：规范化，标准化的代码编写习惯

作为一些外国知名软件公司的规矩，代码的变量命名，代码内注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。

fans叫嚣高水平程序员写的代码旁人从来看不懂，这种叫嚣只能证明他们自己压根不配自称程序员。代码具有良好的可读性，是程序员基本的素质需求。再看看整个linux的搭建，没有规范化和标准化的代码习惯，全球的研发协作是绝对不可想象的。

4：需求理解能力

程序员需要理解一个模块的需求，很多小朋友写程序往往只关注一个功能需求，他们把性能指标全部归结到硬件， *** 作系统和开发环境上，而忽视了本身代码的性能考虑，有人曾经放言说写一个广 告交换程序很简单，这种人从来不知道在百万甚至千万数量级的访问情况下的性能指标是如何实现的，对于这样的程 序员，你给他深蓝那套系统，他也做不出太极链的并访能力。

性能需求指标中，稳定性，并访支撑能力以及安全性都很重要，作为程序员需要评估该模块在系统运营中所处的环境，将要受到的负荷压力以及各种潜在的危险和恶意攻击的可能性。就这一点，一个成熟的程序员至少需要2到3年的项目研发和跟踪经验才有可能有心得。

5：复用性，模块化思维能力

经常可以听到一些程序员有这样的抱怨，写了几年程序，变成了熟练工，每天都是重复写一些没有任何新意的代码，这其实是中国软件人才最大浪费的地方，一些重复性工作变成了熟练程序员的主要工作，而这些，其实是完全可以避免的。

复用性设计，模块化思维就是要程序员在完成任何一个功能模块或函数的时候，要多想一些，不要局限在完成当前任务的简单思路上，想想看该模块是否可以脱离这个系统存在，是否可以通过简单的修改参数的方式在其他系统和应用环境下直接引用，这样就能极大避免重复性的开发工作，如果一个软件研发单位和工作组能够在每一次研发过程中都考虑到这些问题，那么程序员就不会在重复性的工作中耽误太多时间，就会有更多时间和精力投入到创新的代码工作中去。

一些好的程序模块代码，即便是70年代写成的，拿到现在放到一些系统里面作为功能模块都能适合的很好，而现在我看到的是，很多小公司软件一升级或改进就动辄全部代码重写，大部分重复性工作无谓的浪费了时间和精力。

6：测试习惯

作为一些商业化正规化的开发而言，专职的测试工程师是不可少的，但是并不是说有了专职的测试工程师程序员就可以不进行自测；软件研发作为一项工程而言，一个很重要的特点就是问题发现的越早，解决的代价就越低，程序员在每段代码，每个子模块完成后进行认真的测试，就可以尽量将一些潜在的问题最早的发现和解决，这样对整体系统建设的效率和可靠性就有了最大的保证。

测试工作实际上需要考虑两方面，一方面是正常调用的测试，也就是看程序是否能在正常调用下完成基本功能，这是最基本的测试职责，可惜在很多公司这成了唯一的测试任务，实际上还差的远那；第二方面就是异常调用的测试，比如高压力负荷下的稳定性测试，用户潜在的异常输入情况下的测试，整体系统局部故障情况下该模块受影响状况的测试，频发的异常请求阻塞资源时的模块稳定测试等等。

当然并不是程序员要对自己的每段代码都需要进行这种完整测试，但是程序员必须清醒认识自己的代码任务在整体项目中的地位和各种性能需求，有针对性的进行相关测试并尽早发现和解决问题，当然这需要上面提到需求理解能力。

7：学习和总结的能力

程序员是人才很容易被淘汰，很容易落伍的职业，因为一种技术可能仅仅在三两年内具有领先性，程序员如果想安身立命，就必须不断跟进新的技术，学习新的技能。善于学习，对于任何职业而言，都是前进所必需的动力，对于程序员，这种要求就更加高了。

但是学习也要找对目标，一些小coding有些codingTO就是这样的coding上只是一些Cfans们，他们也津津乐道于他们的学习能力，一会学会了asp，一会儿学会了php，一会儿学会了jsp，他们把这个作为炫耀的资本，盲目的追逐一些肤浅的，表面的东西和名词，做网络程序不懂通讯传输协议，做应用程序不懂中断向量处理，这样的技术人员，不管掌握了多少所谓的新语言，永远不会有质的提高。

善于总结，也是学习能力的一种体现，每次完成一个研发任务，完成一段代码，都应当有目的的跟踪该程序的应用状况和用户反馈，随时总结，找到自己的不足，这样逐步提高，一个程序员才可能成长起来。一个不具备成长性的程序员，即便眼前看是个高手，建议也不要选用，因为他落伍的时候马上就到了。

具备以上全部素质的人，应当说是够格的程序员了，请注意以上的各种素质都不是由IQ决定的，也不是大学某些课本里可以学习到的，需要的仅仅是程序员对自己工作的认识，是一种意识上的问题。那么作为高级程序员，以至于系统分析员，也就是对于一个程序项目的设计者而言。

一、不提升非技术技能

我们认为非技术技能是项目成功的主要因素。这些非技术技能也可以称之为“软技能”，总体上来说，它已经被公司证明为能够驾驭企业和客户之间的长期商业关系，因此也能决定公司的成长发展路径。一些关键的软技能指标包括：

a.纪律——这是最重要的特征之一，缺乏纪律，最终会让这个开发团队在开发能力上“缺乏自信”。解决这一问题的矫正方法就是每天制定详细的to-do清单：兑现你的承诺、完成你开始做的事情、避免多重任务，因为这些往往会让你的生活产生混乱。

b.顾客的声音——不把客户置于决策的核心地位只会跟你们业务的原始目的相冲突。如果客户不高兴，即使你拥有世界上一流的专业知识和资源也不会起什么作用。保持符合客户期望的解决方案、及时交付才能体现出项目的真正价值。

c.沟通——尤其是当客户和供应商并不在同一地点的时候，明确而及时的沟通是填补服务空白的极好措施。主要集中在这三个方面你就能克服问题——进行主题讨论、清晰表达、干脆简洁。

d.了解需求——在整个开发生命周期过程中，决定成功和失败的之间的一个至关重要的区别将会给人留下深刻的印象。通过最初的头脑风暴法了解问题状态，以及后续的交货程序，这其中都要和客户完美配合。只有这样，客户才会赞赏你的工作，给你好评。

二、对编码不理智

古人云：善泅者溺，善骑者堕。但估计绝大多数的程序员都认为自己的编程技术绝对的牛。而同样真实的是，每一个代码，让不同的程序员去实现的话都会不可避免地发现它所存在的缺陷。所以说，只有通过在一个项目上的合作，程序员之间必然有的摩擦才能证明谁是最好的。健康的竞争是好事，但它不应该成为一个本来可以成功的项目的负担。

另一个创意阻碍是无法将预定义的模板使用在对你有利的开发项目里。几乎所有的编程语言有一个很好的在线/内置的代码片段存储库，可以修补代码，防止重新编程。然而，如果因为不理解需求或缺乏接触各种可用库/模板的话，这就意味着程序员最终会无意间将一开始就创建的代码付之东流。这不仅增加了开发时间，也提高了总体成本。另外一点就是，发布了的代码已经经过了质量检测，所以只有将它用作模板才能发挥它更大的价值。

三、不一定什么都要被理解

如果你是刚调到这个团队来的编程人员，对于手头的工作并不是很熟悉，那该怎么办?肯定是先看一些前任留下来的工作计划，要是他写的详细倒也没什么，如果写的不详细，估计会让你更加的挠头。

因此，推己及人，在需要交代的工作上，最好是把任务写的尽可能的详细。这么做也是非常现实的原因：能够把编程问题解决掉，最好是保证使用解释性的语言和英语发音来表示变量。一些基本的指针可以让你的程序更容易被理解，包括：

a.把所有参数、引用、方法和变量名称尽可能接近英语表达。保持文件名简短但有助于理解的功能。

b.使用++包装文字是一个好办法，能让代码和注释更加清晰。

c.将编写的程序保持在一个连续的流程上，尤其是在使用OOP基础上的语言：C、C和C++。

d.对于不同的代码块使用不同的描述名称。

四、不使用经过验证的工具和技术

程序员的好坏从他使用的编程工具和调试工具上就能看出。在异常情况的跟踪上，下面就是程序员经常会出现的常见错误。

对一些可能会对其它代码有影响的常见案例进行捕捉，处理这些比较常见的异常情况(而不是特殊的异常)意味着无意中除除掉了会抑制整个程序的残留部分，因此并不会影响他人的代码。

也许程序员可能带有恶意的意图来捕捉所有的异常情况，但即使是捕捉到了也不实施采取措施，这就是常说的“虚假安全阀”，这种异常处理手段是对整个软件的稳定和安全的一种妥协方式。

五、较差的控制版本

在任何涉及多个团队的项目里，当谈到版本控制的时候不去介绍使用最佳实践都是一个十足的罪过。版本控制的目的是确保由一个人执行的编辑或修订不去影响另一个人的工作。

版本控制不仅有助于将由两个或两个以上的程序员的编辑工作合并到一起，还有助于跟踪程序的更改历史。所以说，任何开发团队都应该做一些好的改进措施以确保强大的版本控制，这其中就包括：

为每个解决方案创建一个“逻辑单元”

给解决方案制定描述性的名称

确保你所使用的都是最先进的文件

频繁的向团队分享你所做的各种改变

六、拥有最新信息的个人代表不了团队

一旦有新员工加入，就立刻强制安排他参加专业培训，让他知道他的角色是用来干什么的，尽早产生创造力。例如一个测试人与加入之后，就应该向他介绍编程的理念，之后将培训重点放到测试实践上，而不是继续阐述编程的重要性。

现阶段的技术的进化程度比以往任何时候都要快，，所以要记住，定期培训是必不可少的，这是在给团队创造价值。例如一个Web设计师需要知道响应式设计，提供给设计师大量的用户日常使用的移动设备的不断扩张的样品，希望他们能获得灵感。

七、不恰当的测试

测试作为整个系统开发生命周期(SystemsDevelopmentLifeCycle，简称SDLC)的重要一个要素，通常不需要开发团队给出太惊人的结果。但是如果在测试环节没有付出恰当的、相应的努力的话，这是说不过去的。下面的一些方法或许对你的测试团队有用，至少在你们交付产品的时候能够给用户一个好的交代。

单元测试

实物模型

综合测试

八、注意安全漏洞

有的时候在软件开发过程中，就会遇见如下这样的安全漏洞：

A、不同组件之间意想不到的交互作用：a、输入不正确的验证信息b、SQL资料隐码攻击c、跨网站指令码d、命令植入攻击e、跨站请求伪造(CSRF)

B、难以实施的资源管理，包括：a、不尊重可用内存缓冲区b、对外控制c、使用有潜在危险的功能

九、和客户交流

最初的合同签订后，开发公司通常会忘记每天与客户进行产品上的信息交互，以至于在交货的时候还需要进行升级。两大关键的交流点可以让你和客户保持更好的、更长的关系：

在客户开问之前，开发方应该和客户进行交流沟通。

和客户保持周期性的交流。

十、避免标准实践面临的迫在眉睫的最后期限

通常情况下项目都会遇到进度延误的现象。然而，这不是说你有理由去偷工减料或者是在开发或测试阶段耍花招，未经测试的模块绝对是一个隐患，会让你的开发团队名誉受损的。一个更好的方法来管理延迟是提前告知客户并且积极执行延迟计划。只要延期的理由是有效的，客户应该会理解，也会给你额外的时间来解决这个问题。

---