“它能做什么 Windows 不能做的吗？”

这是许多人在考虑使用 Linux 桌面时的第一个问题。虽然支撑 Linux 的开源哲学对于某些人来说就是一个很好的理由，但是有些人想知道它在外观、感受和功能上有多么不同。在某种程度上，这取决于你是否选择桌面环境或窗口管理器。

如果你想要的是闪电般快速的桌面体验且向高效妥协, 那么经典桌面中的窗口管理器可能适合你。

事实之真相

“ 桌面环境 Desktop Environment （DE）”是一个技术术语，指典型的、全功能桌面，即你的操作系统的完整图形化布局。除了显示你的程序，桌面环境还包括应用程序启动器，菜单面板和小部件等组成部分。

在 Microsoft Windows 中，桌面环境包括开始菜单、显示打开的程序的任务栏和通知中心，还有与操作系统捆绑在一起的所有 Windows 程序，以及围绕这打开的程序的框架（包括右上角的最小按钮、最大按钮和关闭按钮）。

Linux 中有很多相似之处。

例如，Linux Gnome 桌面环境的设计略有不同，但它共享了所有的 Microsoft Windows 的基本元素 - 从应用程序菜单到显示打开的应用程序的面板、通知栏、窗框式程序。

窗口程序框架依赖于一个组件来绘制它们，并允许你移动并调整大小：它被称为“ 窗口管理器 Window Manager （WM）”。因为它们都有窗口，所以每个桌面环境都包含一个窗口管理器。

然而，并不是每个窗口管理器都是桌面环境的一部分。你可以只运行窗口管理器，并且完全有这么做的需要。

离开你的环境

对本专栏而言，所谓的“窗口管理器”指的是可以那种独立进行的。如果在现有的 Linux 系统上安装了一个窗口管理器，你可以在不关闭系统的情况下注销，在登录屏幕上选择新的窗口管理器，然后重新登录。

不过, 在研究你的窗口管理器之前，你可能不想这么做，因为你将会看到一个空白屏幕和稀疏的状态栏，而且它或许能、或许不能点击。

通常情况下，可以直接在窗口管理器中直接启动终端，因为这是你编辑其配置文件的方式。在那里你会发现用来启动程序的按键和鼠标组合，你实际上也可以使用你的新设置。

例如，在流行的 i3 窗口管理器中，你可以通过按下 Super 键（即 Windows 键）加 Enter 键来启动终端，或者按 Super + D 启动 应用程序启动器 app launcher 。你可以在其中输入应用程序名称，然后按 Enter 键将其打开。所有已有的应用程序都可以通过这种方式找到，一旦选择后，它们将会全屏打开。

i3 还是一个平铺式窗口管理器，这意味着它可以确保所有的窗口均匀地扩展到屏幕，既不重叠也不浪费空间。当弹出新窗口时，它会减少现有的窗口，将它们推到一边腾出空间。用户可以以垂直或水平相邻的方式打开下一个窗口。

功能亦敌亦友

当然，桌面环境有其优点。首先，它们提供功能丰富、可识别的界面。每个都有其特征鲜明的风格，但总体而言，它们提供了普适的默认设置，这使得桌面环境从一开始就可以使用。

另一个优点是桌面环境带有一组程序和媒体编解码器，允许用户立即完成简单的任务。此外，它们还包括一些方便的功能，如电池监视器、无线小部件和系统通知。

与桌面环境的完善相应的，是这种大型软件库和用户体验理念独一无二，这就意味着它们所能做的都是有限度的。这也意味着它们并不总是非常可配置。桌面环境强调的是漂亮的外表，很多时候是金玉其外的。

许多桌面环境对系统资源的渴求是众所周知的，所以它们不太喜欢低端硬件。因为在其上运行的视觉效果，还有更多的东西可能会出错。我曾经尝试调整与我正在运行的桌面环境无关的网络设置，然后整个崩溃了。而当我打开一个窗口管理器，我就可以改变设置。

那些优先考虑安全性的人可能希望不要桌面环境，因为更多的程序意味着更大的攻击面 —— 也就是坏人可以突破的入口点。

然而，如果你想尝试一下桌面环境，XFCE 是一个很好的起点，因为它的较小的软件库消除了一些臃肿，如果你不往里面塞东西，垃圾就会更少。

