不多有人会告诉你的5个编程名言，安排！

经过理解这些永恒的看法，你将成为更好的开发人员。

成为一名优秀的程序员，就是让你本身接受不断学习的生活（活到老，学到老）。包括新功能、新语言、新工具、新框架等优秀的源头——学习永不停息。可是，其实计算机科学也是一个使人惊讶的传统领域，这是基于久经考验的原则得出来的。咱们已经添加了面向对象、现代硬件以及人工智能。然而，尽管发生了这么多的变化，许多上一代人提出来的看法在今天仍然适用（这点和咱们如今的名言警句相似）。

在这篇文章中，我剖析了一些我最喜欢的关于计算机科学的引用。我设置的惟一条件就是，每一个优秀的引用必须至少有20年的历史。由于古老的技术很快就会变得毫无用处，而咱们编程祖先的古老戒律却有更强的持久力。

1. 关于Indirection

"计算机科学中的全部问题均可以经过另外一种间接的方式来解决"。——David Wheeler

这里有一个不多被开发者愿意解释却又常常被复用的compsci的引用。但这是我最喜欢的编程真理之一，由于它触及了编码的核心。

开始考虑Indirection的最简单的方法是想像层次。例如，假设您有一个小项目，须要将组件A放入组件B：

两个都是标准的组件，所以你不能破坏他们并更改他们的工做方式。你能够构建一个全新的组件，但这须要大量的工做和没必要要的重复。一个更好的方式就是这两个部分之间添加一层——一个适合于两个组件并在它们之间进行转化的适配器。（其实就是设计模式中的适配器模式）

如今，若是Indirection仅仅是添加一个新层来说不兼容的部分组合在一块儿，这将是很好的，也确实颇有用。可是围绕问题进行构建来解决问题的想法是一个从底层一直延伸到顶层的概念。当你试图将新的数据模型适配到旧的用户接口时，你就会看到它；当你试图将遗留应用安装到一个新的web后端服务器时，你就会看到它；当你须要绑定更好级别的特性（如日志和缓存）或协调更高级别的服务（如消息传递和事务）时，你就会看到它；在金字塔的顶端，你将会接触到像机器学习（当你不能为你须要的行为编码时，再写一层代码来帮你找出它）这样的少数主题。

不少人会告诉你，编程就是用一种即便电脑小白也能理解的语言写出明确的指令。可是大卫·惠勒的名言揭示了
更好的看法：好的编程是要爬上抽象的阶梯才能到达最通用的解决方案。

相关引用：

间接是强大的，可是复杂性是有代价的。人们不多引用惠勒关于间接的后续评论：

但一般会产生另外一个问题——David Wheeler

从那时起，这一真理就一直让程序员在商业上如日中天。

2. 关于简单

“简单是可靠性的先决条件”。——Edsger Dijkstra

很多明智的程序员警告咱们不要使代码过于复杂。但不多有人能比荷兰计算机科学先驱 Edsger Dijkstra 更清楚地说明复杂性的成本。

这里的看法是：你不会选择简单做为送给将来的礼物。你不作由于您正在期待机会重用您的代码，或者由于您但愿在代码评审时让它看起来更整洁，或者是由于您想使其更易于修改（尽管全部这些好处都是宝贵的！）。您这样作由于简单是一个先决条件。若是没有简单性，就永远不可能有能够信赖的可靠代码来开展业务或处理您的数据。

要接受Dijkstra的观点，咱们须要从新定义“好代码”的含义。不是最短的代码。它不必定是最快的代码。绝对不是最聪明的代码。能够信任的代码。

相关引用：

保持代码简单的最佳方法之一就是记住少便是多。Dijkstra 提供了一个可帮助咱们牢记这一点的指标：

“若是咱们但愿计算代码行，则不该将它们视为‘产生的行’，而是看做‘花费的行’”。——Edsger Dijkstra

3. 关于可读性和重写

“读代码比写代码难”。——Joel Spolsky

乍一看，这个引用来自软件传奇和StackOverflow共同建立者Joel Spolsky彷佛是正确的，但看似肤浅。是的，代码可能很密集，简短而又冗长。这不只仅是别人的代码。若是您看一年前的工做，您可能须要一些时间来整理一下您曾经很是了解的逻辑。

可是Spolsky 的洞察力却有所不一样。您没法阅读的代码的危险不只仅是显而易见（很难对其进行更改和改进）。相反，更大的危险是复杂的代码彷佛比实际状况更糟。其实，尝试了解别人已经写好的代码是如此之好，以致于您可能会被吸引犯 Spolsky所说的最严重的错误-决定从头开重写该代码始。

并非说重写不能改善系统的体系结构。他们绝对能够。但这些改进付出了巨大的代价。他们重置测试和调试错误的时间固定，两项活动比单纯的编码要花更长的时间。重写很诱人由于它们是软件开发中最多见的偏见之一：咱们低估了作概念上简单的事情的努力。这就是为何最终的5％项目须要50％的时间。简单的事情可能会很是耗时！和解决您已经解决的问题相比彷佛没有比这容易的了。

