系统可以持续运行 5 年、10 年甚至 20 年或者更多年。但是，特定的代码行的生命，即使是经过设计，通常要短得多：当你通过各种方式来迭代寻求解决方案时，它会有几个月、几天甚至几分钟的生命。

一些代码比其他代码重要

通过研究代码如何随时间变化，Michael Feathers 确定了一个代码库的冥曲线。每个系统都有代码，通常有很多是一次性写成，永远都不会改变。但是有少量的代码，包括最重要和最有用的代码，会一次又一次地改变、会有几次重构或者从头重写。

当你在一个系统、或者问题领域、体系结构方法中有更多经验时，会更容易了解并预测什么代码将一直改变，哪些代码将永远不会改变：什么代码重要，什么代码不重要。

我们应该尝试编写完美的代码么？

我们知道我们应该写干净的代码，代码应该一致、清晰也要尽可能简单。

有些人把这变成了极端，他们迫使自己写出美丽、优雅、接近完美的代码，痴迷于重构并且纠结每个细节。

但是，如果代码只写一次而从不改变，或者如果在另一个极端下，它一直在改变的话，就如同尝试去写完美的需求和尝试做完美的前期设计那样，写完美的代码难道不是既浪费又没有必要（也不可能实现）的么？

“你不能写出完美的软件。是不是收到了伤害？并不。把它作为生活的公理接受它、拥抱它、庆祝它。因为完美的软件不存在。在计算机的短暂历史中从没有人写过完美的软件。你不可能成为第一个。除非你接受这个事实，否则你最终会浪费时间和精力追逐不可能的梦想。”

Andrew Hunt，务实的程序员: 从熟练工到大师

一次性写的代码不需要美观优雅。但它必须是正确的、可以理解的 —— 因为绝不会改变的代码在系统的整个生命周期内可能仍然被阅读很多次。它不需要干净并紧凑 —— 只要干净就够了。代码中复制和粘贴和其他小的裁剪是允许的，至少在某种程度上是这样的。这些是永远不需要打磨的代码。即使周围的其他代码正在更改，这些也是不需要重构的代码（除非你需要更改它）。这是不值得花费额外时间的代码。

你一直在改变的代码怎么样了呢？纠结于代码风格以及提出最优雅的解决方案是浪费时间，因为这段代码可能会再次更改，甚至可能会在几天或几周内重写。因此，每当你进行更改时，都会痴迷重构代码，或者没有重构没有改变的代码，因为它可能会更好。代码总是可以更好。但这并不重要。

重要的是：代码是否做了应该做的 —— 是正确的、可用的和高效的吗？它可以处理错误和不良数据而不会崩溃 —— 或者至少可以安全地失败？调试容易吗？改变是否容易且安全？这些不是美的主观方面。这些是成功与失败实际措施之间的差异。

务实编码和重构

精益开发 Lean Development 的核心思想是：不要浪费时间在不重要的事情上。这应该提醒我们该如何编写代码，以及我们如何重构它、审查它、测试它。

为了让工作完成，只重构你需要的 —— Martin Fowler 称之为 机会主义重构 opportunistic refactoring （理解、清理、童子军规则 ）和 准备重构 preparatory refactoring 。足够使改变更加容易和安全，而不是更多。如果你不改变那些代码，那么它并不会如看起来的那么重要。

在代码审查中，只聚焦在重要的事上。代码是否正确？有防御机制吗？是否安全？你能理解么？改变是否安全？

忘记代码风格（除非代码风格变成无法理解）。让你的 IDE 处理代码格式化。不要争议代码是否应该是“更多的 OO”。只要它有意义，它是否适当地遵循这种或那种模式并不重要。无论你喜欢还是不喜欢都没关系。你是否有更好的方式做到这一点并不重要 —— 除非你在教新接触这个平台或者语言的人，而且需要在做代码审查时做一部分指导。

写测试很重要。测试涵盖主要流程和重要的意外情况。测试让你用最少的工作获得最多的信息和最大的信心。大面积覆盖测试，或小型针对性测试 —— 都没关系，只要一直在做这个工作，在编写代码之前或之后编写测试并不重要。

（不只是）代码无关

建筑和工程方面的隐喻对软件从未有效过。我们不是设计和建造几年或几代将保持基本不变的桥梁或摩天大楼。我们构建的是更加弹性和抽象、更加短暂的东西。代码写来是被修改的 —— 这就是为什么它被称为“软件”。

“经过五年的使用和修改，成功的软件程序的源码通常完全认不出它原来的样子，而一个成功建筑五年后几乎没有变化。”

Kevin Tate，可持续软件开发

我们需要将代码看作是我们工作的一个暂时的手工制品：

有时候面对更重要的事情时，我们会迷信代码。我们经常有一个错觉，让卖出的产品有价值的是代码，然而实际上可能是对该问题领域的了解、设计难题的进展甚至是客户反馈。

Dan Grover，Code and Creative Destruction

迭代开发教会我们来体验和检验我们工作的结果 —— 我们是否解决了这个问题，如果没有，我们学到了什么，我们如何改进？软件构建从没有止境。即使设计和代码是正确的，它们也可能只是一段时间内正确，直到环境要求再次更改或替换为更好的东西。

我们需要编写好的代码：代码可以理解、正确、安全和可靠。我们需要重构和审查它，并写出好的有用的测试，同时知道这其中一些或者所有的代码，可能会很快被抛弃，或者它可能永远不会被再被查看，或者它可能根本不会用到。我们需要认识到，我们的一些工作必然会被浪费，并为此而进行优化。做需要做的，没有别的了。不要浪费时间尝试编写完美的代码。

作者简介：

Jim Bird

我是一名经验丰富的软件开发经理、项目经理和 CTO，专注于软件开发和维护、软件质量和安全性方面的困难问题。在过去 15 年中，我一直在管理建立全球证券交易所和投资银行电子交易平台的团队。我特别感兴趣的是，小团队在构建真正的软件中如何有效率：在可靠性，性能和适应性极限限制下的高质量，安全系统。

via: https://dzone.com/articles/dont-waste-time-writing