乍一看，它不是最漂亮的，但在下载了一些 GTK 主题包（每个桌面环境都可以提供这些主题或 Qt 主题，而 XFCE 在 GTK 阵营之中），并且在“外观”部分的设置中，你可以轻松地修改。你甚至可以在这个集中式画廊中找到你最喜欢的主题。

时间就是生命

如果你想了解桌面环境之外可以做什么，你会发现窗口管理器给了你足够的回旋余地。

无论如何，窗口管理器都是与定制有关的。事实上，它们的可定制性已经催生了无数的画廊，承载着一个充满活力的社区用户，他们手中的调色板就是窗口管理器。

窗口管理器的少量资源需求使它们成为较低规格硬件的理想选择，并且由于大多数窗口管理器不附带任何程序，因此允许喜欢模块化的用户只添加所需的程序。

可能与桌面环境最为显著的区别是，窗口管理器通常通过鼠标移动和键盘热键来打开程序或启动器来聚焦效率。

键盘驱动的窗口管理器特别流畅，你可以启动新的窗口、输入文本或更多的键盘命令、移动它们，并再次关闭它们，这一切无需将手从 键盘中间 home row 移开。一旦你适应了其设计逻辑，你会惊讶于你能够如此快速地完成任务。

尽管它们提供了自由，窗口管理器也有其缺点。最显著的是，它们是赤裸裸的开箱即用。在你可以使用其中一个之前，你必须花时间阅读窗口管理器的文档以获取配置语法，可能还需要更多的时间来找到该语法的窍门。

如果你从桌面环境（这是最可能的情况）切换过来，尽管你会有一些用户程序，你也会缺少一些熟悉的东西，如电池指示器和网络小部件，并且需要一些时间来设置新的。

如果你想深入窗口管理器，i3 有完整的文档和简明直白的配置语法。配置文件不使用任何编程语言 - 它只是每行定义一个变量值对。创建热键只要输入 bindsym、键盘绑定以及该组合启动的动作即可。

虽然窗口管理器不适合每个人，但它们提供了独特的计算体验，而 Linux 是少数允许使用它们的操作系统之一。无论你最终采用哪种模式，我希望这个概观能够给你足够的信息，以便对你所做的选择感到自信 —— 或者有足够的信心跨出您熟悉的区域来看看还有什么可用的。

作者简介：

Jonathan Terrasi - 自 2017 年以来一直是 ECT 新闻网专栏作家。他的主要兴趣是计算机安全（特别是 Linux 桌面）、加密和分析政治和时事。他是全职自由作家和音乐家。他的背景包括在芝加哥委员会发表的关于维护人权法案的文章中提供技术评论和分析。

via: http://www.linuxinsider.com/story/84473.html

作者：Jonathan Terrasi 译者：geekpi 校对：wxy

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

真正的组织文化变革有助于弥合你原以为无法跨过的鸿沟

回想一下你最近一次尝试改掉一个个人习惯的事情，你可能遇到过这样的情形，你需要改变你思考的方式并且改掉之前的习惯。这很艰难，你只能试着改变你自己的思维方式。

所以你可能会试着让自己置身于新的环境。新的环境实际上可帮助我们养成新的习惯，它反过来又会促成新的思维方式。

那就是能否成功改变的所在：思考的越多，得到的越多。你需要知道你在改变的原因以及你的目的所在（而不仅仅你要怎么做），因为改变本身往往是短暂和短视的。

现在想想你的 IT 组织需要做出的改变。也许你正在考虑采用像 DevOps 这样的东西。这个我们称之为 “DevOps” 的东西有三个组件：人、流程和工具。人和流程是任何团体组织的基础。因此，采用 DevOps 需要对大多数组织的核心进行根本性的改变，而不仅仅是学习新的工具。

如同其它的改变一样，它也是短视的。如果您将注意力集中在将改变作为单点解决方案 —— 例如，“获得更好的报警工具” —— 你可能只是管中窥豹。这种思维方式或许可以提供一套拥有更多铃声、口哨以及可以更好地处理呼叫轮询的工具，但是它不能解决这样的实际问题：警报不能送达到正确的团队，或者故障得不到解决，因为实际上没有人知道如何修复服务。

