通过理解这些永恒的见解，你将成为更好的开发人员。
成为一名优秀的程序员，就是让你自己接受不断学习的生活（活到老，学到老）。包括新功能、新语言、新工具、新框架等优秀的源头——学习永不停息。但是，其实计算机科学也是一个令人惊讶的传统领域，这是基于久经考验的原则得出来的。我们已经添加了面向对象、现代硬件以及人工智能。然而，尽管发生了这么多的变化，许多上一代人提出来的见解在今天仍然适用（这点和我们现在的名言警句类似）。
在这篇文章中，我剖析了一些我最喜欢的关于计算机科学的引用。我设置的唯一条件就是，每个优秀的引用必须至少有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原则，是不是让你铭记在心，还有最后说的缓存失效很难，命名很简单的错觉。