作者：Jim Bird 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

编程初学者可能都思考过这个问题，“我该怎么学编程？”这里我们提供些相关的参考指导来帮助你找到最适合自己学习情况和学习需要的方法。

最近有很多关于学习编程的争论。不仅仅是因为与软件开发公司公开的待应聘的职位数量相比较符合招聘要求的人远远无法满足缺口，编程也是工资最高和工作满足感最强的众多职业之一。也难怪越来越多的人都想进入这个行业。

但是你要怎么做才能正确地入行呢？“我应该怎么学习编程？”是初学者常见的一个问题。尽管我没有这些问题的全部答案，但是我希望这篇文章能够给你提供相关指导来帮助你找到最适合你的需求和自身情况发展的解决办法。

你的学习方式是什么？

在你开始学习编程之前，你需要考虑的不仅仅是你的方向选择，还要更多的考虑下你自己。古罗马人有句谚语， γνῶθι σεαυτόν （ gnothi seauton ） ，意思是“认识你自己”。投入到一个大型的编程学习过程中难度不小。足够的自我认识是非常有必要的，这能够确保你做出的选择通向成功的机会非常大。你需要思考并诚实地回答接下来的这些问题：

• 你最喜欢什么样的学习方式？怎么做你才能学到最好？是通过阅读的方式吗？还是听讲座？还是主要通过动手实践？你需要选择对你最有效的方法。不要仅仅因为这种学习方法流行或者有其他人说过这种方法对他们很有用就选择了这种方法。
• 你的需要和要求是什么？你为什么想学习如何编程？是因为你只是想换一份工作吗？如果是这样的话，你需要多次时间才能完成呢？你要牢记，这些是需要的 ，不是想要的 。你可能想要下周就换份新工作，但是需要在接下来的一年里供养你正在成长的家庭。当你在人生的道路上面临方向的抉择时，时间的安排特别重要。
• 你能获取的参考资料有哪些？当然，重返大学并获得一份计算机科学专业的学位证书可能也不错，但是你必须对你自己实事求是面对现实。你的生活必须和你学习相适应。你能承受花费几个月的时间和不菲的费用去参加集训吗？你是否生活在一个可以提供学习机会的地方，比如提供技术性的聚会或者大学课程？你能获取到的参考资料会对你的学习过程产生巨大的影响。在打算学编程换工作前先调查好这些。

选择一门编程语言

当你打算开始你的编程学习之路和考虑你的选择的时候，请记住不管其他人说什么，选择哪门编程语言来开始你的编程学习关系不大。是的，是有些编程语言比其他的更流行。比如，根据一份调查研究，目前 JavaScript，Java，PHP， 和 Python 处于 最受欢迎最流行的编程 中的前排。但是现在正流行的编程语言有可能过几年就过时了，所以不用太纠结编程语言的选择。像那些方法，类，函数，条件，控制流程和其他的编程的概念思想等等，不管你选的哪门编程语言，它们的底层原理基本是一致的。只有语法和社区的最佳实践会变。因此你能够用 Perl 学习编程，也可以用 Swift 或者 Rust。作为一个程序员，你会在你的职业生涯里用很多不同的编程语言来工作。不要认为你被困在了编程语言的选择上。

试水

除非你已经涉足过这个行业或者确信你愿意花费你生命的剩余时光来编程，我建议你最好还是下水之前先用脚趾头来试试水温之类的来判断这水适不适合。这种工作不是每个人都能做的。在把全部希望都压在学习编程之前，你可以先尝试花费少量时间金钱来学习一小部分知识点来了解自己是否会享受这种每周起码花费 40 个小时来编码工作的生活。如果你不喜欢这种工作，你不太可能完成编程项目的学习。即便你完成结束了编程的学习阶段，你也会在你以后的编程工作中感到无比痛苦。人生苦短就不要花费你人生三分之一的时间来做你不喜欢的事了。　

谢天谢地，软件开发不仅仅需要编程。熟悉编程概念和理解软件是怎么和他们结合在一起的是非常有用的，但是你不需要成为一个程序员也能在软件开发行业中找到一份报酬不菲的工作。在软件开发过程中，另外的重要角色有技术文档撰写人、项目经理、产品经理、测试人员、设计人员、用户体验设计者、运维/系统管理员和数据科学家等。软件成功的启动需要很多角色之间相互配合。不要觉得学习了编程就要求你成为一个程序员。你需要探索你的选择并确定哪个选择才是最适合你的。

参考的学习资料

你对学习参考资料的选择是什么？可能正如你已经发现的那样，可供选择的参考资料非常多，尽管在你的那片区域不是所有的资料都能够获得。

• 训练营：最近这几年像 App Academy 和 Bloc 这样的训练营越来越流行。训练营通常收费 $10K 或者更多，他们宣称在几周内就能够把一个学生培训成一个称职的程序员。在参加编程集训营前，你需要研究下你将要学习的项目能确保正如它所承诺的那样，在学生学完毕业后能够找到一个高薪的长期供职的职位。一方面花费了数目不小的钱财，而且时间也花费了不少——通常这些都是典型的全日制课程并且要求学生在接下来的连续几周里把其它的事先放在一边专心课程学习。然而时间金钱这两项不菲的消耗通常会使很多未来的程序员无法参加训练营。
• 社区学院/职业培训中心：社区学院常常被那些调研自己学习编程的方式的人所忽视，不得不说这些人该为自己对社区学院的忽视感到羞愧。你在社区学院或者职业培训中心能够接受到的教育是和你选择其他方式学习编程的学习效果一样有效，而且费用也不高。
• 国家/地方的培训项目：许多地区都认识到在他们的地区增加技术投资的经济效益，并且已经制定了培训计划来培养受过良好教育和准备好的劳动力。培训项目的案例包括了 Code Oregon 和 Minneapolis TechHire。检查下你的州、省或自治区是否提供这样的项目。
• 在线训练：许多公司和组织都提供在线技术培训项目。比如，Linux 基金会致力于通过开源技术使人们获得成功。其他的像 O'Reilly Media、Lynda.com 和 Coursera 在软件开发涉及的许多方面提供培训。Codecademy 提供对编程概念的在线介绍。每个项目的成本会有所不同，但大多数项目会允许你在你的日程安排中学习。
• MOOC：在过去的几年里，大规模开放在线课程的发展势头已经很好了。像 哈佛、斯坦福、MIT 和其他的一些世界一流大学他们一直在记录他们的课程，并免费提供在线课程。课程的自我指导性质可能并不适合所有人，但可利用的材料使这成为一个有价值的学习选择。
• 专业书籍：许多人喜欢用书自学。这是相当经济的，在初步学习阶段后提供了现成的参考资料。尽管你可以通过像 Safari 和 Amazon 这样的在线服务订购和访问图书，但是也不要忘了检查你本地的公共图书馆。

