现在，当有人提到“优化”这个词时，他们通常指的是“针对执行时间进行优化”，除非他们明确表示他们想要优化GPU内存消耗、网络流量等。了解优化对象当我开始的时候编程，我的处理器很慢，内存空间非常有限——有时以千字节为单位。因此，必须适当考虑内存使用和优化。在大学里，我们了解了优化的两个极端：可以牺牲空间来换取执行速度的提升，或者进行重复操作来换取优化的内存消耗。如今，没有人太在意内存的使用（demosener、嵌入式系统工程师和一些手游开发者除外），不仅是内存空间，还有硬盘空间。试想一下，仅仅安装看门狗就消耗了将近25Gb的硬盘空间。此外，当我在GoogleChrome选项卡中编写此内容时，我占用了130Mb的RAM空间。其实需要优化的对象很多：随着智能手机市场的增长，功耗的优化备受关注；优化可读性可以使代码易于阅读和调试，从而缩短开发周期，降低开发成本；还有很多其他的优化类型，这里不再赘述……优化可读性——让代码更容易阅读、遵循和理解。您应该明白，您在优化时很难考虑到所有方面。例如，在进行性能优化时，您很可能会增加应用程序的内存消耗并降低代码的可读性。为什么要优化可读性开发人员花费大量时间不是写代码，而是阅读代码、调试代码、查阅别人提交的开发文档、学习新的库等。计算机）——在他们的头脑中执行代码并试图记住当前的执行状态。这就是为什么程序员在阅读代码时会被打断和脾气暴躁的原因。时间==金钱您应该意识到的最重要的事情之一是您和您的同事浪费了很多时间。即使是勤奋的开发人员仍然会浪费大量时间做以下事情：实现现在不需要并且将来可能永远不会使用的功能。进行没有实际价值的改进。例如，花一周时间优化一个在1小时内只调用10ms的函数的执行时间。编写难以调试的代码并尝试查找其中的错误。编写其他人难以理解的代码。请注意，“其他”也可能是一周后的您。以上情况假设遇到问题的开发者经验丰富，熟悉如何写出高效的算法和简洁的代码，否则还有更多的情况需要罗列。优化可读性DonaldKnuth有一句名言。我敢打赌你已经听过很多次了。“在编程中，过早的优化是万恶之源。”-D.Knuth,1974我遇到过很多知道这句话的人，但真正理解它的人很少。最常见的误解是这样的：-为什么代码对于如此简单的任务如此复杂？-我优化了X和Y因为在未来...-你没听说过早优化是万恶之源吗？——当然，这不是过早的优化，我敢肯定程序的执行效率会更高。我想这是由于缺乏对过早优化一词的明确定义。这就是为什么这些人根本不认为他们做得太早了。那么我们如何定义这个词呢？过早优化-在工作系统中分析和运行测试之前进行的任何优化尝试。除了可读性之外的任何修改都是过早的优化。所以，与其说一个人不应该做什么，不如说一个人应该做什么。好吧，这句话可以这样读：Prioritizereadability。是什么阻碍了开发人员阅读代码好吧，我们都同意我们应该让代码更易于阅读，这样可以节省时间和金钱，对吧？但这到底是什么意思呢？有迹象表明，以下两个基本方面极大地拖慢了开发人员阅读代码的速度：代码晦涩难懂，代码难以理解。代码很难理解不幸的是，人们不能忽略代码中将两个数字相加并调用函数的部分，就像软件解释器（机械编译）一样。为了找到代码异常的原因，程序员必须了解源程序中编写的代码实现了什么功能，编写的初衷是为了实现什么功能。是什么让代码晦涩难懂？对于熟悉代码开发语言和程序中使用的算法（即他们有足够的知识来理解代码）的有经验的开发人员来说就是这种情况。错误的代码。奇怪的单个字母变量和1000行代码的冗长函数。代码格式错误或不一致。该代码包含冗余代码。该代码包含未记录的低级优化。代码太聪明了。我将跳过前两个，因为无论如何你不应该阅读糟糕的代码。如果您公司中有人编写了错误的代码，您应该改正它或将其丢弃。当然，您必须对整个代码库执行严格的编程纪律。3.代码中包含冗余代码或所谓的行优化。带有嵌套函数调用和条件运算符的长代码行很难解析。当然，你可以说这种观点是片面的。但是这些人觉得不管可读性如何，源代码越短越好。4.未加注解的优化级别最初，代码可读性很强，运行稳定，但有些人决定在某些方面对其进行优化。经过仔细的剖析，这可能是一个很好的优化，但此时代码看起来像是数组、位操作和幻数的组合。没有人知道代码在做什么，甚至不知道代码应该做什么，因为做优化的人没有提交任何指令。也许您听说过好的代码不需要文档。但是优化后的代码（尤其是当优化非常理想时）必须有文档。在您的代码库中，可能大多数优化只是像这样未注释的行：if(val!=val){...}5.代码太聪明了作为软件开发人员，我们掌握越来越多的学术技能并应用它们到实际的代码开发。毕竟，我们是计算机科学家，而不仅仅是编码员！有些语言甚至鼓励开发者使用前沿技术，让代码更具表现力和学术性。当您使用代码构建一个非常健壮的系统时，您会获得那种成就感，尤其是当您从数学上证明了一个99.997%的受过教育的人都无法理解的深奥定理时。即使代码被很好地封装成模块/类/函数，并且这些模块包含完全可读的命令式代码，但要让其他人理解这段代码，他们必须掌握整个代码的框架以及所有相关的技术和模式。再次提醒，一周后“其他人”可能就是你。很可能这就是我只认识两个在工作中使用Scala的人的原因。就个人而言，我非常喜欢Scala语言。对我来说，这是一个学术游乐场，我可以在那里建造玻璃城堡。一旦您更好地了解它，它的功能就会越来越多，您就会越来越意识到它本质上只是一种编程语言（请不要在这里引用我的话！）。不如Perl，但即使是最漂亮的代码库也需要修改和更新。现在，你需要找一个能看懂这段漂亮代码的人……简洁明了的代码很难读懂，这似乎是有争议的。“调试软件的难度是编写代码的两倍，如果你足够聪明来编写代码，那么你还不够聪明来调试它。"-BrianKernighan#p#Codeishardtofollow在阅读代码时，您通常需要频繁地从一个函数或类跳转到另一个。掌握您使用的集成开发环境(IDE)可以节省大量阅读时间。通过使用集成开发环境（如VisualStudio）的“跳转到声明”、“查找使用”、“导航至”、“检查”等功能，你可以看到整个代码是一个连通图。在记事本中写代码是一个不错的选择，但是要想有效阅读代码，就必须掌握集成开发环境。那么，连通图到底是什么？连通图是拓扑空间中任意两点之间连通的图。graph它们之间有一条路径。（来源）换句话说，在“连接”代码中，您可以轻松地从一个方法跟踪到另一个方法，并在您的脑海中构建这段代码的功能框架。如果代码的某个部分是损坏（在这种情况下，IDE无法帮助您在功能），通常你必须花一些时间自己寻找链接。代码中断开的链接越多，就越难遵循，代码就越难阅读。那么，为什么代码图坏了呢？有几个原因，下面列出了一些常见的情况：1.使用字符串来引用方法和属性有些框架喜欢这样做，它们将“回调”作为字符串传递，并在需要时使用反射。此时需要使用CMD+F来查找。最糟糕的是动态语言中的动态字符串……感谢JavaScript或AS3！2。代码被分成离散的部分。例如，你一半的代码是用C#编写的，另一半是在可视化节点编辑器中生成的。在两者之间跳跃并不容易。依赖注入框架和其他XML配置工具。虽然没有明确说明，编写XML配置文件也是编程。这就是所谓的声明式编程（更不用说那些基于XML构建命令式语言的疯子了）。3.巨大的图节点20个链接跳数1000行代码去这个函数？...哎呀。你不需要像这样的节点图。4.一切都太抽象通过跳转到一个声明，你到达一个接口或一个抽象类并且必须弄清楚哪些实现。依赖注入、抽象工厂和所有其他反对依赖的方法使情况变得更糟。代码图中节点之间的连接过于抽象。话虽如此，我讨厌依赖注入(DI)和可扩展标记语言(XML)。但是DI是一个很棒的工具，它可以让你避免编写意大利面条式的代码，并使程序架构更加模块化和更易于测试。但就像任何好事一样，过度依赖必然会产生负面影响。我曾经在审查一个应用程序时感到非常沮丧，因为我意识到我无法弄清楚程序从哪里开始。..例如它的入口点在哪里。这都是在程序启动时从XML配置工具自动生成的。但我讨厌XML配置工具。***所以，到这里你应该学会了：掌握你的IDE，让你的代码图尽可能的连通，先写简单的代码，写不必要的代码是浪费钱。强迫自己编写简单的代码，避免在早期阶段进行优化确实有一些困难，而且需要时间。在截止日期前2小时连续工作了48小时，如果你半睡半醒并且能够阅读你正在使用的代码，你应该对以前的自己说“谢谢”。附言不要错过reddit和hackernews上的精彩讨论。非常感谢/u/Arandur纠正了大量的语法错误！（备注：限于译者水平，翻译难免有错误和不足之处，敬请批评指正！）本文由伯乐在线-ashiontang翻译自ValentinSimonov。