所以，若是您不该该重写全部内容以使其完美，那么有什么更好的解决方案？答案是让每一个开发人员都参与恒定大小的重构。这个为您提供小的，连续的代码改进-真正有回报，而且风险很小。您能够在编码的过程当中提升可读性。

相关引用：

若是您仍然不肯定可读性的重要性，Martin Fowler能够帮助您解决这一问题角度来看：

“任何人均可以编写计算机能够理解的代码。优秀的程序员写的代码人类均可以理解。”——Martin Fowler

换句话说，程序员的工做不只是写代码，更在于作有意义的事情。

4. 关于重复

“不要重复本身。每一项知识必须有一个单一的，明确的，权威的系统中的表示形式。”——Andy Hunt and Dave Thomas

每一个自重的程序员都知道重复是万恶之源。若是您在不一样的地方写相同的东西，你在作额外的工做，测试和调试。更糟糕的是，您正在引入不一致-例如，若是代码的一部分已更新，而其余相似的代码没有同步更新。程序不一导致您的程序存在误差，而您存在误差的程序再也不是可行的解决方案。

可是，重复代码并非形成严重破坏的惟一地方。这个版本的著名的“请勿重复本身”（DRY）规则将无重复原则扩展为覆盖其余可能隐藏矛盾之处。咱们再也不谈论代码重复。咱们也在谈论系统中的重复-系统具备代码知识的许多不一样方式。它们包括：

• 代码声明
• 代码注释
• 开发人员或客户文档
• 数据模式（例如，数据库表）
• 其余规范，例如测试计划，工做流程文档和构建规则

全部这些层均可以彼此重叠。而当他们这样作时，他们就有可能引入同一现实的不一样版本。例如，若是文档描述一种工做方式，但应用程序遵循另外一种方式？谁拥有真相？若是数据库表与代码中的数据模型不匹配怎么办？或者注释描述了算法的操做，与实际的实施方式不符？每一个系统都须要一个单一的、权威的，其余一切都必须高度统一。

顺便说一下，竞争版本的真相不只是小规模项目中的问题或设计不良的代码。最好的例子之一是随着XHTML和HTML5之间的斗争。一个阵营认为规范是官方事实，须要对浏览器进行更正以遵循它。另外一派声称浏览器行为是事实上的标准，由于这就是当设计师们写网页时已经想到了。最后，浏览器版本的真相获胜。从这一点上来讲，HTML5的浏览器就是这么作的 -包括快捷键，他们容许和他们接受的错误.

相关引用：

代码和注释彼此矛盾的可能性引起了关于注释是否弊大于利的激烈辩论。极限编程的支持者公开怀疑：

“代码永远不会说谎；代码注释有时会。”——Ron Jeffries

5. 关于难题

“计算机只有两件事科学：缓存失效以及命名事物。”——Phil Karlton

乍一看，这句话彷佛颇有趣，但倒是普通的编程笑话。听起来很困难的内容（缓存无效）与听起来很轻松（为事物命名）的事物能够当即关联。每个程序员投入了数小时的工做来解决一个荒谬的琐碎问题，例如参数传递顺序错误或大小写不一致的变量（感谢JavaScript）。只要人类须要与机器合做完成任务，编程将成为高级系统规划和琐碎输入错误的混搭。

可是，若是您再看一看Phil Karlton的引用，还有更多须要解决的问题。命名事情并不难，由于程序员的生活常常因小小的头痛而毁了。这也是由于命名问题其实是每一个程序员最关心的重要工做：软件设计。换句话说，您如何编写清晰的代码，干净，一致吗？

有不少方法可使命名错误。咱们都看到过以变量命名的数据类型（myString，obj），缩写（用于产品目录的pc），一些琐碎的实现细节（swappable_name，formUserInput），甚至什么都没有（ret_value，tempArray）。容易陷入基于如下方式命名变量的陷阱您当时正在使用它作什么，而不是其中包含什么。布尔值是特别棘手的-当 progress 标记进度开始，代表您须要在用户界面中显示进度信息，或彻底标记某些内容不一样？

可是变量名仅仅是开始。命名类提出了如何将代码分红独立部分的问题。命名 public 成员将影响您的工做方式显示容许应用程序的一部分与另外一部分交互的界面。锁定这些名称不只描述了一段代码能够作什么，并且肯定它将作什么。

相关引用：

“计算机科学有两件事：缓存失效，事物命名和一对一错误。”——Leon Bambrick

结语

很高兴，你和我同样坚持看到了最后，是否是对本身编程过程当中有不少想改变的地方呢？好比简单行，可读性，DRY原则，是否是让你铭记在心，还有最后说的缓存失效很难，命名很简单的错觉。