网络支持

无论你选择哪一种学习资源，有网络支持都将获得更大的成功。与他人分享你的经历和挑战可以帮助你保持动力，同时为你提供一个放心的地方去问那些你可能还没有足够自信到其他地方去问的问题。许多城镇都有当地的用户群聚在一起讨论和学习软件技术。通常你可以在 Meetup.com 这里找到。专门的兴趣小组，比如 Women Who Code 和 Code2040，在大多数城市地区经常举行会议和黑客马拉松活动，这是在你学习的时候结识并建立一个支持网络的很好的方式。一些软件会议举办“黑客日”，在那里你可以遇到有经验的软件开发人员，他们能够帮助你解决你所困扰的一些问题。例如，每年的 PyCon 会议都会提供几天的时间来让人们聚集在一起工作、研讨。一些项目，比如 BeeWare，使用这些短暂的时间来帮助新程序员学习和对这些项目做贡献。

你的网络支持不需要来自正式的聚会。一个小的学习小组可以有效地保持你的学习积极性，并且可以像在你最喜欢的社交网络上发布邀请一样容易形成。如果你生活在一个没有大量软件开发人员社区所支持的聚会和用户组的地区，那么这一点特别有用。

开始学习编程的几个步骤

简单的来说，既然你决定学习编程，可以参考这几个方法给自己一个尽可能成功的机会：

1. 将你的需要/需求和参考学习资料列出清单并进行收集
2. 搜寻在你的当地那里能够可用的选择
3. 放弃不能符合你的需求和参考学习资料的选择
4. 选择最符合你需求的和最适合你的学习参考资源
5. 找到一个能够得到支持的网络

务必牢记：你的学习过程永远不会结束。高速发展的软件产业，会导致新技术和新进展几乎每天都会出现。一旦你学会了编程，你就必须花时间去学习适应这些新的进步。你不能依靠你的工作来为你提供这种培训。只有你自己负责自己的职业发展，所以如果你想保持最新的技术和工作能力，你必须紧跟行业最新的技术。

祝你好运！

作者简介：

VM (Vicky) Brasseur - VM (aka Vicky) 是一个技术人员，也是项目、工作进程、产品和企业的经理。在她的长达 18 年的科技行业里，她曾是一名分析师、程序员、产品经理、软件工程经理和软件工程总监。目前，她是惠普企业上游开源开发团队的高级工程经理。她的博客是 anonymoushash.vmbrasseur.com，推特是 @vmbrasseur。　

via: https://opensource.com/article/17/4/how-get-started-learning-program

作者：VM (Vicky) Brasseur 译者：WangYueScream 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

多年前，我曾是一名 Smalltalk 程序员，这种经验让我以一种不同的视角来观察编程的世界，例如，需要花时间来适应源代码应该存储在文本文件中的这种做法。

我们作为程序员通常会区分“开发”和“部署”，特别是我们在开发的地方所使用的工具不同于我们在之后部署软件时的地点和工具时。而在 Smalltalk 世界里，没有这样的区别。

Smalltalk 构建于虚拟机包含了你的开发环境（IDE、调试器、文本编辑器、版本控制等）的思路之上，如果你需要修改任何一处代码，你得修改内存中运行副本。如果需要的话，你可以为运行中的机器做个快照；如果你想分发你的代码，你可以发送一个运行中的机器的镜像副本（包括 IDE、调试器、文本编辑器、版本控制等）给用户。这就是上世纪 90 年代软件开发的方式（对我们中的一些人来说）。

如今，部署环境与开发环境有了很大的不同。起初，你不要期望那里（指部署环境）有任何开发工具。一旦部署，就没有版本控制、没有调试、没有开发环境。有的是记录和监视，这些在我们的开发环境中都没有，而有一个“构建管道”，它将我们的软件从开发形式转换为部署形式。作为一个例证，Docker 容器则试图重新找回上世纪 90 年代 Smalltalk 程序员部署体验的那种简单性，而避免同样的开发体验。

我想如果 Smalltalk 世界是我唯一的编程方面的体验，让我无法区分开发和部署环境，我可能会偶尔回顾一下它。但是在我成为一名 Smalltalk 程序员之前，我还是一位 APL 程序员，这也是一个可修改的虚拟机镜像的世界，其中开发和部署是无法区分的。因此，我相信，在当前的时代，人们编辑单独的源代码文件，然后运行构建管道以创建在编辑代码时尚不存在的部署作品，然后将这些作品部署给用户。我们已经以某种方式将这种反模式的软件开发制度化，而不断发展的软件环境的需求正在迫使我们找回到上世纪 90 年代的更有效的技术方法。因此才会有 Docker 的成功，所以，我需要提出我的建议。

我有两个建议：我们在运行时系统中实现（并使用）版本控制，以及，我们通过更改运行中的系统来开发软件，而不是用新的运行系统替换它们。这两个想法是相关的。为了安全地更改正在运行的系统，我们需要一些版本控制功能来支持“撤消”功能。也许公平地说，我只提出了一个建议。让我举例来说明。

让我们开始假设一个静态网站。你要修改一些 HTML 文件。你应该如何工作？如果你像大多数开发者一样，你会有两个，也许三个网站 - 一个用于开发，一个用于 QA（或者预发布），一个用于生产。你将直接编辑开发实例中的文件。准备就绪后，你将把你的修改“部署”到预发布实例。在用户验收测试之后，你将再次部署，这次是生产环境。