新的工具（或者至少一个新工具的想法）创造了一个讨论潜在问题的机会，可以让你的团队讨论对监控的看法。新工具让你能够做出更大的改变 —— 信仰和做法的改变 —— 它们作为你组织的基础而显得更加重要。

创造更深层次的变革需要一种可以全新地改变观念的方法。要找到这种方法，我们首先需要更好的理解变革的驱动力。

清除栅栏

就改革而言，它不同于推翻。这是一条直白且简单的原则，这个原则或许被视作悖论。在这种情况下，存在某种制度或法律；这么说吧，为了简单起见，在一条路上架设了一个栅栏或门。当今的改革者们来到这儿，并说：“我看不到它的用处，让我们把它清除掉。”更聪明的改革者会很好地回答：“如果你看不到它的用处，我肯定不会让你清除它，回去想想，然后你可以回来告诉我你知道了它的用处，我也许会允许你摧毁它。” — G.K Chesterton, 1929

为了了解对 DevOps 的需求 —— 它试图将传统意义上分开的开发部门和运维部门进行重新组合 —— 我们首先必须明白这个分开是如何产生的。一旦我们"知道了它的用处"，然后我们就会知道将它们分开是为了什么，并且在必要的时候可以取消分开。

今天我们没有一个单一的管理理论，但是大多数现代管理理论的起源可以追溯到 弗雷德里克·温斯洛·泰勒 Frederick Winslow Taylor 。泰勒是一名机械工程师，他创建了一个衡量钢厂工人效率的系统。泰勒认为，他可以对工厂的劳动者运用科学分析的方法，不仅可以改进个人任务，也证明发现了有一个可以用来执行任何任务最佳方法。

我们可以很容易地画一个以泰勒为起源的历史树。从泰勒早在 18 世纪 80 年代后期的研究出现的时间运动研究和其他质量改进计划，跨越 20 世纪 20 年代一直到今天，我们可以从中看到六西格玛、精益，等等类似方法。自上而下、指导式管理，再加上研究过程的系统方法，主宰了今天主流商业文化。它主要侧重于把效率作为工人成功的测量标准。

如果泰勒是我们这颗历史树的根，那么我们主干上的下一个主叉将是 20 世纪 20 年代通用汽车公司的 阿尔弗雷德·斯隆 Alfred P. Sloan 。通用汽车公司创造的斯隆结构不仅持续强劲到 21 世纪初，而且在未来五十年的大部分时间里，都将成为该公司的主要模式。

1920 年，通用公司正经历一场管理危机，或者说是缺乏管理的危机。斯隆向董事会写了一份为通用汽车的多个部门提出了一个新的结构《组织研究》。这一新结构的核心概念是“集中管理下放业务”。与雪佛兰，凯迪拉克和别克等品牌相关的各个部门将独立运作，同时为中央管理层提供推动战略和控制财务的手段。

在斯隆的建议下（以及后来就任 CEO 的指导下），通用汽车在美国汽车工业中占据了主导地位。斯隆的计划把一个处于灾难边缘公司创造成了一个非常成功的公司。从中间来看，自治单位是黑盒子，激励和目标被设置在顶层，而团队在底层推动。

泰勒思想的“最佳实践” —— 标准、可互换和可重复的行为 —— 仍然在今天的管理理念中占有一席之地，与斯隆公司结构的层次模式相结合，主导了僵化部门的分裂和孤岛化以实现最大的控制。

我们可以指出几份管理研究来证明这一点，但商业文化不是通过阅读书籍而创造和传播的。组织文化是 真实的 人在 实际的 情形下执行推动文化规范的 具体的 行为的产物。这就是为何类似泰勒和斯隆这样的理论变得固化而不可动摇的原因。

技术部门投资就是一个例子。以下是这个周期是如何循环的：投资者只投资于他们认为可以实现 他们的 特定成功观点的公司。这个成功的模式并不一定源于公司本身（和它的特定的目标）；它来自董事会对一家成功的公司 应该 如何看待的想法。许多投资者来自从经营企业的尝试和苦难中幸存下来的公司，因此他们对什么会使一个公司成功有 不同的 理念。他们为那些能够被教导模仿他们的成功模式的公司提供资金，希望获得资金的公司学会模仿。这样，初创公司孵化器就是一种重现理想的结构和文化的直接的方式。

