成为一名程序员就是报名参加终身培训。新的源流-新功能，新语言，新工具，新框架-永不枯竭。但与此同时，编程是一个领域，令人惊讶地忠于传统，因为一切都基于经过时间考验的原理。我们引入了面向对象的程序设计，现代硬件解决方案，人工智能，但是，尽管进行了所有这些更改，但上一代制定的许多公理如今仍然适用。我将本文专门介绍了一些有关编程的最喜欢的声明。我做出选择的唯一标准是要求报价至少等于20年。因为只有过时的技术才能很快变得不可用，而我们祖先程序员的古老诫命却长期存在。1.间接性
“所有编程问题都可以通过创建附加级别的间接访问来解决”-David Willer
这是《计算机科学理论与应用》一书的引文，每个人都喜欢重复，很少有人喜欢解释。尽管如此，这是我最喜欢的编程真理之一-它恰如其分地揭示了编程的本质。理解间接性的最简单方法是想象层。好吧，例如，假设您有一个小项目，需要在其中将组件A放置在组件B中：这两个组件都是标准化的，因此将它们分解成组件并更改操作原理是行不通的。您可以创建一个单独的附加组件（PlugTwoProngVariant），但这既繁琐又不必要。有一个更好的解决方案：在这两个组件之间添加一个适配器层，可以成功地与这两个组件交互并充当它们之间的中介。有了所有这些，如果间接通过在组件之间添加否则不会停靠的其他层而被用尽，那当然是有用的，但在应用中非常有限。但是通过改变问题区域的环境来解决问题的想法贯穿了所有编程的自上而下。当您尝试将新数据模型拟合到旧界面时会遇到它。当您尝试将具有旧代码的应用程序附加到新Web服务的后端时，就会遇到它。当您需要添加一些新的高级功能（如日志记录和缓存）或协调一些高级服务（如发送消息和进行交易）的工作时，就会遇到它。在这座金字塔的最高处，您会获得诸如机器学习之类的精细指导（如果您无法编写自己的行为，请添加另一层代码来为您解决此问题）。许多人会告诉您，编程的重点是用连最笨的计算机也能理解的语言编写清晰的指令。但是大卫·惠勒的报价更深入地探讨了这个问题。成为一名优秀的程序员意味着要爬上间接的阶梯，争取最常见的解决方案。关于间接性的奖励报价是一个强大的工具，但是您必须付出复杂性。人们很少引用著名名言后的陈述：“这通常会带来一个新问题。”-惠勒（David Wheeler）。
正是由于这个事实，程序员才长期从事业务。2.关于简单
“简单是可靠性的前提”-Edsger Dijkstra
不乏明智的程序员警告我们不要迫切需要使代码复杂化。但是几乎没有人能清楚地说明作为计算机科学先驱Edsger Dijkstra对我们而言的复杂性。重点是：您选择支持简单性，而不仅仅是出于希望让人们满意的未来。并不是因为您假定将来有能力重用此代码。这不是因为您希望它更准确地检查检查，也不是因为您希望促进将来进行更改的过程（尽管这当然是一个宝贵的优势）。您这样做是因为简单是前提。没有它，您将永远不会拥有可信赖的代码，可用于运行业务或处理数据。要采取Dijkstra的立场，我们需要改变对“好代码”的理解。这不一定是最简洁的代码，也不是最快的代码，也不一定是最深刻的代码。好的代码是您可以依靠的代码。关于主题的奖励报价保持代码简单的最佳方法之一就是记住少即是多。Dijkstra提供了一种新的度量单位，它总是使我们想起这一点：“如果我们要计算代码行数，我们不应认为它们是书面的，而是浪费的”-Edsger Dijkstra
3.关于可读性和重写
“代码比编写起来难读”-Joel Spolsky
乍一看，来自编程传奇人物和Stack Overflow联合创始人Joel Spolsky的这段话似乎是合理的，但似乎是肤浅的。是的，代码片段信息丰富，压缩过度或冗长。这不仅适用于其他人写的东西。如果您看一下自己去年的工作，您将需要一些时间来重新创建您曾经知道的逻辑。但是Spolsky的观察结果展现了一些有趣的东西。难以阅读的代码的危险不仅是最明显的后果（难以纠正和改进）。还有另一个很大的危险：难以阅读的代码看上去比实际情况差。实际上，了解别人的代码似乎是一项艰巨的任务，您将很想做Spolsky所说的所有错误中最严重的 -再次重写所有内容。我并不是说系统架构永远不会从这种重写中受益。当然，碰巧会赢。但是这种改进是昂贵的。在涉及测试和修复bug的所有方面（这是开发的两个组成部分，比编写代码本身要花费更多的时间），您将回到初始位置。重写看起来很诱人，因为它符合开发人员最常见的误解之一-倾向于低估概念上简单的事物的人工成本。这就是为什么50％的时间都花在项目的最后5％上的原因。基本任务可能会非常耗时！对于过去已经解决的问题，解决方案总是看起来很简单。好吧，如果您从头开始重写所有内容以使代码更完美，那么应该不这样做，那么，更成功的替代方法是什么？答：让每个开发人员参与到连续的零散重构过程中。因此，由于一系列小的更改，您的代码也在不断得到改进-真正的好处是风险最小。在此过程中可以提高可读性。对该主题的奖励报价如果您仍然怀疑可读性的重要性，Martin Fowler将帮助您更广泛地研究问题：任何傻瓜都可以编写计算机可以理解的代码。优秀的程序员编写人们可以理解的代码。”-Martin Fowler
换句话说，程序员的任务不仅是发布工作代码，还发布具有内部逻辑的代码。4.关于重复
“不要重复。每条知识都必须在系统中具有唯一，明确，可靠的表示形式”-Andy Hunt和David Thomas
每个自重的程序员都知道重复存在很多麻烦。如果您在多个地方编写相同的东西，则必须花费更多的精力来测试和修复错误。更糟糕的是，您为差异创造了条件。例如，一个代码段可能随后被更新，而其他相关过程可能未得到遵从。发散程序是不能被信任的程序，不能被信任的程序不能被认为是可行的解决方案。使用该方法可以避免此错误，GetTeamUniform()但是，重复不仅会对代码造成严重破坏。此版本的著名DRY原则（请勿重复自己）解释了广泛消除重复的原则，涵盖了其他重复出现的地方。现在，对话不再是代码中的重复-我们也正在讨论整个系统中的重复。系统以各种格式编码知识。特别是：- 经营者
- 代码注释
- 开发人员或客户的文档
- 数据模式（例如数据库表）
- 其他规范-测试计划，过程组织文档，组装规则
所有这些组的内容可能重叠。当这种情况发生时，他们就有可能开始广播一个现实的不同版本。假设如果文档描述了一种工作模型，而应用程序本身遵循另一种工作模型，该怎么办？在这种情况下，什么被认为是真理的持有者？但是，如果数据库中的表与代码中的数据模型不匹配怎么办？还是代码注释描述的操作或算法与实际实现有根本不同？每个系统都需要一个单一的，可靠的表示形式，其他所有内容都基于该表示形式。顺便说一句，不应认为真相申请人之间的冲突仅在小型项目中发生，或者是由于质量差的代码导致的。显而易见的最佳示例之一是XHTML和HTML5之间的斗争。一方声称该规范-这是官方的正确版本，浏览器应适应该规范。另一个阵营反对将浏览器的行为视为事实上的标准-毕竟，这就是设计人员在编写网页时如何想象一切的方式。最终，浏览器推广的真理版本胜出了。从那时起，HTML5就是浏览器真正的功能，包括有效的快捷方式和错误。主题中的奖励报价。代码及其注释相互冲突的可能性引起了热烈的讨论：注释中有什么好不好的地方？极端编程的支持者完全不信任他们。“代码永远不会说谎，但这会伴随注释发生”-Ron Jeffries
5.关于复杂问题
“在计算机科学中，只有两个复杂的问题-使高速缓存无效和提出名称”-Phil Carleton
从表面上看，这句话似乎只是程序员的笑话，很有趣，但并不脱颖而出。每个人都可以感觉到听起来像是一项艰巨的任务（使高速缓存无效）和听起来像是在胡说八道的事物（发明名称）之间的对比。任何程序员都至少有一个小时因为一个可笑的小问题而花了整整一个小时-两个参数，以错误的顺序放置，一个变量在某个地方带有大写字母而在某个地方没有（谢谢，JavaScript！）。人们必须使用计算机来实现其目标，而编程始终是高级系统规划和愚蠢的错字的混合体。但是，如果我们仔细观察Phil Cardboard的话，我们会在这里发现更多的思考空间。很难想出名字，不仅是因为程序员头疼小，而且一生都在努力。这里的重点是名称是程序员主要任务（程序设计）的一个方面。换句话说，通常如何编写清晰，整洁和一致的代码？恶名有很多。我们都遇到了以数据类型（myString，obj），缩写（pc即产品目录），一些无关紧要的实现细节（swappable_name，formUserInput）甚至是无名（ret_value，tempArray）很容易陷入陷阱并根据您现在对它的操作而不是根据其内容来命名变量。而用逻辑数据类型的值来说，麻烦是：这是什么意思progress-进度已经开始，您需要在界面中显示有关进度的信息还是其他一般情况？资料来源：CommitStrip.com传递«results_tmp_2? ?.. , ? !» — «, … , results_tmp_2. »
但是变量名仅仅是开始。当您开始提出类的名称时，就会出现一个问题，即如何将代码分成独立的部分。公共成员的姓名决定了接口的表示形式，应用程序的不同部分将通过该接口进行交互。通过为一段代码分配名称，您不仅在描述它可以做什么，而且还在设置它可以做什么。主题中的奖励报价。« – , » —