使用 Occam 的 Razor，让我们可以避免不必要地创建实例。我们需要多少台机器？我们可以使用一台电脑。我们需要多少台 web 服务器？我们可以使用具有多个虚拟主机的单台 web 服务器。如果不使用多个虚拟主机的话，我们可以只使用单个虚拟主机吗？那么我们就需要多个目录，并需要使用 URL 的顶级路径来区分不同的版本，而不是虚拟主机名。但是为什么我们需要多个目录？因为 web 服务器将从文件系统中提供静态文件。我们的问题是，目录有三个不同的版本，我们的解决方案是创建目录的三个不同的副本。这不是正是 Subversion 和 Git 这样的版本控制系统解决的问题吗？制作目录的多个副本以存储多个版本的策略回到了版本控制 CVS 之前的日子。为什么不使用比如说一个空的的 Git 仓库来存储文件呢？要这样做，web 服务器将需要能够从 git 仓库读取文件（参见 mod\_git）。

这将是一个支持版本控制的运行时系统。

使用这样的 web 服务器，使用的版本可以由 cookie 来标识。这样，任何人都可以推送到仓库，用户将继续看到他们发起会话时所分配的版本。版本控制系统有不可改变的提交； 一旦会话开始，开发人员可以在不影响正在运行的用户的情况下快速推送更改。开发人员可以重置其会话以跟踪他们的新提交，因此开发人员或测试人员就可能如普通用户一样查看在同台服务器上同一个 URL 上正在开发或正在测试的版本。作为偶然的副作用，A/B 测试仅仅是将不同的用户分配给不同的提交的情况。所有用于管理多个版本的 git 设施都可以在运行环境中发挥作用。当然，git reset 为我们提供了前面提到的“撤销”功能。

为什么不是每个人都这样做？

一种可能性是，诸如版本控制系统的工具没有被设计为在生产环境中使用。例如，给某人推送到测试分支而不是生产分支的许可是不可能的。对这个方案最常见的反对是，如果发现了一个漏洞，你会想要将某些提交标记为不可访问。这将是另一种更细粒度的权限的情况；开发人员将具有对所有提交的读取权限，但外部用户不会。我们可能需要对现有工具进行一些额外的改造以支持这种模式，但是这些功能很容易理解，并已被设计到其他软件中。例如，Linux （或 PostgreSQL）实现了对不同用户的细粒度权限的想法。

随着云环境变得越来越普及，这些想法变得更加相关：云总是在运行。例如，我们可以看到，AWS 中等价的 “文件系统”（S3）实现了版本控制，所以你可能有一个不同的想法，使用一台 web 服务器提供来自 S3 的资源文件，并根据会话信息选择不同版本的资源文件。重要的并不是哪个实现是最好的，而是支持这种运行时版本控制的愿景。

部署的软件环境应该是“版本感知”的原则，应该扩展到除了服务静态文件的 web 服务器之外的其他工具。在将来的文章中，我将介绍版本库，数据库和应用程序服务器的方法。

作者简介：

Robert M. Lefkowitz - Robert（即 r0ml）是一个喜欢复杂编程语言的编程语言爱好者。 他是一个提高清晰度、提高可靠性和最大限度地简化的编程技术收藏家。他通过让计算机更加容易获得来使它普及化。他经常演讲中世纪晚期和早期文艺复兴对编程艺术的影响。

via: https://opensource.com/article/17/1/difference-between-development-deployment

作者：Robert M. Lefkowitz 译者：geekpi 校对：Bestony

本文由 LCTT 原创编译，Linux中国 荣誉推出

在最近关于 Linus Torvalds 的一个采访中，这位 Linux 的创始人，在采访过程中大约 14:20 的时候，提及了关于代码的 “good taste”。good taste？采访者请他展示更多的细节，于是，Linus Torvalds 展示了一张提前准备好的插图。

他展示的是一个代码片段。但这段代码并没有 “good taste”。这是一个具有 “poor taste” 的代码片段，把它作为例子，以提供一些初步的比较。

这是一个用 C 写的函数，作用是删除链表中的一个对象，它包含有 10 行代码。

他把注意力集中在底部的 if 语句。正是这个 if 语句受到他的批判。

我暂停了这段视频，开始研究幻灯片。我发现我最近有写过和这很像的代码。Linus 不就是在说我的代码品味很差吗？我放下自傲，继续观看视频。

随后， Linus 向观众解释，正如我们所知道的，当从链表中删除一个对象时，需要考虑两种可能的情况。当所需删除的对象位于链表的表头时，删除过程和位于链表中间的情况不同。这就是这个 if 语句具有 “poor taste” 的原因。

但既然他承认考虑这两种不同的情况是必要的，那为什么像上面那样写如此糟糕呢？

接下来，他又向观众展示了第二张幻灯片。这个幻灯片展示的是实现同样功能的一个函数，但这段代码具有 “goog taste”　。

原先的 10 行代码现在减少为 4 行。

但代码的行数并不重要，关键是 if 语句，它不见了，因为不再需要了。代码已经被重构，所以，不用管对象在列表中的位置，都可以运用同样的操作把它删除。

Linus 解释了一下新的代码，它消除了边缘情况，就是这样。然后采访转入了下一个话题。

我琢磨了一会这段代码。 Linus 是对的，的确，第二个函数更好。如果这是一个确定代码具有 “good taste” 还是 “bad taste” 的测试，那么很遗憾，我失败了。我从未想到过有可能能够去除条件语句。我写过不止一次这样的 if 语句，因为我经常使用链表。

这个例子的意义，不仅仅是教给了我们一个从链表中删除对象的更好方法，而是启发了我们去思考自己写的代码。你通过程序实现的一个简单算法，可能还有改进的空间，只是你从来没有考虑过。

以这种方式，我回去审查最近正在做的项目的代码。也许是一个巧合，刚好也是用 C 写的。

