优秀程序员是如何处理糟糕代码的

第一篇：优秀程序员是如何处理糟糕代码的

优秀程序员是如何处理糟糕代码的

可能你一行不好的代码也从来没有写过。这是有可能的，但在现实中又不太可能。

现实情况是，和这个星球上的其他所有程序员一样，你会产出安全漏洞、UI元素偏移，等等等等的代码。这并不能说明你是一个不好的开发人员。只是因为你是人类而已——一种不可避免会犯错的生物。

正是这种每个开发人员都有的“人性”缺陷，驱使那些优秀的开发人员敢于承担代码和底层基础架构的不足，有准备有计划地行动。下面是他们将做的事情。

假设 几年前，Netflix开源了Chaos Monkey和Simian Army的其他部分（Simian Army是一套工具，用来管理基于云的软件）。从本质上说，Chaos Monkey的范围贯穿亚马逊Web服务的基础设施，能够随意终止实例。从根本上说，它是一种通过创建最坏的可能方案来做最坏打算的方法。

正如Netflix的Cory Bennett和Ariel Tseitlin于发行之时在博客上这样写道，“代码会失败，并且你越不希望失败或一点也没有准备的时候，反而更加不可避免会出现故障。如果你的应用程序不能容忍实例故障，那么你是愿意凌晨3点被召唤呢还是在办公室里通宵？”

使用不可预测的方式来模拟故障，Netflix强迫注重基础设施的弹性。与其假设最佳的情形，还不如做一个最坏的打算。这样我们就能愉快地进入下一个进程了。测试

上面我们说了一个提高基础设施的伟大方法，那么代码呢？

Jeff Atwood，一个程序员的答案是：“你需要折腾你的代码。”他写道： 我相信，每个专业程序员职业生涯的一个关键转折点，就在当你意识到你才是自己最大的敌人，以及减轻这种威胁的唯一办法就是接受它的时候。将自己当作最大的敌人。打破你的用户界面。打破你的代码。折腾你的软件。

在实践中，这意味着“程序员至少需要对常见错误有一定的了解，然而，很多程序员往往不会这么去做，甚至是反着来。”这意味着你作为“编程之神”的责任也包括成为“测试之神”，通过“折腾”代码积极地来消除里面的错误。

Andre Medeiros补充认为我们应该对调试“精益求精”，因为开发人员需要对他们的代码做更多的事情。

“为了防止bug，你写出来的代码得让任何程序员都觉得简单。为了修复bug，你得理解你的代码。为了精密地了解代码，你需要列举和验证你的假设，如果有必要，你还需要构建调试工具。”

贫民窟上的摩天大楼

当然，对于我们的代码，其最大的问题之一是，它继承了如此多其他的代码。特别是在已建立的企业中，我们常常构建在旧代码上，从而导致了各种后续延伸问题。以下是Zeynep Tufekci的精彩描述：

将它比喻成造房子的话——也就说你将要在已经造好的底层基础上造二楼。但房子一开始造的时候并没有造好，没有打好地基，你也不知道哪面是承重墙。你只能尽可能地去猜，然后造好了一个楼层——用你的手指。然后你接着这样做。很多旧但控制着基础设施关键部分的软件系统就是这样运行的。在某一段时间内它也的确是可以工作，但每一个新楼层的建造意味着增加了更多的漏洞。我们正在代码中建设贫民窟上的摩天大楼——而且，还在地震区。很显然，我们对于改善这种情况束手无策，除非我们能够致力于去除技术债务。

但也许，只是也许，在心甘情愿折腾代码的过程中，你会发现消除技术债务是如此之重要。【编辑推荐】

是谁炒出来个程序员泡沫？

程序员痛苦的源头：一个bug

国外程序员常去的14个顶级开发社区

成为核心程序员的一些建议

程序员保值的4个秘密

第二篇：程序员如果做到每天写代码？

对于程序员来说，如何做到每天都写代码呢？可汗学院计算机科学学院院长暨jQuery创始人John Resig撰文分享了自己的心得和体会。下面，一起看看他是如何做到的----首先他给自己定下了几条规则：

1.每天必须写代码。可以写文档、博客或者其他的文章，但是必须要加进自己写的代码。

2.代码必须是有用的。不要格式化、重构的代码。

3.代码必须在午夜之前写好（为了避免不想熬夜而草率地写代码）。

4.代码必须是开源的，且要放到Github上（这样强迫自己小心写代码，并会考虑代码重用性及怎么创建项目前期的模块）。