“开发”和“运维”的分开不是因为人的原因，也不是因为不同的技能，或者放在新员工头上的一顶魔法分院帽；它是泰勒和斯隆的理论的副产品。责任与人员之间的清晰而不可渗透的界线是一个管理功能，同时也注重员工的工作效率。管理上的分开可以很容易的落在产品或者项目界线上，而不是技能上，但是通过今天的业务管理理论的历史告诉我们，基于技能的分组是“最好”的高效方式。

不幸的是，那些界线造成了紧张局势，这些紧张局势是由不同的管理链出于不同的目标设定的相反目标的直接结果。例如：

• 敏捷 ⟷ 稳定
• 吸引新用户 ⟷ 现有用户的体验
• 让应用程序增加新功能 ⟷ 让应用程序保持可用
• 打败竞争对手 ⟷ 维持收入
• 修复出现的问题 ⟷ 在问题出现之前就进行预防

今天，我们可以看到组织的高层领导人越来越认识到，现有的商业文化（并扩大了它所产生的紧张局势）是一个严重的问题。在 2016 年的 Gartner 报告中，57％ 的受访者表示，文化变革是 2020 年之前企业面临的主要挑战之一。像作为一种影响组织变革的手段的敏捷和 DevOps 这样的新方法的兴起反映了这一认识。“影子 IT” 的出现更是事物的另一个方面；最近的估计有将近 30％ 的 IT 支出在 IT 组织的控制之外。

这些只是企业正在面临的一些“文化担忧”。改变的必要性是明确的，但前进的道路仍然受到昨天的决定的约束。

抵抗并不是没用的

Bert Lance 认为如果他能让政府采纳一条简单的格言“如果东西还没损坏，那就别去修理它”，他就可以为国家节省三十亿。他解释说：“这是政府的问题：‘修复没有损坏的东西，而不是修复已经损坏了的东西。’” — Nation's Business, 1977.5

通常，改革是组织针对所出现的错误所做的应对。在这个意义上说，如果紧张局势（即使逆境）是变革的正常催化剂，那么对变化的 抵抗 就是成功的指标。但是过分强调成功的道路会使组织变得僵硬、衰竭和独断。重视有效结果的政策导向是这种不断增长的僵局的症状。

传统 IT 部门的成功加剧了 IT 孤岛的壁垒。其他部门现在变成了“顾客”，而不是伙伴。试图将 IT 从成本中心转移出来创建一个新的操作模式，它可以将 IT 与其他业务目标断开。这反过来又会对敏捷性造成限制，增加摩擦，降低反应能力。合作被搁置转而偏向“专家方向”。结果是一个孤立主义的观点，IT 只能带来更多的伤害而不是好处。

正如“软件吃掉世界”，IT 越来越成为组织整体成功的核心。具有前瞻性的 IT 组织认识到这一点，并且已经对其战略规划进行了有意义的改变，而不是将改变视为恐惧。

例如，Facebook 与人类学家 罗宾·邓巴 Robin Dunbar 就社会团体的方法进行了磋商，而且意识到这一点对公司成长的内部团体（不仅仅是该网站的外部用户）的影响。 扎波斯 Zappos 的文化得到了很多的赞誉，该组织创立了一个部门，专注于培养他人对于核心价值观和企业文化的看法。当然，这本书是 《开放式组织》的姊妹篇，那是一本描述被应用于管理的开放原则 —— 透明度、参与度和社区 —— 可以如何为我们快节奏的互联时代重塑组织。

决心改变

“如果外界的变化率超过了内部的变化率，那末日就不远了。” — Jack Welch, 2004

一位同事曾经告诉我他可以只用 “信息技术基础设施库（ITIL）” 框架里面的词汇向一位项目经理解释 DevOps。

虽然这些框架 似乎 是反面的，但实际上它们都集中在风险和变革管理上。它们简单地介绍了这种管理的不同流程和工具。在 IT 圈子外面谈论 DevOps 时，这一点需要注意。不要强调流程问题和故障，而是显示更小的变化引起的风险 更小 等等。这是强调改变团队文化的有益方式：专注于 新的 功能而不是老问题，是改变的有效中介，特别是当您采用别人的框架进行参考时。