我尽最大的能力去审查代码，“good taste” 的一个基本要求是关于边缘情况的消除方法，通常我们会使用条件语句来消除边缘情况。你的测试使用的条件语句越少，你的代码就会有更好的 “taste” 。

下面，我将分享一个通过审查代码进行了改进的一个特殊例子。

这是一个关于初始化网格边缘的算法。

下面所写的是一个用来初始化网格边缘的算法，网格 grid 以一个二维数组表示：grid行 。

再次说明，这段代码的目的只是用来初始化位于 grid 边缘的点的值，所以，只需要给最上方一行、最下方一行、最左边一列以及最右边一列赋值即可。

为了完成这件事，我通过循环遍历 grid 中的每一个点，然后使用条件语句来测试该点是否位于边缘。代码看起来就是下面这样：

for (r = 0; r < GRID_SIZE; ++r) {
    for (c = 0; c < GRID_SIZE; ++c) {
        // Top Edge
        if (r == 0)
            grid[r][c] = 0;
        // Left Edge
        if (c == 0)
            grid[r][c] = 0;
        // Right Edge
        if (c == GRID_SIZE - 1)
            grid[r][c] = 0;
        // Bottom Edge
        if (r == GRID_SIZE - 1)
            grid[r][c] = 0;
    }
}

虽然这样做是对的，但回过头来看，这个结构存在一些问题。

1. 复杂性 — 在双层循环里面使用 4 个条件语句似乎过于复杂。
2. 高效性 — 假设 GRID_SIZE 的值为 64，那么这个循环需要执行 4096 次，但需要进行赋值的只有位于边缘的 256 个点。

用 Linus 的眼光来看，将会认为这段代码没有 “good taste” 。

所以，我对上面的问题进行了一下思考。经过一番思考，我把复杂度减少为包含四个条件语句的单层 for 循环。虽然只是稍微改进了一下复杂性，但在性能上也有了极大的提高，因为它只是沿着边缘的点进行了 256 次循环。

for (i = 0; i < GRID_SIZE * 4; ++i) {
    // Top Edge
    if (i < GRID_SIZE)
        grid[0][i] = 0;
    // Right Edge
    else if (i < GRID_SIZE * 2)
        grid[i - GRID_SIZE][GRID_SIZE - 1] = 0;
    // Left Edge
    else if (i < GRID_SIZE * 3)
        grid[i - (GRID_SIZE * 2)][0] = 0;
    // Bottom Edge
    else
        grid[GRID_SIZE - 1][i - (GRID_SIZE * 3)] = 0;
}

的确是一个很大的提高。但是它看起来很丑，并不是易于阅读理解的代码。基于这一点，我并不满意。

我继续思考，是否可以进一步改进呢？事实上，答案是 YES！最后，我想出了一个非常简单且优雅的算法，老实说，我不敢相信我会花了那么长时间才发现这个算法。

下面是这段代码的最后版本。它只有一层 for 循环并且没有条件语句。另外。循环只执行了 64 次迭代，极大的改善了复杂性和高效性。

for (i = 0; i < GRID_SIZE; ++i) {
    // Top Edge
    grid[0][i] = 0;

    // Bottom Edge
    grid[GRID_SIZE - 1][i] = 0;
    // Left Edge
    grid[i][0] = 0;
    // Right Edge
    grid[i][GRID_SIZE - 1] = 0;
}

这段代码通过每次循环迭代来初始化四条边缘上的点。它并不复杂，而且非常高效，易于阅读。和原始的版本，甚至是第二个版本相比，都有天壤之别。

至此，我已经非常满意了。

那么，我是一个有 “good taste” 的开发者么？

我觉得我是，但是这并不是因为我上面提供的这个例子，也不是因为我在这篇文章中没有提到的其它代码……而是因为具有 “good taste” 的编码工作远非一段代码所能代表。Linus 自己也说他所提供的这段代码不足以表达他的观点。

我明白 Linus 的意思，也明白那些具有 “good taste” 的程序员虽各有不同，但是他们都是会将他们之前开发的代码花费时间重构的人。他们明确界定了所开发的组件的边界，以及是如何与其它组件之间的交互。他们试着确保每一样工作都完美、优雅。

其结果就是类似于 Linus 的 “good taste” 的例子，或者像我的例子一样，不过是千千万万个 “good taste”。

你会让你的下个项目也具有这种 “good taste” 吗？

via: https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a

作者：Brian Barto 译者：ucasFL 校对：wxy

本文由 LCTT 组织编译，Linux中国 荣誉推出

最近几年中，面向数据的设计已经受到了很多的关注 —— 一种强调内存中数据布局的编程风格，包括如何访问以及将会引发多少的 cache 缺失。由于在内存读取操作中缺失所占的数量级要大于命中的数量级，所以缺失的数量通常是优化的关键标准。这不仅仅关乎那些对性能有要求的 code-data 结构设计的软件，由于缺乏对内存效益的重视而成为软件运行缓慢、膨胀的一个很大因素。

高效缓存数据结构的中心原则是将事情变得平滑和线性。比如，在大部分情况下，存储一个序列元素更倾向于使用普通数组而不是链表 —— 每一次通过指针来查找数据都会为 cache 缺失增加一份风险；而普通数组则可以预先获取，并使得内存系统以最大的效率运行

如果你知道一点内存层级如何运作的知识，下面的内容会是想当然的结果——但是有时候即便它们相当明显，测试一下任不失为一个好主意。几年前 Baptiste Wicht 测试过了 std::vector vs std::list vs std::deque，（后者通常使用分块数组来实现，比如：一个数组的数组）。结果大部分会和你预期的保持一致，但是会存在一些违反直觉的东西。作为实例：在序列链表的中间位置做插入或者移除操作被认为会比数组快，但如果该元素是一个 POD 类型，并且不大于 64 字节或者在 64 字节左右（在一个 cache 流水线内），通过对要操作的元素周围的数组元素进行移位操作要比从头遍历链表来的快。这是由于在遍历链表以及通过指针插入/删除元素的时候可能会导致不少的 cache 缺失，相对而言，数组移位则很少会发生。（对于更大的元素，非 POD 类型，或者你已经有了指向链表元素的指针，此时和预期的一样，链表胜出）