当然，以上这些规则是灵活的。John Resig之所以制定这么严格的规则，是想提高自己业余项目的开发效率。他已经在连续20周的时间里每天写代码，这给他带来了好的工作习惯。鉴于此，John Resig为大家分享了自己坚持每天做业余项目后的心得体会：

利用最小化的时间写好代码。

我强迫自己每天花不少于半个小时来写代码（这真不是一件容易的事，尤其还得回忆前一天写了什么），在工作日期间一般不超过一个小时，但在周末我会花多一些时间做业余项目。

让写代码成为习惯。

要知道我并不关心自己在Github上的排名，因为我觉得做业余项目是自己的事，不要为了取悦别人而做。减肥和锻炼也是同样的道理，如果你不在乎提升自己，你永远都不会取得成功。

与不良情绪作斗争。

在开始实施每天写代码的计划前期，我时常焦虑项目没有很大的进展，毕竟业余项目没有时间限制。后来我意识到有这样的不良情绪对项目进展一点帮助都没有，反而会阻碍。所以要与不良情绪作斗争，现在我能心平气和地完成大量的工作，再也不会像以前那样为工作的事情忙得焦头烂额了。

安排、利用好周末时间。

对大多数人来说，利用周末时间做业余项目是项目取得大进展的绝好机会。而对于我来说，如果直到周末业余项目才能做好我会对自己很失望。之前我很少能完成所有自己想做的工作，这也就强迫自己不参加诸如参观博物馆、游公园等自己喜欢的周末娱乐活动，把时间留给工作。然而现在我强烈地意识到尽管业余项目很重要，但是也不应该忽略个人生活，所以学会安排时间很重要。

潜意识思考。

每天做业余项目写代码有一个有趣的副作用，那就是大脑会在潜意识里思考。因此，当我在散步、淋浴或从事其他非脑力活动时，我还在想着下一步代码该怎么写、出现问题了有什么解决的好方法，以前我每星期或者隔一个星期写一次代码从没出现过这样的情况。时间用来思考自然就不会再为业余项目取得的进展少而焦虑了。

每天写一点代码不易忘。

当接头做业余项目时总要付出“上下文切换”的代价，然而不幸的是思考是很难接上头的。所以我每天都做一点业余项目，让自己不容易忘记。

管理好时间，平衡工作、生活、业余项目。

现在的我已简单地学会了如何更好地维持工作、生活、业余项目的平衡，我知道自己每天都要做业余项目，所以我会更好地管理时间。如果我晚上有活动且很晚才能回家，那么我会在开始工作之前就做好当天的业余项目。假如当天的业余项目没有做完，那么不论多晚我都会完成，做到今日事今日毕。

要及时跟外界沟通。

当自己养成了新的习惯后跟外界沟通这是很有好处的。我的伙伴们都知道我每天写代码这个习惯，因此有活动安排时我会跟他们说：“等我写完代码再去。”他们一点都不会介意也很理解我的行为。

代码积少成多。

我很难相信自己在过去的几个月写了很多的代码。我新建了几个网站，重新写了框架并创建了大量节点模块。我已经写了这么多以至于有时我都忘记自己写了些什么，但是我真的很高兴我写了这么多的代码。

好的习惯能带来巨大的成功，武汉北大青鸟光谷校区专业老师指出，像每天写代码做业余项目这件事只要你坚持做下去，一定会有意想不到的效果。

第三篇：代码审查是由若干程序员和测试员组成一个审查小组

代码审查是由若干程序员和测试员组成一个审查小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步。第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为审查的依据。小组成员在充分阅读这些材料后，进入审查的第二步，召开程序审查会。

走查与代码审查基本相同，其过程分为两步。第一步把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。开会的程序与代码审查不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当计算机”，即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。

------------------

我们把代码审查叫做CR，即Code Review。它是项目进展到编码阶段非常重要的品质保证活动。但是很多时候，我们的CR工作都流于形式，在CR过程中不能发现本质问题，主要有以下四点原因：

一，CR时的目的性不强，缺乏针对性。CR的根本目的是保证品质，但不能把它做为一次CR活动的直接目标，这样的目标太泛泛，让我们在CR活动过程中抓不住重点。二，CR活动时参与的角色不合理。参与CR活动的人大多是技术合格，但业务不合格，这样对于一些复杂的业务逻辑问题就很难发现，从而使得这些业务逻辑问题在CR的保护伞下，堂而皇之的蒙混过关。