改革不仅仅只是 重构 组织；它也是跨越历史上不可跨越的鸿沟的新途径 —— 通过拒绝把像“敏捷”和“稳定”这样的东西作为互相排斥的力量来解决我之前提到的那些紧张局势。建立注重 结果 胜过 功能 的跨部门团队是一个有效的策略。把不同的团队 —— 其中每个人的工作依赖于其他人 —— 聚集起来围绕一个项目或目标是最常见的方法之一。消除这些团队之间的摩擦和改善沟通能够产生巨大的改进 —— 即使在坚持铁仓管理结构时（如果可以掌握，则不需要拆除孤岛）。在这些情况下，对改革的 抵抗 不是成功的一个指标；而对改革的拥抱才是。

这些也不是“最佳实例”，它们只是一种检查你自己的栅栏的方式。每个组织都会有独特的、由他们内部人员创造的栅栏。一旦你“知道了它的用途”，你就可以决定它是需要拆解还是掌握。

本文是 Opensource.com 即将推出的关于开放组织和 IT 文化指南的一部分。你可以在这注册以便当它发布时收到通知。

（题图 : opensource.com）

作者简介：

Matt Micene 是 Red Hat 公司的 Linux 和容器传播者。从架构和系统设计到数据中心设计，他在信息技术方面拥有超过 15 年的经验。他对关键技术（如容器，云计算和虚拟化）有深入的了解。他目前的重点是宣传红帽企业版 Linux，以及操作系统如何与计算环境的新时代相关。

via: https://opensource.com/open-organization/17/5/what-is-the-point-of-DevOps

作者：Matt Micene 译者：zhousiyu325 校对：apemost，wxy

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

互联网世界新概念层出不穷，往往今天流行的概念和技术，明天就被取代和推翻。比如说，以前大家都说什么 服务器 Server 、 SQL 数据库 SQL Database 和 前端 Frontend ，而现在已经开始流行 ServerLess、No-SQL 了。

当然，ServerLess 不是说不要服务器了，而是指一些运行在无状态的容器的服务器端逻辑，比如 AWS 的 Lambda 的 FaaS。而 No-SQL 则是一种非关系型数据库。

而这位所谓的专家，什么都 “No” 和 “Less” 了，然后，就在办公室里面从早坐到晚，正在践行了“Codeless”（没代码）的日子。

via: http://turnoff.us/geek/codeless/

作者：Daniel Stori 译者：wxy

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

HTTP2 服务器推送会在一个请求中将用户请求的内容及相关内容一次性推送给用户——以避免用户再次发起请求。

via: http://turnoff.us/geek/http2-server-push-explained/

作者：Daniel Stori 译者：wxy

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

开源软件虽然可以免费使用，但就如同饲养一条幼犬一样（开始虽然花钱不多，后边越养越费钱）。在采用开源之前，确保能够了解其隐藏的成本和陷阱。

对于初创公司来说，开源软件是一把双刃剑。它可以成为一家创业公司的生命线，因为开源软件可以帮助初创企业快速创新，而不必从头开始。不过，正如有些人所说的，开源软件虽然可以免费使用，但就如同饲养一条幼犬一样，开始虽然花钱不多，后边越养越费钱。开源软件的真正代价是开源许可证合规成本。

滥用开源软件可能会造成获得投资的机遇被延迟或破坏。但是，如果遵守这些简单的法则，初创企业可以轻松地实现开源许可证合规。

法则一：不使用没有许可条款的软件

互联网上的一些软件不包含许可证通知，但这不意味它们可以自由使用。发布软件的人可能没有遵守上游许可条款。或者软件的作者可能尚未为其软件指定许可协议——无论是以开源方式亦或是其他方式。“没有许可条款”是指没有许可证：您应该避免使用该软件或要求作者为其该软件指定许可证。

法则二：不要违反开源许可证

开源软件的使用可能难以让其作者进行追踪，但并不意味着该软件的使用和不合规行为会被忽视。违反开源许可证可能会使初创公司面临法律责任和公众谴责，甚至可能会影响其被投资或收购。也可能导致潜在客户由于担心下游责任而拒绝购买您的产品。软件开发人员为实现其软件开源付出了巨大的努力，其中也包括上述的许可费用。滥用开源软件对这些开发人员是不公平的，并且损害了他们希望促成的创新。