多亏了类似 Baptiste 这样的数据，我们知道了内存布局如何影响序列容器。但是关联容器，比如 hash 表会怎么样呢？已经有了些权威推荐：Chandler Carruth 推荐的带局部探测的开放寻址（此时，我们没必要追踪指针），以及Mike Acton 推荐的在内存中将 value 和 key 隔离（这种情况下，我们可以在每一个 cache 流水线中得到更多的 key）， 这可以在我们必须查找多个 key 时提高局部性能。这些想法很有意义，但再一次的说明：测试永远是好习惯，但由于我找不到任何数据，所以只好自己收集了。

测试

我测试了四个不同的 quick-and-dirty 哈希表实现，另外还包括 std::unordered_map 。这五个哈希表都使用了同一个哈希函数 —— Bob Jenkins 的 SpookyHash（64 位哈希值）。（由于哈希函数在这里不是重点，所以我没有测试不同的哈希函数；我同样也没有检测我的分析中的总内存消耗。）实现会通过简短的代码在测试结果表中标注出来。

• UM： std::unordered_map 。在 VS2012 和 libstdc++-v3 （libstdc++-v3: gcc 和 clang 都会用到这东西）中，UM 是以链表的形式实现，所有的元素都在链表中，bucket 数组中存储了链表的迭代器。VS2012 中，则是一个双链表，每一个 bucket 存储了起始迭代器和结束迭代器；libstdc++ 中，是一个单链表，每一个 bucket 只存储了一个起始迭代器。这两种情况里，链表节点是独立申请和释放的。最大负载因子是 1 。
• Ch：分离的、链状 bucket 指向一个元素节点的单链表。为了避免分开申请每一个节点，元素节点存储在普通数组池中。未使用的节点保存在一个空闲链表中。最大负载因子是 1。
• OL：开地址线性探测 —— 每一个 bucket 存储一个 62 bit 的 hash 值，一个 2 bit 的状态值（包括 empty，filled，removed 三个状态），key 和 value 。最大负载因子是 2/3。
• DO1：“data-oriented 1” —— 和 OL 相似，但是哈希值、状态值和 key、values 分离在两个隔离的平滑数组中。
• DO2：“data-oriented 2” —— 与 OL 类似，但是哈希/状态，keys 和 values 被分离在 3 个相隔离的平滑数组中。

在我的所有实现中，包括 VS2012 的 UM 实现，默认使用尺寸为 2 的 n 次方。如果超出了最大负载因子，则扩展两倍。在 libstdc++ 中，UM 默认尺寸是一个素数。如果超出了最大负载因子，则扩展为下一个素数大小。但是我不认为这些细节对性能很重要。素数是一种对低 bit 位上没有足够熵的低劣 hash 函数的挽救手段，但是我们正在用的是一个很好的 hash 函数。

OL，DO1 和 DO2 的实现将共同的被称为 OA（open addressing）——稍后我们将发现它们在性能特性上非常相似。在每一个实现中，单元数从 100 K 到 1 M，有效负载（比如：总的 key + value 大小）从 8 到 4 k 字节我为几个不同的操作记了时间。 keys 和 values 永远是 POD 类型，keys 永远是 8 个字节（除了 8 字节的有效负载，此时 key 和 value 都是 4 字节）因为我的目的是为了测试内存影响而不是哈希函数性能，所以我将 key 放在连续的尺寸空间中。每一个测试都会重复 5 遍，然后记录最小的耗时。

测试的操作在这里：

• Fill：将一个随机的 key 序列插入到表中（key 在序列中是唯一的）。
• Presized fill：和 Fill 相似，但是在插入之间我们先为所有的 key 保留足够的内存空间，以防止在 fill 过程中 rehash 或者重申请。
• Lookup：执行 100 k 次随机 key 查找，所有的 key 都在 table 中。
• Failed lookup: 执行 100 k 次随机 key 查找，所有的 key 都不在 table 中。
• Remove：从 table 中移除随机选择的半数元素。
• Destruct：销毁 table 并释放内存。

你可以在这里下载我的测试代码。这些代码只能在 64 机器上编译（包括Windows和Linux）。在 main() 函数顶部附近有一些开关，你可把它们打开或者关掉——如果全开，可能会需要一两个小时才能结束运行。我收集的结果也放在了那个打包文件里的 Excel 表中。（注意： Windows 和 Linux 在不同的 CPU 上跑的，所以时间不具备可比较性）代码也跑了一些单元测试，用来验证所有的 hash 表实现都能运行正确。

我还顺带尝试了附加的两个实现：Ch 中第一个节点存放在 bucket 中而不是 pool 里，二次探测的开放寻址。 这两个都不足以好到可以放在最终的数据里，但是它们的代码仍放在了打包文件里面。

结果

这里有成吨的数据!! 这一节我将详细的讨论一下结果，但是如果你对此不感兴趣，可以直接跳到下一节的总结。

Windows

这是所有的测试的图表结果，使用 Visual Studio 2012 编译，运行于 Windows 8.1 和 Core i7-4710HQ 机器上。

从左至右是不同的有效负载大小，从上往下是不同的操作（注意：不是所有的Y轴都是相同的比例！）我将为每一个操作总结一下主要趋向。

Fill：

在我的 hash 表中，Ch 稍比任何的 OA 变种要好。随着哈希表大小和有效负载的加大，差距也随之变大。我猜测这是由于 Ch 只需要从一个空闲链表中拉取一个元素，然后把它放在 bucket 前面，而 OA 不得不搜索一部分 bucket 来找到一个空位置。所有的 OA 变种的性能表现基本都很相似，当然 DO1 稍微有点优势。

在小负载的情况，UM 几乎是所有 hash 表中表现最差的 —— 因为 UM 为每一次的插入申请（内存）付出了沉重的代价。但是在 128 字节的时候，这些 hash 表基本相当，大负载的时候 UM 还赢了点。因为，我所有的实现都需要重新调整元素池的大小，并需要移动大量的元素到新池里面，这一点我几乎无能为力；而 UM 一旦为元素申请了内存后便不需要移动了。注意大负载中图表上夸张的跳步！这更确认了重新调整大小带来的问题。相反，UM 只是线性上升 —— 只需要重新调整 bucket 数组大小。由于没有太多隆起的地方，所以相对有效率。