三，CR活动过于集中，一次CR的代码量太大。在有限的几个小时内，面对上千行，甚至更多的代码时，再有耐心的人也难免产生视觉疲劳。

四，准备不足，对于要CR的代码缺少必要的审查规范和标准。在代码审查过程中，我们往往只有代码编写规范，但是代码的设计规范、业务的逻辑规范和标准等准备不足。那么，我们应该怎样做，才能使CR工作保质而且高效呢？一个标准的CR活动应该分为三个阶段：

一，事前准备阶段。在一次CR前，以下对以下内容进行充分准备。

1．CR的对象。在准备CR代码对象时，我们要注意代码的数量，如果代码量比较大，要对代码进行必要的分解，确定其中的关键代码，对关键代码进行CR，可以达到举一反三的目的。

2．CR内容。我们对代码的审查内容很多，如代码的编写是否规范（注释的书写格式、命名规范等）、技术处理规范（异常处理、日志处理、代码组织结构等）、业务实现等。我们不能希望通过一次CR活动，完成所有这些内容的审查，因此我们必须设定本次CR活动内容界限，确定审查重点；

3．评审规范和标准。在CR前设计确定评审规范和标准是必要，通过规范和标准我们在审查过程中可以有据可依，有理可循，而且还可以做到标准统一。

4．选择CR活动的参与者。在CR开始前，必须把本次CR活动的对象、审查内容以及审查的规范和标准通报给所有的参与者。

5．选择CR活动的实施方式。CR活动有很多形式可供我们选择，我们可以根据实际情况选择桌面式CR、演示讲解式CR、一对一的座位CR等等。

二，实施阶段。充分的事前准备，只是做好CR活动的前提，在CR实施过程中，我们要做好以下工作。

1．准确记录。对于CR过程发现的问题，我们必须清晰准确的记录，可以使用问题点

记录单，明确记录的项目和内容。

2．CR过程中，要采用代码作者讲解和审查者提问方式。审查者不能只在发现问题时提问，同时也要根据本次审查的内容要求代码作者对某个特定问题的讲解。

3．对事前确定的审查内容，要逐项审查，不能因为时间不足等因素一扫而过。

4．实施审查时，要营造一个讨论问题、解决问题的氛围，不能把审查会搞成批判会，这样会影响相关人员的积极性。

三，事后跟踪跟踪。CR结束后，对发现的问题，首先需要确定以下内容。

1．问题点的难易程度以及影响的范围；

2．解决问题的责任者和问题点修正结果的确认者；

3．解决问题点的时限。

其次是对于修正问题责任者，在问题点的修正过程中，要三方面内容的记录。

1．问题点的原因；

2．解决问题点的对策；

3．修正的内容。

做为修正结果的确认者，必须按照事前约定的时限及时的对修正结果进行全面的确认。工作流管理系统是“一种在工作流形式化表示的驱动下，通过软件的执行而完成工作流定义、管理及执行的系统”，其主要目标是对业务过程中各活动发生的先后次序及同活动相关的相应人力或信息资源的调用，进行管理而实现业务过程的自动化。

在企业的日常工作中，绝大多数属于流程类工作，比如业务的分级审批工作、各类申请表单、公文签审、业务处理等。通过现代的技术手段将企业内诸多繁琐复杂的业务流程自动化，并对其进行有效地管理便是工作流需要解决的问题。

传统的系统设计方式将业务流程以编码的方式固化在应用系统中，在业务流程和组织结构发生改变的情况下，需要将系统进行重大修改，甚至重新设计。实际上，业务流程的改变是导致许多应用系统失败的最主要的原因。

工作流管理系统的出现使得上述情况发生了改变。应用系统的开发人员通过可视化的方式分析和设计业务流程，并将各个应用模块联接在一起。在组织结构和业务流程发生变化的时候，能够在很少修改甚至不修改原来应用的情况下，仅仅通过适当调整或重新定义工作流程就能适应变化了的情况。

采用工作流管理系统有以下优点：

提高系统的柔性，适应业务流程的变化，建设各类信息系统的重要工作之一就是发现用户的工作流程，进行分析建模，并把它体现到信息系统的设计中。

企业都在随着时间不断地改革工作流程，使企业各部门能够更好地发挥服务职能、提高工作效率。

-------------------------代码审查（code review）是软件开发过程的一个阶段，在这个阶段中，代码创造者和审查人员，可能还有质量保证（QA）测试人员，一起进行代码审查。能在该阶段中就找出并更正存在的错误，相对来说比较合理，因为如果在开发软件后面的阶段或者软件交付给用户后才来处理、查找和修改程序缺陷的话，会花费更多成本。

