本文翻译自"Continuous Learning"，来自于《97 Things Every Programmer Should Know》一书中的某个章节。

我们生活在一个引人入胜的时代。软件开发分布在全球各地，你知道那里有很多人可以胜任你的工作。你需要不断学习以保持你在市场上的竞争力。否则，你将变成一条恐龙，专心从事某一个工作，直到有一天，你不再被需要或者你的工作被外包给了其它更为廉价的开发人员。

那么，你对此该怎么办？一些雇主非常慷慨地提供培训，拓宽你的技能。其它雇主则根本无法抽出时间或提供任何培训经费。为了谨慎起见，你需要为自己的教育负责。

下面是一个让你保持持续学习的方法列表，其中许多可以在互联网上免费找到：

·阅读书籍、杂志、博客，订阅twitter种子，浏览互联网站点。如果你想深入了解某一主题，可考虑加入一个邮件列表或新闻组。 

·如果你真想深入研究某种技术，抓住它 – 编写一些代码。  

·尽量找到一名导师与你一同工作，因为成为最牛的人将阻碍你的教育。虽然从任何一个人身上你都可以学到一些东西，但是从那些比你更聪明更有经验的人那里，你可以学到更多。如果你找不到导师，那么请继续往下看。

·使用虚拟导师。在互联网上找到那些你真正喜欢的开发者和技术书籍的作者，阅读他们写的一切。订阅他们的博客。

·去了解你使用的框架和库。熟悉它们的工作原理可以让你知道如何更好的使用它们。如果它们是开源的，那你真是幸运。使用调试器单步调试这些代码，弄清楚在幕后发生的事情，你将看到由那些真正聪明的人编写和评审的代码。

·每当你犯了一个错误，修正了一个bug，或者遇到了一个问题时，设法真正理解所发生的事情。很可能其它人也遇到过相同的问题，并把它放在了互联网的某个角落里。这时Google就会变得十分有用了。

·学习东西的一个真正的好方法就是去教它或者讨论它。当人们打算去听你的演讲并向你咨询问题时，你就会动力十足的去学习。尝试在公司组织一次午餐学习会，或用户组，或一个本地会议。

·加入或启动一个学习小组或者一个你感兴趣的有关语言、技术或行为准则的本地用户组。

·参加会议。如果你无法参加，许多会议都会将现场演讲视频免费放到网上供下载。

·上下班路程过长？ 听播客吧。

·曾经在代码库上运行过静态分析工具或者看到过IDE给出的警告吗？弄清楚他们报告的是什么以及为什么报告。 

·遵照《程序员修炼之道》一书中的建议并且每年学习一门新语言。至少学习一门新技术或工具。扩展技术视野将给你带来新的想法，你可以将这些想法用到当前的技术栈上。 

·不是你学到的所有一切都与技术相关。学习你正在从事的行业的领域知识，这样你可以更好的理解需求并且帮助解决业务问题。学会如何更加高效-如何更好的工作-是另外一个很好的选项。

·回到学校 

拥有《黑客帝国》中尼奥所具有的能力将是多么好啊，只需简单地下载需要装入我们大脑的信息。但是我们没有这种能力，因此我们的学习需要一个时间保证。你无需醒着就去学习。每星期花一点时间就比什么不学要强。拥有（应该有）一个工作之外的生活。

技术日新月异，不要落在后面。

By Clint Shank

本文翻译自"Code Reviews"，来自于《97 Things Every Programmer Should Know》一书中的某个章节。

你应该做代码评审。为什么呢？因为代码评审可以提高代码质量并且降低缺陷比例。但进行代码评审未必是因为你想到的那些理由。

由于之前有过一些代码评审的糟糕体验，因此许多程序员不喜欢代码评审。我曾经见过一些组织，它们要求所有代码在部署到生产环境之前必须通过一个正式的评审。多数情况下由架构师或一名主程序员进行这些评审，这种做法被戏称为“架构师评审一切”。这个要求被写在了他们的软件开发过程手册中，因此程序员必须遵守。可能有一些组织的确需要这样一个严格且正式的过程，不过大多数组织并不需要。在大多数组织中，这样做法只会适得其反。被评审者会感到他们就像是在等待一个假释裁决委员会的判决。而评审者既需要时间阅读源码，还需要时间跟上系统的最新进展，了解系统的全部细节。评审者很快就成为了这个过程的瓶颈。而这个过程也会很快地成为众矢之的并变得愈加糟糕。

代码评审的目的应该是共享知识和建立共同的编码指南，而不是简单地纠正代码中的错误。与其它程序员们分享你的代码使集体代码拥有权成为可能。让任意一个项目成员与组内其它人一起浏览代码。评审代码时，你应该尝试学习并理解这些代码，而不是去找错误。

代码评审过程中保持气氛和谐。确保意见是建设性的，而不是刻薄挖苦。为评审会议引入不同的评审角色，避免成员之间的年资影响代码评审。就角色举例来说，可以有一个专门关注文档的评审者，另外一个评审者重点关注异常，第三个人负责关注功能性。这种方法有助于在项目成员间分担评审负担。

每周进行一次例行的代码评审。在评审会议室里花上几个小时进行评审。每次会议按照一个简单循环的方式轮换被评审者。记住项目组组员承担的评审角色在每次会议上也要轮换。代码评审时带上新手。他们也许经验不足，不过他们从大学带来的新鲜知识可以提供一种不同的看法。带上专家，他们有经验和知识。他们可以更快更准确地识别出容易出错的代码。如果项目组拥有代码规范的检查工具的话，代码评审过程将更加容易和顺畅。那样的话，在代码评审会议上大家永远不会讨论代码格式问题。

让代码评审变得有趣也许才是代码评审成功的最为重要的因素。评审是关于人的评审。如果评审会议是痛苦且枯燥无味的，那么它很难激发出大家参与的热情。让它成为一种非正式的、以在项目组成员间共享知识为主要目的的代码评审吧。抛弃那些刻薄挖苦，用蛋糕或黄包餐（译注：全体成员一起参加的午餐）取而代之。

By Mattias Karlsson