Presized fill：

大致和 Fill 相似，但是图示结果更加的线性光滑，没有太大的跳步（因为不需要 rehash ），所有的实现差距在这一测试中要缩小了些。大负载时 UM 依然稍快于 Ch，问题还是在于重新调整大小上。Ch 仍是稳步少快于 OA 变种，但是 DO1 比其它的 OA 稍有优势。

Lookup：

所有的实现都相当的集中。除了最小负载时，DO1 和 OL 稍快，其余情况下 UM 和 DO2 都跑在了前面。（LCTT 译注： 你确定？）真的，我无法描述 UM 在这一步做的多么好。尽管需要遍历链表，但是 UM 还是坚守了面向数据的本性。

顺带一提，查找时间和 hash 表的大小有着很弱的关联，这真的很有意思。 哈希表查找时间期望上是一个常量时间，所以在的渐进视图中，性能不应该依赖于表的大小。但是那是在忽视了 cache 影响的情况下！作为具体的例子，当我们在具有 10 k 条目的表中做 100 k 次查找时，速度会便变快，因为在第一次 10 k - 20 k 次查找后，大部分的表会处在 L3 中。

Failed lookup：

相对于成功查找，这里就有点更分散一些。DO1 和 DO2 跑在了前面，但 UM 并没有落下，OL 则是捉襟见肘啊。我猜测，这可能是因为 OL 整体上具有更长的搜索路径，尤其是在失败查询时；内存中，hash 值在 key 和 value 之飘来荡去的找不着出路，我也很受伤啊。DO1 和 DO2 具有相同的搜索长度，但是它们将所有的 hash 值打包在内存中，这使得问题有所缓解。

Remove：

DO2 很显然是赢家，但 DO1 也未落下。Ch 则落后，UM 则是差的不是一丁半点（主要是因为每次移除都要释放内存）；差距随着负载的增加而拉大。移除操作是唯一不需要接触数据的操作，只需要 hash 值和 key 的帮助，这也是为什么 DO1 和 DO2 在移除操作中的表现大相径庭，而其它测试中却保持一致。（如果你的值不是 POD 类型的，并需要析构，这种差异应该是会消失的。）

Destruct：

Ch 除了最小负载，其它的情况都是最快的（最小负载时，约等于 OA 变种）。所有的 OA 变种基本都是相等的。注意，在我的 hash 表中所做的所有析构操作都是释放少量的内存 buffer 。但是 在Windows中，释放内存的消耗和大小成比例关系。（而且，这是一个很显著的开支 —— 申请 ～1 GB 的内存需要 ～100 ms 的时间去释放！）

UM 在析构时是最慢的一个（小负载时，慢的程度可以用数量级来衡量），大负载时依旧是稍慢些。对于 UM 来讲，释放每一个元素而不是释放一组数组真的是一个硬伤。

Linux

我还在装有 Linux Mint 17.1 的 Core i5-4570S 机器上使用 gcc 4.8 和 clang 3.5 来运行了测试。gcc 和 clang 的结果很相像，因此我只展示了 gcc 的；完整的结果集合包含在了代码下载打包文件中，链接在上面。

大部分结果和 Windows 很相似，因此我只高亮了一些有趣的不同点。

Lookup：

这里 DO1 跑在前头，而在 Windows 中 DO2 更快些。（LCTT 译注： 这里原文写错了吧？）同样，UM 和 Ch 落后于其它所有的实现——过多的指针追踪，然而 OA 只需要在内存中线性的移动即可。至于 Windows 和 Linux 结果为何不同，则不是很清楚。UM 同样比 Ch 慢了不少，特别是大负载时，这很奇怪；我期望的是它们可以基本相同。

Failed lookup：

UM 再一次落后于其它实现，甚至比 OL 还要慢。我再一次无法理解为何 UM 比 Ch 慢这么多，Linux 和 Windows 的结果为何有着如此大的差距。

Destruct：

在我的实现中，小负载的时候，析构的消耗太少了，以至于无法测量；在大负载中，线性增加的比例和创建的虚拟内存页数量相关，而不是申请到的数量？同样，要比 Windows 中的析构快上几个数量级。但是并不是所有的都和 hash 表有关；我们在这里可以看出不同系统和运行时内存系统的表现。貌似，Linux 释放大内存块是要比 Windows 快上不少（或者 Linux 很好的隐藏了开支，或许将释放工作推迟到了进程退出，又或者将工作推给了其它线程或者进程）。

UM 由于要释放每一个元素，所以在所有的负载中都比其它慢上几个数量级。事实上，我将图片做了剪裁，因为 UM 太慢了，以至于破坏了 Y 轴的比例。

总结

好，当我们凝视各种情况下的数据和矛盾的结果时，我们可以得出什么结果呢？我想直接了当的告诉你这些 hash 表变种中有一个打败了其它所有的 hash 表，但是这显然不那么简单。不过我们仍然可以学到一些东西。

首先，在大多数情况下我们“很容易”做的比 std::unordered_map 还要好。我为这些测试所写的所有实现（它们并不复杂；我只花了一两个小时就写完了）要么是符合 unordered_map 要么是在其基础上做的提高，除了大负载（超过128字节）中的插入性能， unordered_map 为每一个节点独立申请存储占了优势。（尽管我没有测试，我同样期望 unordered_map 能在非 POD 类型的负载上取得胜利。）具有指导意义的是，如果你非常关心性能，不要假设你的标准库中的数据结构是高度优化的。它们可能只是在 C++ 标准的一致性上做了优化，但不是性能。:P

其次，如果不管在小负载还是超负载中，若都只用 DO1 （开放寻址，线性探测，hashes/states 和 key/vaules分别处在隔离的普通数组中），那可能不会有啥好表现。这不是最快的插入，但也不坏（还比 unordered_map 快），并且在查找，移除，析构中也很快。你所知道的 —— “面向数据设计”完成了！