法则三：跟踪您正在使用的软件

将来有一天您将必须提供您正在使用的开源软件的列表。及时维护该列表将会为您节约大量的时间和精力，因为潜在的投资者和收购方将会要求您提供该列表。大多数开源软件下载包中都包括一个 “license.txt” 或 “copy.txt” 文件。保留该许可证的副本，并记录其涵盖的软件。大多数创业公司都使用简单的电子表格跟踪软件许可情况。

法则四：了解 宽松 （ permissive ） 许可证和 左版 （ copyleft ） 许可证

开源许可证大致分为两种类型：宽松许可证（BSD、MIT 和 Apache）和左版许可证（GPL、LGPL、Eclipse 公共许可证、Mozilla 公共许可证以及 通用开发和分发许可证 （ Common Development and Distribution License ） ）。大多数公司及其客户对于使用遵循宽松许可证的软件没有什么法律上的担心。不过，遵循左版许可证需要更加谨慎，将软件保留为专有可能会与某些特定计划不一致。

法则五：遵守许可证 通知 （ notice ） 要求

无论是宽松许可证还是左版许可证，所有开源许可都有通知要求。通常，这意味着在分发开源软件时，您需要包含其所适用的许可证的副本，仅仅包括许可证的链接或缩略形式通常是不完备的。为了避免混淆或疏离您的客户，开发一个符合大多数开源许可证的通知传送策略非常重要。

法则六：了解哪些开源许可证与分布式软件兼容

除了 Affero GPL 之外，大多数开源许可证都没有涉及软件即服务（SaaS）的情境。对于 SaaS 和云系统的分布式组件（如 JavaScript）或分布式软件（包括移动 APP 和测试版），您可以使用遵循宽松许可证的软件，但在使用遵循左版许可证的软件之前，您需要特别小心。仅在其完全在自己的进程中执行并且没有链接的代码时才去使用遵循 GPL 的软件，而不要相信以下如何让 GPL 合规的谣传：动态链接至 GPL 代码或让客户下载 GPL 软件。仅将 LGPL 软件作为动态链接库进行使用。在不修改 API 的前提下使用遵循其它左版许可证的软件。遵循移动 APP 市场的分发规定也许与遵循某些特定的左版许可证有冲突（例如 GPL 或者 LGPL）。

法则七：在咨询律师之前不要贡献或发布开源软件

贡献和发布开源软件可能是公众的福音，但它可能不是您业务上的正确选择。一旦作出贡献或发布，您在软件中拥有的任何知识产权将不大可能构成您公司估值的依据。您的律师可以帮助您更好地理解在专有和开源软件之间如何选择，并对这一重要业务决策提供指导。

法则八：确保您的员工和第三方开发人员遵守这些规则

不管是由于您的员工或第三方承包商造成的开源违规行为，所引起的法律和宣传问题都将砸在您的头上。您可以通过适当的培训和跟踪开源软件来避免这些问题。

法则九：规划未来

初创公司业务模式可以快速变化。SaaS 模式可以快速转变为分布式软件模式。无论您当前的模式是什么，遵守分布式软件的规则将为您转变为分布式软件模式提供更大的灵活性，而无需删除某些开源软件并更改相关功能。

采用这些法则将有助于初创企业利用开源软件的优势，降低您在获取投资或收购时遇到的风险。对您的初创企业感兴趣的第三方想知道您如何应对开源软件问题，确保您做好准备，并能够为他们提供积极和专业的答案。

（题图：Beth Cortez-Neavel on Flickr. Public Domain. Modified by Opensource.com）

作者简介：Heather Meeker 是 O’Melveny & Myers 硅谷办公室的合伙人，为客户提供技术交易和知识产权方面的建议，是国际知名的开源软件许可专家。Heather 于 2016 年获得加州律师协会知识产权先锋奖。 《最佳律师》 （ Best Lawyers ） 将她提名为 2018 年年度 IT 律师。

译者简介：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

系统可以持续运行 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中国 荣誉推出