审查人员需要很仔细地检查代码，包括：

 缺陷或者潜在缺陷

 和整个程序设计的一致性

 评论的质量

 遵守编码标准代码审查通常能很好地检测出安全漏洞问题。有一些专门的应用程序可以帮助进行代码审查。自动代码审查系统可以有效地系统化地检测源代码的潜在问题，如缓冲区溢出、竞态条件、内存泄露、代码块大小问题和重复语句等。另外，代码审查也常用于检测补丁质量。安全代码审查的目的是要识别出会导致安全问题和事故的不安全编码技术和漏洞。虽然可能很耗时，但代码审查必须是项目开发周期中的常规事件，这是因为在开发时修复安全缺陷会比以后在产品部署或维护修复周期中再做这项工作节省大量的成本和工作量。

代码走读与审查

目的主要检查软件代码编写质量，是否与设计相符，与开发目的（需求）是否一致；是否符合编码规范；有没有存在明显的缺陷；

与测试的不同是测试通过一系列的测试活动(运行程序为主)来发现BUG，而代码审查走读则一方面通过浏览代码，检查语法结构，调用关系，以规范度，注释率，类化程度，耦合度，复用度等等指标来衡量代码的质量，达到防范问题发生；另一方面检查代码与设计的偏差，问题是否得到正确解决。

代码审查的阶段

一般的代码审查活动通常发生在软件完成时提交测试前，主要的目的是检查软件代码结构，评估软件质量，防止软件出现重大缺陷，把质量问题解决在测试之前。

近年来随着软件行业的发展，软件开发设计和控制能力不断提高，但软件依然存在BUG，不停地发放补丁，问题依然存在。对软件测试后的修改，也越来越谨慎，考虑得也越来越周全，因此，修改bug的代码改动也越来越重要，软件行业开始对代码修动进行了走读和审查，目的是防止问题的再次发生并且防止修改引发新的问题。

第四篇：公司规章制度之程序员代码管理制度

公司规章制度之程序员代码管理制度

第一章

总则

为规范公司程序源代码管理制度，保持良好的工作秩序和工作环境。根据《中华人民共和国劳动法》的有关规定，结合无锡博达信息技术有限公司的实际状况,特制定本规定。本规定适用于公司所有负责程序开发的员工。

第二章

程序源代码管理

1、程序员需在每周五和程序有较大更改/更新时，将程序源代码及说明书整理好交给程序保管员（QQ：***邮箱：***，优先发送至QQ；联系方式如有变更将另行通知）；

2、每个项目的源代码中应有完整详细的说明书，写清楚每一个程序包的名称及用途等；程序有变化时需同时更新相关文档，并注明相对上个版本的更改之处；

3、程序员有义务管理好各自所负责的工作项目的源代码以及相关账户权限，如非代码编写的需要和总经理同意，不得转交给他人；

4、程序员在公司任职期间，因职务需要及为公司项目开发的程序源代码，公司拥有所有权。

第五篇：技术总监谈好的程序员如何写代码

技术总监谈好的程序员如何写代码

2010-01-04 16:55 |

2846次阅读 | 来源：风轻扬官方博客 【已有17条评论】发表评论

感谢carlkxiafhwfhw的提供 | 收藏这篇新闻

要判断一个程序员是不是好的程序员，主要看他写的代码，因为程序员最重要的事是写代码。

即便不去理解代码的意图，只要看一眼，好的程序员写的代码与差的程序员写的代码基本上就可以看出来。好的程序员写的代码，整洁而规范，视觉上自然有一种美感。空白错落有致，注释恰到好处，命名和排版遵守统一的规范。差的程序员写的代码则经常出现过长的函数，前后不一致的命名方式和排版，过深的嵌套结构，非常复杂的表达式，随处可见的数字等毛病。