注意，我的为这些哈希表做的测试代码远未能用于生产环境——它们只支持 POD 类型，没有拷贝构造函数以及类似的东西，也未检测重复的 key，等等。我将可能尽快的构建一些实际的 hash 表，用于我的实用库中。为了覆盖基础部分，我想我将有两个变种：一个基于 DO1，用于小的，移动时不需要太大开支的负载；另一个用于链接并且避免重新申请和移动元素（就像 unordered_map ),用于大负载或者移动起来需要大开支的负载情况。这应该会给我带来最好的两个世界。

与此同时，我希望你们会有所启迪。最后记住，如果 Chandler Carruth 和 Mike Acton 在数据结构上给你提出些建议，你一定要听。

作者简介：

我是一名图形程序员，目前在西雅图做自由职业者。之前我在 NVIDIA 的 DevTech 软件团队中工作，并在美少女特工队工作室中为 PS3 和 PS4 的 Infamous 系列游戏开发渲染技术。

自 2002 年起，我对图形非常感兴趣，并且已经完成了一系列的工作，包括：雾、大气雾霾、体积照明、水、视觉效果、粒子系统、皮肤和头发阴影、后处理、镜面模型、线性空间渲染、和 GPU 性能测量和优化。

你可以在我的博客了解更多和我有关的事，除了图形，我还对理论物理和程序设计感兴趣。

你可以在 [email protected] 或者在 Twitter（@Reedbeta)/Google+ 上关注我。我也会经常在 StackExchange 上回答计算机图形的问题。

via: http://reedbeta.com/blog/data-oriented-hash-table/

作者：Nathan Reed 译者：sanfusu 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

这些练习目前已经支持 33 种编程语言了。

我们中的很多人的 2017 年目标，将提高编程能力或学习如何编程放在第一位。虽然我们有许多资源可以访问，但练习独立于特定职业的代码开发的艺术还是需要一些规划。Exercism.io 就是为此目的而设计的一种资源。

Exercism 是一个 开源 的项目和服务，通过发现和协作，帮助人们提高他们的编程技能。Exercism 提供了几十种不同编程语言的练习。实践者完成每个练习，并获得反馈，从而可以从他们的同行小组的经验中学习。

这里有这么多同行！ Exercism 在 2016 年留下了一些令人印象深刻的统计：

• 有来自 201 个不同国家的参与者
• 自 2013 年 6 月以来，29,000 名参与者提交了练习，其中仅在 2016 年就有 15,500 名参加者提交练习
• 自 2013 年 6 月以来，15,000 名参与者就练习解决方案提供反馈，其中 2016 年有 5,500 人提供反馈
• 每月 50,000 名访客，每周超过 12,000 名访客
• 目前的练习已经支持 33 种编程语言，另外 22 种语言在筹备工作中

该项目为各种级别的参与者提供了一系列小小的挑战，使他们能够“即使在低水平也能发展到高度谙熟”，Exercism 的创始人 Katrina Owen 这样说到。Exercism 并不旨在教导学员成为一名职业程序员，但它的练习使他们对一种语言及其瑕疵有深刻的了解。这种熟悉性消除了学习者对语言的认知负担（使之更谙熟），使他们能够专注于更困难的架构和最佳实践的问题。

Exercism 通过一系列练习（或者还有别的？）来做到这一点。程序员下载命令行客户端，检索第一个练习，添加完成练习的代码，然后提交解决方案。提交解决方案后，程序员可以研究他人的解决方案，并学习到对同一个问题不同的解决方式。更重要的是，每个解决方案都会收到来自其他参与者的反馈。

反馈是 Exercism 的超级力量。鼓励所有参与者不仅接收反馈而且提供反馈。根据 Owen 说的，Exercism 的社区成员提供反馈比完成练习学到更多。她说：“这是一个强大的学习经验，你需要发表内心感受，并检查你的假设、习惯和偏见”。她还指出，反馈可以有多种形式。

欧文说：“只需进入，观察并发问”。

那些刚刚接触编程，甚至只是接触了一种特定语言的人，可以通过预设好的问题来提供有价值的反馈，同时通过协作和对话来学习。

除了对新语言的 “微课”学习 bite-sized learning 之外，Exercism 本身还强烈支持和鼓励项目的新贡献者。在 SitePoint.com 的一篇文章中，欧文强调：“如果你想为开源贡献代码，你所需要的技能水平只要‘够用’即可。” Exercism 不仅鼓励新的贡献者，它还尽可能地帮助新贡献者发布他们项目中的第一个补丁。到目前为止，有近 1000 人成为 Exercism 项目的贡献者。

新贡献者会有大量工作让他们忙碌。 Exercism 目前正在审查其语言发展轨迹的健康状况，目的是使所有发展轨迹可持续并避免维护者的倦怠。它还在寻求捐赠和赞助，聘请设计师提高网站的可用性。

Owen 说：“这些改进对于网站的健康以及为了 Exercism 参与者的发展是有必要的，这些变化还鼓励新贡献者加入并简化了加入的途径。” 她说：“如果我们可以重新设计，产品方面将更加可维护……当用户体验一团糟时，华丽的代码一点用也没有”。该项目有一个非常活跃的讨论仓库，这里社区成员合作来发现最好的新方法和功能。

那些想关注项目但还没有参与的人可以关注邮件列表。

作者简介：

VM（Vicky）Brasseur - VM（也称为 Vicky）是技术人员、项目、流程、产品和 p^Hbusinesses 的经理。在她超过 18 年的科技行业从业中，她曾是分析师、程序员、产品经理、软件工程经理和软件工程总监。 目前，她是 Hewlett Packard Enterprise 上游开源开发团队的高级工程经理。 VM 的博客在 anonymoushash.vmbrasseur.com，tweets 是 @vmbrasseur。

via: https://opensource.com/article/17/1/exercism-learning-programming

作者：VM (Vicky) Brasseur 译者：geekpi 校对：jasminepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出