再去粗粗阅读，对好的程序员还是差的程序员就会更有把握。好的程序员写的代码，有一种精心雕琢而成的一致性。好的程序员一致会遵守统一的命名方式，如camelCase，而差的程序员的变量命名时不时的就会偏离统一规范。好的程序员的代码中拼写错误几乎不可见，而差的程序员的拼写错误要多得多。好的程序员对于同一类动作，不会忽而用这个动词，忽而又用那个同义词，如add/insert混用。好的程序员采用一致的简写规则，差的程序员则时而不简写，时而简写。好的程序员会很注意名称中形容词与名词谁在前谁在后，而差的程序员没有规则，时而在前时而在后。好的程序员很少会写出大段大段的重复代码，差的程序员却经常搞不定重复代码，他们难以将重复的代码抽取出一个统一的概念进行重用。好的程序员对于对外的API会注重注释与代码的一致性，差的程序员经常注释中的参数名称与函数定义都不一致。好的程序员很少会留下被注释掉的或用#if 0括起的垃圾代码，他们意志坚决，代码有用就要，没用就不要，差的程序员则不一样，他们经常不确信一段代码是否真的需要，他们缺乏保持代码整洁的习惯，因此他们让垃圾代码留着。

如上，即便你不懂他所用的语言，不却关心程序的逻辑，对好的程序员还是差的程序员就能做到八九不离十的判断。程序的好坏几乎总是取决于它们是否漂亮，不漂亮而好的程序，除了C++ STL源码，我再也没见过（如果你稍仔细看，STL的源码虽然不够漂亮，但仍然满足这里提出的一致性原则）。而又好又漂亮的代码则随处可见，如Linux Kernel，InnoDB，JDK，JUnit等等。

如果再仔细阅读，就能更准确。好的程序员写的代码，好似浑然天成，简单而直白。函数通常较短小，函数的名称准确的反映函数要完成的工作。逻辑简单而自然，让你读的时候由衷的发出啊，就应该是这样的感叹，而差的程序员的代码经常让你发出怎么是这样？这是再干什么呀？的疑问。好的程序员会在紧要关头加以画龙点睛般的注释，差的程序员要么没注释，要么注释只是代码的重复，纯粹是废话，更差的是注释是错的，是误导。

好的程序员未必是语言律师，即那种非常清楚的了解语言的各个细节，在编程时到处使用的家伙。好的程序员也不常炫技，在代码中精心构造一些独具匠心的片断，他们偶而会，但大多数时候总是用直白的语言来表述。

从代码也可以看出一个程序员的团队协作精神。注意团队合作的程序员，会严格按照团队规范写代码，而风格与团队规范不一致的程序员则很可能欠缺团队精神。注意团队合作的程序员会注意给模块的对外接口加以重要的说明，如前置条件、后置条件、参数能否是NULL等等，不注意团队合作的程序员懒于处理这些细节。

好的程序员与差的程序员的生产力差别巨大，项目的周期越长，项目越复杂，项目对质量的要求越高，好的程序员的价值就越大。好的程序员与差的程序员，管理成本也差别巨大，好的程序员只需要与他共同确定设计，代码可以不看，差的程序员的代码经常需要经过多次review，且仍有可能达不到理想的质量。

要成为好的程序员，首先要树立要成为好的程序员的志向，再勤加练习，天长日久，就会越来越好，这些人不怕老。没有志向永远成不了好的程序员，这些人若不在老去之前成为经理就会变成废人。

通过两个小时的笔试和半个小时的面试对于判断程序员来说是不够的。通过笔试与面试，你可以判断一个程序员是否具备算法与数据结构等基础知识，可以判断他对编程语言的特性是否掌握，可以判断他对技术是否关注，然而要知道他能否真的能很好的完成工作，不写代码是不够的。

那些显得对技术充满热情的，未必是好的程序员。这些人可能非常乐意从事有新意的工作，但后续的编码、测试、调试、文案工作则可能让他们感到厌烦。他们可能会提出好的创意，但却经常不能够有始有终的将其完成。公司不需要多少这样的人。

因此招聘的方式需要改善。招聘是最重要的，因为进来后就难以出去，即便是试用。转正条件白纸黑字写的很清楚，只要合格就可以转正，要达到合格并不是很困难。今年部门里进了很多新人，并不是人人都很优秀，但确实也都合格，自然也应该转正。

改善招聘的方法，就是让他写程序，可以出两道题，一道让他写程序，一道让他重构一个已有的较长的程序，一天之内完成。假使可以考他半个月，那么重构是不太需要的，但一天的时间太短，通过重构可以考察阅读并理解代码，并通过重构化腐朽为神奇的能力。那些不愿意写别人的代码，不愿意接受别人的代码，经常要重来一遍的人是不理想的。今年有两个人采用了类似的方法。有一位简历很优秀的人，做了两道编程题被拒了，有一位简历及面试一般的人，通过编程测试，录用了。我感觉比单纯的笔试与面试要准确。