在每一个程序员、项目管理员、团队领导的一生中，这都会至少发生一次。原来的程序员早已离职去度假了，给你留下了一坨几百万行屎一样的、勉强支撑公司运行的代码和（如果有的话）跟代码驴头不对马嘴的文档。

你的任务：带领团队摆脱这个混乱的局面。

当你的第一反应（逃命）过去之后，你开始去熟悉这个项目。公司的管理层都在关注着你，所以项目只能成功；然而，看了一遍代码之后却发现失败几乎是不可避免。那么该怎么办呢？

幸运（不幸）的是我已经遇到好几次这种情况了，我和我的小伙伴发现将这坨热气腾腾的屎变成一个健康可维护的项目是一个有丰厚利润的业务。下面这些是我们的一些经验：

备份

在开始做任何事情之前备份与之可能相关的所有文件。这样可以确保不会丢失任何可能会在另外一些地方很重要的信息。一旦修改了其中一些文件，你可能花费一天或者更多天都解决不了这个愚蠢的问题。配置数据通常不受版本控制，所以特别容易受到这方面影响，如果定期备份数据时连带着它一起备份了，还是比较幸运的。所以谨慎总比后悔好，复制所有东西到一个绝对安全的地方并不要轻易碰它，除非这些文件是只读模式。

重要的先决条件：必须确保代码能够在生产环境下构建运行并产出

之前我假设环境已经存在，所以完全丢了这一步，但 Hacker News 的众多网友指出了这一点，并且事实证明他们是对的：第一步是确认你知道在生产环境下运行着什么东西，也意味着你需要在你的设备上构建一个跟生产环境上运行的版本每一个字节都一模一样的版本。如果你找不到实现它的办法，一旦你将它投入生产环境，你很可能会遭遇一些预料之外的糟糕事情。确保每一部分都尽力测试，之后在你足够确信它能够很好的运行的时候将它部署生产环境下。无论它运行的怎么样都要做好能够马上切换回旧版本的准备，确保日志记录下了所有情况，以便于接下来不可避免的 “验尸” 。

冻结数据库

直到你修改代码结束之前尽可能冻结你的数据库，在你已经非常熟悉代码库和遗留代码之后再去修改数据库。在这之前过早的修改数据库的话，你可能会碰到大问题，你会失去让新旧代码和数据库一起构建稳固的基础的能力。保持数据库完全不变，就能比较新的逻辑代码和旧的逻辑代码运行的结果，比较的结果应该跟预期的没有差别。

写测试

在你做任何改变之前，尽可能多的写一些端到端测试和集成测试。确保这些测试能够正确的输出，并测试你对旧的代码运行的各种假设（准备好应对一些意外状况）。这些测试有两个重要的作用：其一，它们能够在早期帮助你抛弃一些错误观念，其二，这些测试在你写新代码替换旧代码的时候也有一定防护作用。

要自动化测试，如果你有 CI 的使用经验可以用它，并确保在你提交代码之后 CI 能够快速的完成所有测试。

日志监控

如果旧设备依然可用，那么添加上监控功能。在一个全新的数据库，为每一个你能想到的事件都添加一个简单的计数器，并且根据这些事件的名字添加一个函数增加这些计数器。用一些额外的代码实现一个带有时间戳的事件日志，你就能大概知道发生多少事件会导致另外一些种类的事件。例如：用户打开 APP 、用户关闭 APP 。如果这两个事件导致后端调用的数量维持长时间的不同，这个数量差就是当前打开的 APP 的数量。如果你发现打开 APP 比关闭 APP 多的时候，你就必须要知道是什么原因导致 APP 关闭了（例如崩溃）。你会发现每一个事件都跟其它的一些事件有许多不同种类的联系，通常情况下你应该尽量维持这些固定的联系，除非在系统上有一个明显的错误。你的目标是减少那些错误的事件，尽可能多的在开始的时候通过使用计数器在调用链中降低到指定的级别。（例如：用户支付应该得到相同数量的支付回调）。

这个简单的技巧可以将每一个后端应用变成一个像真实的簿记系统一样，而像一个真正的簿记系统，所有数字必须匹配，如果它们在某个地方对不上就有问题。

随着时间的推移，这个系统在监控健康方面变得非常宝贵，而且它也是使用源码控制修改系统日志的一个好伙伴，你可以使用它确认 BUG 引入到生产环境的时间，以及对多种计数器造成的影响。

我通常保持每 5 分钟（一小时 12 次）记录一次计数器，但如果你的应用生成了更多或者更少的事件，你应该修改这个时间间隔。所有的计数器公用一个数据表，每一个记录都只是简单的一行。

一次只修改一处

不要陷入在提高代码或者平台可用性的同时添加新特性或者是修复 BUG 的陷阱。这会让你头大，因为你现在必须在每一步操作想好要出什么样的结果，而且会让你之前建立的一些测试失效。

修改平台

如果你决定转移你的应用到另外一个平台，最主要的是跟之前保持一模一样。如果你觉得需要，你可以添加更多的文档和测试，但是不要忘记这一点，所有的业务逻辑和相互依赖要跟从前一样保持不变。

修改架构

接下来处理的是改变应用的结构（如果需要）。这一点上，你可以自由的修改高层的代码，通常是降低模块间的横向联系，这样可以降低代码活动期间对终端用户造成的影响范围。如果旧代码很庞杂，那么现在正是让它模块化的时候，将大段代码分解成众多小的部分，不过不要改变量和数据结构的名字。

Hacker News 的 mannykannot 网友指出，修改高层代码并不总是可行，如果你特别不幸的话，你可能为了改变一些架构必须付出沉重的代价。我赞同这一点也应该在这里加上提示，因此这里有一些补充。我想额外补充的是如果你修改高层代码的时候修改了一点点底层代码，那么试着只修改一个文件或者最坏的情况是只修改一个子系统，尽可能限制修改的范围。否则你可能很难调试刚才所做的更改。

底层代码的重构

现在，你应该非常理解每一个模块的作用了，准备做一些真正的工作吧：重构代码以提高其可维护性并且使代码做好添加新功能的准备。这很可能是项目中最消耗时间的部分，记录你所做的任何操作，在你彻底的记录并且理解模块之前不要对它做任何修改。之后你可以自由的修改变量名、函数名以及数据结构以提高代码的清晰度和统一性，然后请做测试（情况允许的话，包括单元测试）。

修复 bug

现在准备做一些用户可见的修改，战斗的第一步是修复很多积累了几年的 bug。像往常一样，首先证实 bug 仍然存在，然后编写测试并修复这个 bug，你的 CI 和端对端测试应该能避免一些由于不太熟悉或者一些额外的事情而犯的错误。

升级数据库

如果你在一个坚实且可维护的代码库上完成所有工作，你就可以选择更改数据库模式的计划，或者使用不同的完全替换数据库。之前完成的步骤能够帮助你更可靠的修改数据库而不会碰到问题，你可以完全的测试新数据库和新代码，而之前写的所有测试可以确保你顺利的迁移。

按着路线图执行

祝贺你脱离的困境并且可以准备添加新功能了。

任何时候都不要尝试彻底重写

彻底重写是那种注定会失败的项目。一方面，你在一个未知的领域开始，所以你甚至不知道构建什么，另一方面，你会把所有的问题都推到新系统马上就要上线的前一天。非常不幸的是，这也是你失败的时候。假设业务逻辑被发现存在问题，你会得到异样的眼光，那时您会突然明白为什么旧系统会用某种奇怪的方式来工作，最终也会意识到能将旧系统放在一起工作的人也不都是白痴。在那之后。如果你真的想破坏公司（和你自己的声誉），那就重写吧，但如果你是聪明人，你会知道彻底重写系统根本不是一个可选的选择。

所以，替代方法：增量迭代工作

要解开这些线团最快方法是，使用你熟悉的代码中任何的元素（它可能是外部的，也可能是内核模块），试着使用旧的上下文去增量改进。如果旧的构建工具已经不能用了，你将必须使用一些技巧（看下面），但至少当你开始做修改的时候，试着尽力保留已知的工作。那样随着代码库的提升你也对代码的作用更加理解。一个典型的代码提交应该最多两三行。

发布！

每一次的修改都发布到生产环境，即使一些修改不是用户可见的。使用最少的步骤也是很重要的，因为当你缺乏对系统的了解时，有时候只有生产环境能够告诉你问题在哪里。如果你只做了一个很小的修改之后出了问题，会有一些好处：

• 很容易弄清楚出了什么问题
• 这是一个改进流程的好位置
• 你应该马上更新文档展示你的新见解

使用代理的好处

如果你做 web 开发那就谢天谢地吧，可以在旧系统和用户之间加一个代理。这样你能很容易的控制每一个网址哪些请求定向到旧系统，哪些请求定向到新系统，从而更轻松更精确的控制运行的内容以及谁能够看到运行系统。如果你的代理足够的聪明，你可以使用它针对个别 URL 把一定比例的流量发送到新系统，直到你满意为止。如果你的集成测试也能连接到这个接口那就更好了。

是的，但这会花费很多时间！

这就取决于你怎样看待它了。的确，在按照以上步骤优化代码时会有一些重复的工作步骤。但是它确实有效，而这里介绍的任何一个步骤都是假设你对系统的了解比现实要多。我需要保持声誉，也真的不喜欢在工作期间有负面的意外。如果运气好的话，公司系统已经出现问题，或者有可能会严重影响到客户。在这样的情况下，我比较喜欢完全控制整个流程得到好的结果，而不是节省两天或者一星期。如果你更多地是牛仔的做事方式，并且你的老板同意可以接受冒更大的风险，那可能试着冒险一下没有错，但是大多数公司宁愿采取稍微慢一点但更确定的胜利之路。

via: https://jacquesmattheij.com/improving-a-legacy-codebase

作者：Jacques Mattheij 译者：aiwhj 校对：JianqinWang, wxy

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

就在之前几篇文章，我开始了“系统管理 101”系列文章，用来记录现今许多初级系统管理员、DevOps 工程师或者“全栈”开发者可能不曾接触过的一些系统管理方面的基本知识。按照我原本的设想，该系列文章已经是完结了的。然而后来 WannaCry 恶意软件出现，并在补丁管理不善的 Windows 主机网络间爆发。我能想象到那些仍然深陷 2000 年代 Linux 与 Windows 争论的读者听到这个消息可能已经面露优越的微笑。

我之所以这么快就决定再次继续“系统管理 101”文章系列，是因为我意识到在补丁管理方面一些 Linux 系统管理员和 Windows 系统管理员没有差别。实话说，在一些方面甚至做的更差（特别是以持续运行时间为自豪）。所以，这篇文章会涉及 Linux 下补丁管理的基础概念，包括良好的补丁管理该是怎样的，你可能会用到的一些相关工具，以及整个补丁安装过程是如何进行的。

什么是补丁管理？

我所说的补丁管理，是指你部署用于升级服务器上软件的系统，不仅仅是把软件更新到最新最好的前沿版本。即使是像 Debian 这样为了“稳定性”持续保持某一特定版本软件的保守派发行版，也会时常发布升级补丁用于修补错误和安全漏洞。

当然，如果你的组织决定自己维护特定软件的版本，要么是因为开发者有最新最好版本的需求，需要派生软件源码并做出修改，要么是因为你喜欢给自己额外的工作量，这时你就会遇到问题。理想情况下，你应该已经配置好你的系统，让它在自动构建和打包定制版本软件时使用其它软件所用的同一套持续集成系统。然而，许多系统管理员仍旧在自己的本地主机上按照维基上的文档（但愿是最新的文档）使用过时的方法打包软件。不论使用哪种方法，你都需要明确你所使用的版本有没有安全缺陷，如果有，那必须确保新补丁安装到你定制版本的软件上了。

良好的补丁管理是怎样的

补丁管理首先要做的是检查软件的升级。首先，对于核心软件，你应该订阅相应 Linux 发行版的安全邮件列表，这样才能第一时间得知软件的安全升级情况。如果你使用的软件有些不是来自发行版的仓库，那么你也必须设法跟踪它们的安全更新。一旦接收到新的安全通知，你必须查阅通知细节，以此明确安全漏洞的严重程度，确定你的系统是否受影响，以及安全补丁的紧急性。

一些组织仍在使用手动方式管理补丁。在这种方式下，当出现一个安全补丁，系统管理员就要凭借记忆，登录到各个服务器上进行检查。在确定了哪些服务器需要升级后，再使用服务器内建的包管理工具从发行版仓库升级这些软件。最后以相同的方式升级剩余的所有服务器。

手动管理补丁的方式存在很多问题。首先，这么做会使补丁安装成为一个苦力活，安装补丁越多就需要越多人力成本，系统管理员就越可能推迟甚至完全忽略它。其次，手动管理方式依赖系统管理员凭借记忆去跟踪他或她所负责的服务器的升级情况。这非常容易导致有些服务器被遗漏而未能及时升级。

补丁管理越快速简便，你就越可能把它做好。你应该构建一个系统，用来快速查询哪些服务器运行着特定的软件，以及这些软件的版本号，而且它最好还能够推送各种升级补丁。就个人而言，我倾向于使用 MCollective 这样的编排工具来完成这个任务，但是红帽提供的 Satellite 以及 Canonical 提供的 Landscape 也可以让你在统一的管理界面上查看服务器的软件版本信息，并且安装补丁。

补丁安装还应该具有容错能力。你应该具备在不下线的情况下为服务安装补丁的能力。这同样适用于需要重启系统的内核补丁。我采用的方法是把我的服务器划分为不同的高可用组，lb1、app1、rabbitmq1 和 db1 在一个组，而lb2、app2、rabbitmq2 和 db2 在另一个组。这样，我就能一次升级一个组，而无须下线服务。

所以，多快才能算快呢？对于少数没有附带服务的软件，你的系统最快应该能够在几分钟到一小时内安装好补丁（例如 bash 的 ShellShock 漏洞）。对于像 OpenSSL 这样需要重启服务的软件，以容错的方式安装补丁并重启服务的过程可能会花费稍多的时间，但这就是编排工具派上用场的时候。我在最近的关于 MCollective 的文章中（查看 2016 年 12 月和 2017 年 1 月的工单）给了几个使用 MCollective 实现补丁管理的例子。你最好能够部署一个系统，以具备容错性的自动化方式简化补丁安装和服务重启的过程。

如果补丁要求重启系统，像内核补丁，那它会花费更多的时间。再次强调，自动化和编排工具能够让这个过程比你想象的还要快。我能够在一到两个小时内在生产环境中以容错方式升级并重启服务器，如果重启之间无须等待集群同步备份，这个过程还能更快。

不幸的是，许多系统管理员仍坚信过时的观点，把持续运行时间（uptime）作为一种骄傲的象征——鉴于紧急内核补丁大约每年一次。对于我来说，这只能说明你没有认真对待系统的安全性！

很多组织仍然使用无法暂时下线的单点故障的服务器，也因为这个原因，它无法升级或者重启。如果你想让系统更加安全，你需要去除过时的包袱，搭建一个至少能在深夜维护时段重启的系统。

基本上，快速便捷的补丁管理也是一个成熟专业的系统管理团队所具备的标志。升级软件是所有系统管理员的必要工作之一，花费时间去让这个过程简洁快速，带来的好处远远不止是系统安全性。例如，它能帮助我们找到架构设计中的单点故障。另外，它还帮助鉴定出环境中过时的系统，给我们替换这些部分提供了动机。最后，当补丁管理做得足够好，它会节省系统管理员的时间，让他们把精力放在真正需要专业知识的地方。

Kyle Rankin 是高级安全与基础设施架构师，其著作包括： Linux Hardening in Hostile Networks，DevOps Troubleshooting 以及 The Official Ubuntu Server Book。同时，他还是 Linux Journal 的专栏作家。

via: https://www.linuxjournal.com/content/sysadmin-101-patch-management

作者：Kyle Rankin 译者：haoqixu 校对：wxy

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

你是否关注过开源技术的发展趋势？ 这里是 10 个预测。

技术一直在变革，诸如 OpenStack、 增强型网页应用 Progressive Web App （PWA）、Rust、R、 认知云 the cognitive cloud 、人工智能（AI），物联网等一些新技术正在颠覆我们对世界的固有认知。以下概述了 2018 年最可能成为主流的开源技术。

1、 OpenStack 认可度持续高涨

OpenStack 本质上是一个云操作平台（系统），它为管理员提供直观友好的控制面板，以便对大量的计算、存储和网络资源进行配置和监管。

目前，很多企业运用 OpenStack 平台搭建和管理云计算系统。得益于其灵活的生态系统、透明度和运行速度，OpenStack 越来越流行。相比其他替代方案，OpenStack 只需更少的花费便能轻松支持任务关键型应用程序。 但是，其复杂的结构以及其对虚拟化、服务器和大量网络资源的严重依赖使得不少企业对使用 OpenStack 心存顾虑。另外，想要用好 OpenStack，好的硬件支持和高水平的员工二者缺一不可。

OpenStack 基金会一直在致力于完善他们的产品。一些功能创新，无论是已经发布的还是尚处于打造阶段，都将解决许多 OpenStack 潜在的问题。随着其结构复杂性降低，OpenStack 将获取更大认可。加之众多大型的软件开发及托管公司以及成千上万会员的支持， OpenStack 在云计算时代前途光明。

2、 PWA 或将大热

PWA，即 增强型网页应用 Progressive Web App ，是对技术、设计和 网络应用程序接口 Web API 的整合，它能够在移动浏览器上提供类似应用的体验。

传统的网站有许多与生俱来的缺点。虽然应用（app）提供了比网站更加个性化、用户参与度更高的体验，但是却要占用大量的系统资源；并且要想使用应用，你还必须提前下载安装。PWA 则扬长避短，它可用浏览器访问、可被引擎搜索检索，并可响应式适应外在环境，为用户提供应用级体验。PWA 也能像应用一样自我更新，总是显示最新的实时信息，并且像网站一样，以极其安全的 HTTPS 模式递交信息。PWA 运行于标准容器中，无须安装，任何人只要输入 URL 即可访问。

现在的移动用户看重便利性和参与度，PWAs 的特性完美契合这一需求，所以 PWA 成为主流是必然趋势。

3、 Rust 成开发者新宠

大多数的编程语言都需在安全和控制二者之间折衷，但 Rust 是一个例外。Rust 使用广泛的编译时检查进行 100% 的控制而不影响程序安全性。上一次 Pwn2Own 竞赛找出了 Firefox C++ 底层实现的许多严重漏洞。如果 Firefox 是用 Rust 编写的，这些漏洞在产品发布之前的编译阶段就会被发现并解决。

Rust 独特的内建单元测试方式使开发者们考虑将其作为首选的开源语言。它是 C 和 Python 等其他编程语言有效的替代方案，Rust 可以在不损失程序可读性的情况下写出安全的代码。总之，Rust 前途光明。

4、 R 用户群在壮大

R) 编程语言，是一个与统计计算和图像呈现相关的 GUN 项目。它提供了大量的统计和图形技术，并且可扩展增强。它是 S) 语言的延续。S 语言早已成为统计方法学的首选工具，R 为数据操作、计算和图形显示提供了开源选择。R 语言的另一个优势是对细节的把控和对细微差别的关注。

和 Rust 一样，R 语言也处于上升期。

5、 广义的 XaaS

XaaS 是 “ 一切皆服务 anything as a service ” 的缩写，是通过网络提供的各种线上服务的总称。XaaS 的外延正在扩大，软件即服务（SaaS）、基础设施即服务（IaaS） 和平台即服务（PaaS）等观念已深入人心，新兴的基于云的服务如网络即服务（NaaS）、存储即服务（SaaS 或 StaaS）、监控即服务（MaaS）以及通信即服务（CaaS）等概念也正在普及。我们正在迈向一个万事万物 “皆为服务” 的世界。

现在，XaaS 的概念已经延伸到实体企业。著名的例子有 Uber 、Lyft 和 Airbnb，前二者利用新科技提供交通服务，后者提供住宿服务。

高速网络和服务器虚拟化使得强大的计算能力成为可能，这加速了 XaaS 的发展，2018 年可能是 “XaaS 年”。XaaS 无与伦比的灵活性、可扩展性将推动 XaaS 进一步发展。

6、 容器技术越来越受欢迎

容器技术，是用标准化方法打包代码的技术，它使得代码能够在任意环境中快速地 “接入并运行”。容器技术让企业可以削减经费、降低实施周期。尽管容器技术在 IT 基础结构改革方面的已经初显潜力，但事实上，运用好容器技术仍然比较复杂。

容器技术仍在发展中，技术复杂性随着各方面的进步在下降。最新的技术让容器使用起来像使用智能手机一样简单、直观，更不用说现在的企业需求：速度和灵活性往往能决定业务成败。

7、 机器学习和人工智能的更广泛应用

机器学习和人工智能 指在没有程序员给出明确的编码指令的情况下，机器具备自主学习并且积累经验自我改进的能力。

随着一些开源技术利用机器学习和人工智能实现尖端服务和应用，这两项技术已经深入人心。

Gartner 预测，2018 年机器学习和人工智能的应用会更广。其他一些领域诸如数据准备、集成、算法选择、学习方法选择、模块制造等随着机器学习的加入将会取得很大进步。

全新的智能开源解决方案将改变人们和系统交互的方式，转变由来已久的工作观念。

• 机器交互，像聊天机器人这样的对话平台，提供“问与答”的体验——用户提出问题，对话平台作出回应，成为人机之间默认的交互界面。
• 无人驾驶和无人机现在已经家喻户晓了，2018 年将会更司空见惯。
• 沉浸式体验的应用不再仅仅局限于视频游戏，在真实的生活场景比如设计、培训和可视化过程中都能看到沉浸式体验的身影。

8、 区块链将成为主流

自比特币应用区块链技术以来，其已经取得了重大进展，并且已广泛应用在金融系统、保密选举、学历验证等领域中。未来几年，区块链会在医疗、制造业、供应链物流、政府服务等领域中大展拳脚。

区块链分布式存储数据信息，这些数据信息依赖于数百万个共享数据库的节点。区块链不被任意单一所有者控制，并且单个损坏的节点不影响其正常运行，区块链的这两个特性让它异常健壮、透明、不可破坏。同时也规避了有人从中篡改数据的风险。区块链强大的先天优势足够支撑其成为将来主流技术。

9、 认知云粉墨登场

认识技术，比如前面所述的机器学习和人工智能，用于为多行业提供简单化和个性化服务。一个典型例子是金融行业的游戏化应用，其为投资者提供了严谨的投资建议，降低投资模块的复杂程度。数字信托平台使得金融机构的身份认证过程较以前精简 80%，提升了合规性，降低了诈骗比率。

认知云技术现在正向云端迁移，借助云，它将更加强大。IBM Watson) 是认知云应用最知名的例子。IBM 的 UIMA 架构是开源的，由 Apache 基金会负责维护。DARPA（美国国防高级研究计划局）的 DeepDive 项目借鉴了 Watson 的机器学习能力，通过不断学习人类行为来增强决策能力。另一个开源平台 OpenCog ，为开发者和数据科学家开发人工智能应用程序提供支撑。

考虑到实现先进的、个性化的用户体验风险较高，这些认知云平台来年时机成熟时才会粉墨登场。

10、 物联网智联万物

物联网（IoT）的核心在于建立小到嵌入式传感器、大至计算机设备的相互连接，让其（“物”）相互之间可以收发数据。毫无疑问，物联网将会是科技界的下一个 “搅局者”，但物联网本身处于一个不断变化的状态。

物联网最广为人知的产品就是 IBM 和三星合力打造的去中心化 P2P 自动遥测系统（ADEPT）。它运用和区块链类似的技术来构建一个去中心化的物联网。没有中央控制设备，“物” 之间通过自主交流来进行升级软件、处理 bug、管理电源等等一系列操作。

开源推动技术创新

数字化颠覆是当今以科技为中心的时代的常态。在技术领域，开放源代码正在逐渐普及，其在 2018 将年成为大多数技术创新的驱动力。

此榜单对开源技术趋势的预测有遗漏？在评论区告诉我们吧！

（题图：Mitch Bennett. Opensource.com 修改）

关于作者

Sreejith Omanakuttan - 自 2000 年开始编程，2007年开始从事专业工作。目前在 Fingent 领导开源团队，工作内容涵盖不同的技术层面，从“无聊的工作”（？）到前沿科技。有一套 “构建—修复—推倒重来” 工作哲学。在领英上关注我： https://www.linkedin.com/in/futuregeek/

via: https://opensource.com/article/17/11/10-open-source-technology-trends-2018

作者：Sreejith Omanakuttan 译者：wangy325 校对：wxy

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

当你真正掌握了整体化的工程设计思维时，你就会发现高屋建瓴的工程设计已经远远超越了技术优化的层面。我们的每一件创造都催生于人类活动的大背景下，被这种人类活动赋予了广泛的经济学意义、社会学意义，甚至于具有了奥地利经济学家所称的“ 人类行为学意义 praxeology ”。而这种人类行为学意义则是明确的人类行为所能达到的最高层次。

对我来说这并不只是一种抽象的理论。当我在撰写关于开源项目开发的文章时，文章的内容正是关于人类行为学的 —— 这些文章并不涉及哪个具体的软件技术或者话题，而是在讨论科技所服务的人类行为。从人类行为学角度对科技进行更深入的理解，可以帮助我们重塑科技，并且提升我们的生产力和成就感。这种提升并不总是因为我们有了更新的工具，而更多的是因为我们改变了使用现有工具的思路，提升了我们对这些工具的驾驭能力。

在这个思路之下，我的随笔文章的第三篇中谈到了 C 语言的衰退和正在到来的巨大改变，而我们也确实能够感受到系统级别编程的新时代的到来。在这里，我会把我的统观见解总结成更具体的、更实用的对计算机语言设计的分析。例如总结出为什么一些语言会成功，另一些语言会失败。

在我最近的一篇文章中，我写道：所有计算机语言的设计都是对机器资源和程序员人力成本的相对权衡的结果；是对一种相对价值主张的体现。而这些设计思路都是在硬件算力成本不断下降，程序员人力成本相对稳定且可能不减反增的背景下产生的。我还强调了语言设计在实现了一些原有的权衡方案之后，其未来的转化和演变成本在这种语言的成败中所要扮演的一些额外角色。在文中我也阐述了编程语言设计者是如何为当前和可见的未来寻找新的最优设计方案的。

现在我要集中讲解一下我在上面段落里最后提到的那个概念，即语言设计工程师们其实可以在多个方面来改进和提高现阶段编程语言的设计水准。比如输入系统的优化，GC (垃圾回收机制) 和手动内存分配的权衡，命令导向、函数导向和面向对象导向的混合和权衡。但是站在人类行为学的角度去考量，我认为设计师们一定会做出更简单的设计权衡，即针对近景问题还是针对远景问题来优化一种语言的设计。

所谓的“远”、“近”之分，是指随着硬件成本的逐渐降低，软件复杂程度的上升和由现有语言向其他语言转化的成本的增加，根据这些因素的变化曲线所做出的判断。近景问题是编程人员眼下看到的问题，远景问题则是指可预见的，但未必会很快到来的一系列情况。针对近景问题的解决方案可以被很快部署下去，且能够在短期内非常有效，但随着情况的变化和时间的推移，这种方案可能很快就不适用了。而远景的解决方案可能因为其自身的复杂和超前性而夭折，或是因其代价过高无法被接受和采纳。

在计算机刚刚面世的时候， FORTRAN 就是一个近景设计方案， LISP 语言的设计则是针对远景问题；汇编语言多是近景设计方案，很好的阐明了这类设计很适用于非通用语言，同样的例子还包括 ROFF 标记语言。PHP 和 Javascript 则是我们后来看到的采用了近景设计思维的语言。那么后来的远景设计方案有哪些例子呢？ Oberon、Ocaml、ML、XML-Docbook 都是它的例子。学术研究中设计出的语言多倾向于远景设计，因为在学术研究领域，原创性以及大胆的假设与想法是很重要的。这和学术研究的动机以及其奖励机制很有关系（值得注意的是，在学术研究中，倾向于远景设计的本源动机并非出于技术方面的原因，而是出自于人类行为，即标新立异才能在学术上有成绩）。学术研究中设计出的编程语言是注定会失败的；因为学术研究的产物常常有高昂的转入成本，无人问津的设计。这类语言也因为在社区中不够流行而不能得到主流的采纳，具有孤立性，且常常被搁置成为半成品。（如上所述的问题正是对 LISP 历史的精辟总结，而且我是以一个对 LISP 语言有深入研究，并深深喜爱它的使用者的身份来评价 LISP 的）。

一些近景设计的失败案例则更加惨不忍睹。对这些案例来说，我们能够期待的最好的结果就是这种语言可以消亡的相对体面一些，被一种新的语言设计取而代之。如果这些近景设计导向的语言没有死亡而是一直被沿用下去（通常是因为转化成本过高），那么我们则会看到不断有新的特性和功能在这些语言原来的基础之上堆积起来，以保持它们的可用性和有效性。直到这种堆积把这些语言变得越来越复杂，变的危若累卵且不可理喻。是的，我说的就是 C++ 。当然， 还有 Javascript。Perl 也不例外，尽管它的设计者 Larry Walls 有不错的设计品味，避免了很多问题，让这种语言得以存活了很多年。但也正是因为 Larry Walls 的好品味，让他在最终对 Perl 的固有问题忍无可忍之后发布了全新的 Perl 6。

从这种角度去思考程序语言，我们则可以把语言设计中需要侧重的目标重新归纳为两部分: （1）以时间的远近为轴，在远景设计和近景设计之间选取一个符合预期的最佳平衡点；（2）降低由一种或多种语言转化为这种新语言的转入成本，这样就可以更好地吸纳其它语言的用户群。接下来我会讲讲 C 语言是怎样占领全世界的。

在整个计算机发展史中，没有谁能比 C 语言在选择远景和近景设计的平衡点的时候做的更完美。事实胜于雄辩，作为一种实用的主流语言，C 语言有着很长的寿命，它目睹了无数个竞争者的兴衰，但它的地位仍旧不可取代。从淘汰它的第一个竞争者到现在已经过了 35 年，但看起来 C 语言的终结仍旧不会到来。

当然，你可以把 C 语言的持久存在归功于文化惰性，但那是对“文化惰性”这个词的曲解，C 语言一直得以延续的真正原因是因为目前还没有人能提供另一种足够好的语言，可以抵消取代 C 语言所需要的转化成本！

相反的，C 语言低廉的 内向转化成本 inward transition costs （转入成本）并未引起大家应有的重视，C 语言几乎是唯一的一个极其多样和强大的编程工具，以至于从它漫长统治时期的初期开始，它就可以适用于多种语言如 FORTRAN、Pascal、汇编语言和 LISP 的编程习惯。在一九八零年代我就注意到，我常常可以根据一个 C 语言新人的编码风格判断出他之前在使用什么语言，这也从另一方面证明了 C 语言可以轻松的被其它语言的使用者所接受，并吸引他们加入进来。

C++ 语言同样胜在它低廉的转化成本。很快，大部分新兴的语言为了降低自身的转入成本，都纷纷参考了 C 语言的语法。值得注意的是这给未来的语言设计带来了一种影响：即新语言的设计都在尽可能的向 C 的语法靠拢，以便这种新语言可以有很低的内向转化成本（转入成本），使其他语言的使用者可以欣然接受并使用这种新语言。

另一种降低转入成本的方法则是把一种编程语言设计的极其简单并容易入手，让那些即使是没有编程经验的人都可以轻松学会。但做到这一点并非易事。我认为只有一种语言 —— Python —— 成功的做到了这一点，即通过易用的设计来降低内向转化成本。对这种程序语言的设计思路我在这里一带而过，因为我并不认为一种系统级别的语言可以被设计的像 Python 一样傻瓜易用，当然我很希望我的这个论断是错的。

而今我们已经来到 2017 年末尾，你一定猜测我接下来会向那些 Go 语言的鼓吹者一样对 Go 大加赞赏一番，然后激怒那些对 Go 不厌其烦的人群。但其实我的观点恰恰相反，我认为 Go 本身很有可能在许多方面遭遇失败。Go 团队太过固执独断，即使几乎整个用户群体都认为 Go 需要做出某些方面的改变了，Go 团队也无动于衷，这是个大问题。目前，Go 语言的 GC 延迟问题以及用以平衡延迟而牺牲掉的吞吐量，都可能会严重制约这种语言的适用范围。

即便如此，在 Go 的设计中还是蕴含了一个让我颇为认同的远大战略目标。想要理解这个目标，我们需要回想一下如果想要取代 C 语言，要面临的短期问题是什么。正如我之前提到的，这个问题就是，随着软件工程项目和系统的不断扩张，故障率也在持续上升，这其中内存管理方面的故障尤其多，而内存管理故障一直是导致系统崩溃和安全漏洞的主要元凶。

我们现在已经认清，一种语言要想取代 C 语言，它的设计就必须遵循两个十分重要准则：（1）解决内存管理问题；（2）降低由 C 语言向本语言转化时所需的转入成本。从人类行为学的角度来纵观编程语言的历史，我们不难发现，作为 C 语言的准替代者，如果不能有效解决转入成本过高这个问题，那设计者所做的其它部分做得再好都不算数。相反的，如果一种 C 的替代语言把转入成本过高这个问题解决地很好，即使它在其他部分做的不是最好的，人们也不会对这种语言吹毛求疵。

而 Go 正是遵循了上述两点设计思路，虽然这个思路并不是一种完美无瑕的设计理论，也有其局限性。比如，目前 GC 延迟的问题就限制了 Go 的推广。但是 Go 目前选择了照搬 Unix 下 C 语言的传染战略，把其自身设计成一种易于转入，便于传播的语言。这样它的广泛和快速的传播就会使其迅速占领市场，从而打败那些针对远景设计的看起来更好的语言。

没错，我所指的这个远景设计方案就是 Rust。而 Rust 的自身定位也正是一种远景和长期的 C 语言替代方案。我曾经在之前的一些文章中解释过我为什么认为 Rust 还没有做好和 Go 展开竞争的准备。TIBOE 和 PYPL 的语言评价指数榜也很好的证明了我的对于 Rust 的这个观点。在 TIBOE 上 Rust 从来没有进过前 20 名。而在 TIBOE 和 PYPL 两个指数榜上， Rust 都要比 Go 的表现差很多。

五年后的 Rust 会发展的怎样还未可知。但如果 Rust 社区的开发人员对这种语言的设计抱着认真投入的态度，并愿意倾听，那么我建议他们要特别重视转入成本的问题。以我个人经历来说，目前由 C 语言转入 Rust 语言的壁垒很高，使人望而却步。如果 Corrode 之类的 Code-lifting 工具只是把 C 语言映射为不安全的 Rust 语言，那么 Corrode 这类工具也是不能解决这种转入壁垒的。或者如果有更简单的方法能够自动注释代码的所有权或生命周期，那么编译器就能把 C 代码直接映射到 Rust，人们也不再需要 Corrode 这一类工具了。目前我还不知道这个问题要如何解决，但我觉得 Rust 社区最好能够找到一种解决方案来代替 Corrode 和其同类工具。

在最后我想强调一下，Ken Thompson 曾经有过语言设计的辉煌历史。他设计的一些语言虽然看起来只是为了解决近景问题，实际上却具有很高的质量和开放程度，让这些语言同样非常适合远景问题，非常易于被提高和拓展。当然 Unix 也是这样的， 这让我不禁暗自揣测，那些我认为的 Go 语言中乍看上去不利于其远景发展的一些令人担忧烦扰的设计（例如缺乏泛型）也许并没有我想象的那样糟糕。如果确如我所认为的那样，即这些设计会影响 Go 的远景发展，那么恐怕我真的是比 Ken 还要聪明有远见了。但是我并不认为我有那么高明。Go 的前途我们还是只能拭目以待。

via: http://esr.ibiblio.org/?p=7745

作者：Eric Raymond 译者：Valoniakim，yunfengHe 校对：yunfengHe，wxy

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

当上世纪九十年代互联网开始被广泛使用的时候，其大部分的通讯只使用几个协议：IPv4 协议路由这些数据包，TCP 协议转发这些包到连接上，SSL（及后来的 TLS）协议加密连接，DNS 协议命名那些所要连接的主机，而 HTTP 协议是最常用的应用程序协议。

多年以来，这些核心的互联网协议的变化几乎是微乎其微的；HTTP 增加了几个新的报文头和请求方式，TLS 缓慢地进行了一点小修改，TCP 调整了拥塞控制，而 DNS 引入了像 DNSSEC 这样的特性。这些协议看起来很长时间都一成不变（除了已经引起网络运营商们的大量关注的 IPv6）。

因此，希望了解（甚至有时控制）互联网的网络运营商、供应商和决策者对这些协议采用的做法是基于其原有工作方式 —— 无论是打算调试问题，提高服务质量，或施加政策。

现在，核心互联网协议的重要改变已经开始了。虽然它们意图与互联网大部分兼容（因为，如果不兼容的话，它们不会被采纳），但是它们可能会破坏那些在协议中没有规定的地方，或者根本就假设那些地方不存在变化。

为什么我们需要去改变互联网

有大量的因素推动这些变化。

首先，核心互联网协议的局限性越来越明显，尤其是考虑到性能的时候。由于在应用和传输协议方面的结构性问题，网络没有得到高效使用，导致终端用户认为性能不能满足要求（特别是，网络延迟）。

这就意味着人们有强烈的动机来演进或者替换这些协议，因为有 大量的经验表明，即便是很小的性能改善也会产生影响。

其次，演进互联网协议的能力 —— 无论在任何层面上 —— 会随着时间的推移变得更加困难，这主要是因为上面所讨论的对网络的非预期使用。例如，尝试去压缩响应的 HTTP 代理服务器使得部署新的压缩技术更困难；中间设备中的 TCP 优化使得部署对 TCP 的改进越来越困难。

最后，我们正处在一个越来越多地使用加密技术的互联网变化当中，首次激起这种改变的事件是，2015 年 Edward Snowden 的披露事件（LCTT 译注：指的是美国中情局雇员斯诺登的事件）。那是一个单独讨论的话题，但是与之相关的是，加密技术是最好的工具之一，我们必须确保协议能够进化。

让我们来看一下都发生了什么，接下来会出现什么，它对网络有哪些影响，和它对网络协议的设计有哪些影响。

HTTP/2

HTTP/2（基于 Google 的 SPDY） 是第一个重大变化 —— 它在 2015 年被标准化。它将多个请求复用到一个 TCP 连接上，从而避免了客户端排队请求，而不会互相阻塞。它现在已经被广泛部署，并且被所有的主流浏览器和 web 服务器支持。

从网络的角度来看，HTTP/2 带来了一些显著变化。首先，这是一个二进制协议，因此，任何假定它是 HTTP/1.1 的设备都会出现问题。

这种破坏性问题是导致 HTTP/2 中另一个重大变化的主要原因之一：它实际上需要加密。这种改变的好处是避免了来自伪装的 HTTP/1.1 的中间人攻击，或者一些更细微的事情，比如 strip headers 或者阻止新的协议扩展 —— 这两种情况都在工程师对协议的开发中出现过，导致了很明显的支持问题。

当它被加密时，HTTP/2 请求也要求使用 TLS/1.2，并且将一些已经被证明是不安全的算法套件列入黑名单 —— 其效果只允许使用 短暂密钥 ephemeral keys 。关于潜在的影响可以去看 TLS 1.3 的相关章节。

最终，HTTP/2 允许多个主机的请求被 合并到一个连接上，通过减少页面加载所使用的连接（从而减少拥塞控制的场景）数量来提升性能。

例如，你可以对 www.example.com 建立一个连接，也可以将这个连接用于对 images.example.com 的请求。而未来的协议扩展也允许将其它的主机添加到连接上，即便它们没有被列在最初用于它们的 TLS 证书中。因此，假设连接上的通讯被限制于它初始化时的目的并不适用。

值得注意的是，尽管存在这些变化，HTTP/2 并没有出现明显的互操作性问题或者来自网络的冲突。

TLS 1.3

TLS 1.3 刚刚通过了标准化的最后流程，并且已经被一些实现所支持。

不要被它只增加了版本号的名字所欺骗；它实际上是一个新的 TLS 版本，全新打造的 “握手”机制允许应用程序数据从头开始流动（经常被称为 ‘0RTT’）。新的设计依赖于短暂密钥交换，从而排除了静态密钥。

这引起了一些网络运营商和供应商的担心 —— 尤其是那些需要清晰地知道那些连接内部发生了什么的人。

例如，假设一个对可视性有监管要求的银行数据中心，通过在网络中嗅探通讯包并且使用他们的服务器上的静态密钥解密它，它们可以记录合法通讯和识别有害通讯，无论是来自外部的攻击，还是员工从内部去泄露数据。

TLS 1.3 并不支持那些窃听通讯的特定技术，因为那也是 一种针对短暂密钥防范的攻击形式。然而，因为他们有使用更现代化的加密协议和监视他们的网络的监管要求，这些使网络运营商处境很尴尬。

关于是否规定要求静态密钥、替代方式是否有效、并且为了相对较少的网络环境而减弱整个互联网的安全是否是一个正确的解决方案有很多的争论。确实，仍然有可能对使用 TLS 1.3 的通讯进行解密，但是，你需要去访问一个短暂密钥才能做到，并且，按照设计，它们不可能长时间存在。

在这一点上，TLS 1.3 看起来不会去改变以适应这些网络，但是，关于去创建另外一种协议有一些传言，这种协议允许第三方去偷窥通讯内容，或者做更多的事情。这件事是否会得到推动还有待观察。

QUIC

在 HTTP/2 工作中，可以很明显地看到 TCP 有相似的低效率。因为 TCP 是一个按顺序发送的协议，一个数据包的丢失可能阻止其后面缓存区中的数据包被发送到应用程序。对于一个多路复用协议来说，这对性能有很大的影响。

QUIC 尝试去解决这种影响而在 UDP 之上重构了 TCP 语义（以及 HTTP/2 流模型的一部分）。像 HTTP/2 一样，它始于 Google 的一项成果，并且现在已经被 IETF 接纳作为一个 HTTP-over-UDP 的初始用例，其目标是在 2018 年底成为一个标准。然而，因为 Google 已经在 Chrome 浏览器及其网站上部署了 QUIC，它已经占有了超过 7% 的互联网通讯份额。

• 阅读 关于 QUIC 的答疑

除了大量的通讯从 TCP 到 UDP 的转变（以及隐含的可能的网络调整）之外，Google QUIC（gQUIC）和 IETF QUIC（iQUIC）都要求全程加密；并没有非加密的 QUIC。

iQUIC 使用 TLS 1.3 来为会话建立密钥，然后使用它去加密每个数据包。然而，由于它是基于 UDP 的，许多 TCP 中公开的会话信息和元数据在 QUIC 中被加密了。

事实上，iQUIC 当前的 ‘短报文头’ 被用于除了握手外的所有包，仅公开一个包编号、一个可选的连接标识符和一个状态字节，像加密密钥轮换计划和包字节（它最终也可能被加密）。

其它的所有东西都被加密 —— 包括 ACK，以提高 通讯分析 攻击的门槛。

然而，这意味着通过观察连接来被动估算 RTT 和包丢失率将不再变得可行；因为没有足够多的信息。在一些运营商中，由于缺乏可观测性，导致了大量的担忧，它们认为像这样的被动测量对于他们调试和了解它们的网络是至关重要的。

为满足这一需求，它们有一个提议是 ‘Spin Bit’ — 这是在报文头中的一个回程翻转的位，因此，可能通过观察它来估算 RTT。因为，它从应用程序的状态中解耦的，它的出现并不会泄露关于终端的任何信息，也无法实现对网络位置的粗略估计。

DOH

即将发生的变化是 DOH — DNS over HTTP。大量的研究表明，对网络实施政策干预的一个常用手段是通过 DNS 实现的（无论是代表网络运营商或者一个更大的权力机构）。

使用加密去规避这种控制已经 讨论了一段时间了，但是，它有一个不利条件（至少从某些立场来看）— 它可能与其它通讯区别对待；例如，通过它的端口号被阻止访问。

DOH 将 DNS 通讯搭载在已经建立的 HTTP 连接上，因此，消除了任何的鉴别器。希望阻止访问该 DNS 解析器的网络只能通过阻止对该网站的访问来实现。

例如，如果 Google 在 www.google.com 上部署了它的 基于 DOH 的公共 DNS 服务，并且一个用户配置了它的浏览器去使用它，一个希望（或被要求的）被停止访问该服务的网络，将必须阻止对 Google 的全部访问（向他们提供的服务致敬！）（LCTT 译注：他们做到了）。

DOH 才刚刚开始，但它已经引起很多人的兴趣，并有了一些部署的传闻。通过使用 DNS 来实施政策影响的网络（和政府机构）如何反应还有待观察。

阅读 IETF 100, Singapore: DNS over HTTP (DOH!)

僵化和润滑

让我们返回到协议变化的动机，有一个主题贯穿了这项工作，协议设计者们遇到的越来越多的问题是网络对流量的使用做了假设。

例如，TLS 1.3 有一些临门一脚的问题是中间设备假设它是旧版本的协议。gQUIC 将几个对 UDP 通讯进行限流的网络列入了黑名单，因为，那些网络认为 UDP 通讯是有害的或者是低优先级的。

当一个协议因为已有的部署而 “冻结” 它的可扩展点，从而导致不能再进化，我们称它为 已经僵化了 。TCP 协议自身就是一个严重僵化的例子，因此，太多的中间设备在 TCP 协议上做了太多的事情，比如阻止了带有无法识别的 TCP 选项的数据包，或者，“优化”了拥塞控制。

防止僵化是有必要的，确保协议可以进化以满足未来互联网的需要；否则，它将成为一个“公共灾难”，一些个别网络的行为 —— 虽然在那里工作的很好 —— 但将影响整个互联网的健康发展。

有很多的方式去防止僵化；如果被讨论的数据是加密的，它并不能被除了持有密钥的人之外任何一方所访问，阻止了干扰。如果扩展点是未加密的，但是通常以一种可以明显中断应用程序的方法使用（例如，HTTP 报头），它不太可能受到干扰。

协议设计者不能使用加密的扩展点不经常使用的情况下，人为地利用扩展点——我们称之为 润滑 它。

例如，QUIC 鼓励终端在 版本协商 中使用一系列的诱饵值，来避免假设它的实现永远不变化（就像在 TLS 实现中经常遇到的导致重大问题的情况）。

网络和用户

除了避免僵化的愿望外，这些变化也反映出了网络和它们的用户之间关系的进化。很长时间以来，人们总是假设网络总是很仁慈好善的 —— 或者至少是公正的 —— 但这种情况是不存在的，不仅是 无孔不入的监视，也有像 Firesheep 的攻击。

因此，当那些网络想去访问一些流经它们的网络的用户数据时，互联网用户的整体需求和那些网络之间的关系日益紧张。尤其受影响的是那些希望去对它们的用户实施政策干预的网络；例如，企业网络。

在一些情况中，他们可以通过在它们的用户机器上安装软件（或一个 CA 证书，或者一个浏览器扩展）来达到他们的目的。然而，在网络不拥有或无法访问计算机的情况下，这并不容易；例如，BYOD 已经很常用，并且物联网设备几乎没有合适的控制接口。

因此，在 IETF 中围绕协议开发的许多讨论，触及了企业和其它的 “叶子” 网络有时相互竞争的需求，以及互联网整体的好处。

参与

为了让互联网在以后工作的更好，它需要为终端用户提供价值、避免僵化、让网络有序运行。现在正在发生的变化需要满足所有的三个目标，但是，人们需要网络运营商更多的投入。

如果这些变化影响你的网络 —— 或者没有影响 —— 请在下面留下评论。更好地可以通过参加会议、加入邮件列表、或者对草案提供反馈来参与 IETF 的工作。

感谢 Martin Thomson 和 Brian Trammell 的评论。

本文作者 Mark Nottingham 是互联网架构委员会的成员和 IETF 的 HTTP 和 QUIC 工作组的联席主席。

via: https://blog.apnic.net/2017/12/12/internet-protocols-changing/

作者：Mark Nottingham 译者：qhwdw 校对：wxy

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

“实现高速缓存会花费 30 个小时，你有额外的 30 个小时吗？ 不，你没有。我实际上并不知道它会花多少时间，可能它会花五分钟，你有五分钟吗？不，你还是没有。为什么？因为我在撒谎。它会消耗远超五分钟的时间。这一切把问题简单化的假设都只不过是程序员单方面的乐观主义。”

— 出自 Owen Astrachan 教授于 2004 年 2 月 23 日在 CPS 108 上的讲座

指责开源软件总是离奇难用已经不是一个新论点了；这样的论点之前就被很多比我更为雄辩的人提及过，甚至是出自一些人非常推崇开源软件的人士口中。那么为什么我要在这里老调重弹呢？

在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为 编写代码实现和一个跟 StackOverflow 一样的系统可以简单到爆，并自信的 声称他们可以在 7 月 4 号的周末就写出一版和 StackOverflow 原版一模一样的程序，以此来证明这一切是多么容易。另一些人则插话说，现有的那些仿制产品 就已经是一个很好的例证了。

秉承着自由讨论的精神，我们来假设一个场景。你在思考了一阵之后认为你可以用 ASP.NET MVC 来编写一套你自己的 StackOverflow 。我呢，在被一块儿摇晃着的怀表催眠之后，脑袋又挨了别人一顿棒槌，然后像个二哈一样一页一页的把 StackOverflow 的源码递给你，让你照原样重新拿键盘逐字逐句的在你的环境下把那些代码再敲一遍，做成你的 StackOverflow。假设你可以像我一样打字飞快，一分钟能敲 100 个词 (也就是大约每秒敲八个字母)，但是却可以牛叉到我无法企及的打字零错误率。从 StackOverflow 的大小共计 2.3MB 的源码来估计（包括 .CS、 .SQL、 .CSS、 .JS 和 .aspx 文件），就单单是照着源代码这么飞速敲一遍而且一气呵成中间一个字母都不错，你也要差不多用掉至少 80 个小时的时间。

或者你打算从零开始编码实现你自己的 StackOverflow，虽然我知道你肯定是不会那样做的。我们假设你从设计程序，到敲代码，再到最终完成调试只需要区区十倍于抄袭 StackOverflow 源代码的时间。即使在这样的假设条件下，你也要耗费几周的时间昼夜不停得狂写代码。不知道你是否愿意，但是至少我可以欣然承认，如果只给我照抄 StackOverflow 源代码用时的十倍时间来让我自己写 StackOverflow，我可是打死也做不到。

好的，我知道你在听到这些假设的时候已经开始觉得泄气了。你在想，如果不是全部实现，而只是实现 StackOverflow 大部分 的功能呢？这总归会容易很多了吧。

好的，问题是什么是 “大部分” 功能？如果只去实现提问和回答问题的功能？这个部分应该很简单吧。其实不然，因为实现问和答的功能还要求你必须做出一个对问题及其答案的投票系统，来显示大家对某个答案是赞同还是反对。因为只有这样你才能保证提问者可以得到这个问题的唯一的可信答案。当然，你还不能让人们赞同或者反对他们自己给出的答案，所以你还要去实现这种禁止自投自票的机制。除此之外，你需要去确保用户在一定的时间内不能赞同或反对其他用户太多次，以此来防止有人用机器人程序作弊乱投票。你很可能还需要去实现一个垃圾评论过滤器，即使这个过滤器很基础很简陋，你也要考虑如何去设计它。而且你恐怕还需要去支持用户图标（头像）的功能。并且你将不得不寻找一个自己真正信任的并且与 Markdown 结合很好的干净的 HTML 库（当然，假设你确实想要复用 StackOverflow 的 那个超棒的编辑器 ）。你还需要为所有控件购买或者设计一些小图标、小部件，此外你至少需要实现一个基本的管理界面，以便那些喜欢捣鼓的用户可以调整和改动他们的个性化设置。并且你需要实现类似于 Karma 的声望累积系统，以便用户可以随着不断地使用来稳步提升他们的话语权和解锁更多的功能以及可操作性。

但是如果你实现了以上所有功能，可以说你就已经把要做的都做完了。

除非……除非你还要做全文检索功能。尤其是在“边问边搜”（动态检索）的特性中，支持全文检索是必不可少的。此外，录入和显示用户的基本信息，实现对问题答案的评论功能，以及实现一个显示热点提问的页面，以及热点问题和帖子随着时间推移沉下去的这些功能，都将是不可或缺的。另外你肯定还需要去实现回答奖励系统，并支持每个用户用多个不同的 OpenID 账户去登录，然后将这些相关的登录事件通过邮件发送出去来通知用户，并添加一个标签或徽章系统，接着允许管理员通过一个不错的图形界面来配置这些标签和 徽章 Badge 。你需要去显示用户的 Karma 历史，以及他们的历史点赞和差评。而且整个页面还需要很流畅的展开和拉伸，因为这个系统的页面随时都可能被 Slashdot、Reddit 或是 StackOverflow 这些动作影响到。

在这之后！你会以为你基本已经大功告成了！

……为了产品的完整性，在上面所述的工作都完成之后，你又奋不顾身的去实现了升级功能，界面语言的国际化，Karma 值上限，以及让网站更专业的 CSS 设计、AJAX，还有那些看起来理所当然做起来却让人吐血的功能和特性。如果你不是真的动手来尝试做一个和 StackOverflow 一模一样的系统，你肯定不会意识到在整个程序设计实施的过程中，你会踩到无数的鬼才会知道的大坑。

那么请你告诉我：如果你要做一个让人满意的类似产品出来，上述的哪一个功能是你可以省略掉的呢？哪些是“大部分”网站都具备的功能，哪些又不是呢？

正因为这些很容易被忽视的问题，开发者才会以为做一个 StackOverflow 的仿制版产品会很简单。也同样是因为这些被忽视了的因素，开源软件才一直让人用起来很痛苦。很多软件开发人员在看到 StackOverflow 的时候，他们并不能察觉到 StackOverflow 产品的全貌。他们会简单的把 Stackoverflow 的实现抽象成下面一段逻辑和代码:

create table QUESTION (ID identity primary key,
                                             TITLE varchar(255), --- 为什么我知道你认为是 255
                                             BODY text,
                                             UPVOTES integer not null default 0,
                                             DOWNVOTES integer not null default 0,
                                             USER integer references USER(ID));
create table RESPONSE (ID identity primary key,
                                             BODY text,
                                             UPVOTES integer not null default 0,
                                             DOWNVOTES integer not null default 0,
                                             QUESTION integer references QUESTION(ID))

如果你让这些开发者去实现 StackOverflow，进入他脑海中的就是上面的两个 SQL 表和一个用以呈现表格数据的 HTML 文件。他们甚至会忽略数据的格式问题，进而单纯的以为他们可以在一个周末的时间里就把 StackOverflow 做出来。一些稍微老练的开发者可能会意识到他们还要去实现登录和注销功能、评论功能、投票系统，但是仍然会自信的认为这不过也就是利用一个周末就能完成了；因为这些功能也不过意味着在后端多了几张 SQL 表和 HTML 文件。如果借助于 Django 之类的构架和工具，他们甚至可以直接拿来主义地不花一分钱就实现用户登录和评论的功能。

但这种简单的实现却远远不能体现出 StackOverflow 的精髓。无论你对 StackOverflow 的感觉如何，大多数使用者似乎都同意 StackOverflow 的用户体验从头到尾都很流畅。使用 StackOverflow 的过程就是在跟一个精心打磨过的产品在愉快地交互。即使我没有深入了解过 StackOverflow ，我也能猜测出这个产品的成功和它的数据库的 Schema 没有多大关系 —— 实际上在有幸研读过 StackOverflow 的源码之后，我得以印证了自己的想法，StackOverflow 的成功确实和它的数据库设计关系甚小。真正让它成为一个极其易用的网站的原因，是它背后大量的精雕细琢的设计和实施。多数的开发人员在谈及仿制和克隆一款产品的难度时，真的很少会去考虑到产品背后的打磨和雕琢工作，因为他们认为这些打磨和雕琢都是偶然的，甚至是无足轻重的。

这就是为什么用开源工具去克隆和山寨 StackOverflow 其实是很容易失败的。即使这些开源开发者只是想去实现 StackOverflow 的主要的“规范和标准特性”，而非全面的高级特性，他们也会在实现的过程中遭遇种种关键和核心的问题，让他们阴沟翻船，半途而废。拿徽章功能来说，如果你要针对普通终端用户来设计徽章， 则要么需要实现一个用户可用来个性化设置徽章的 GUI，要么则取巧的设计出一个比较通用的徽章，供所有的安装版本来使用。而开源设计的实际情况是，开发者会有很多的抱怨和牢骚，认为给徽章这种东西设计一个功能全面的 GUI 是根本不可能的。而且他们会固执地把任何标准徽章的提案踢回去，踢出第一宇宙速度，击穿地壳甩到地球的另一端。最终这些开发者还是会搞出一个类似于 Roundup 的 bug tracker 程序都在使用的流程和方案：即实现一个通用的机制，提供以 Python 或 PHP 为基础的一些系统 API， 以便那些可以自如使用 Python 或 PHP 的人可以轻松的通过这些编程接口来定制化他们自己的徽章。而且老实说，PHP 和 Python 可是比任何可能的 GUI 接口都要好用和强大得多，为什么还要考虑 GUI 的方案呢？（出自开源开发者的想法）

同样的，开源开发者会认为那些系统设置和管理员界面也一样可以省略掉。在他们看来，假如你是一个管理员，有 SQL 服务器的权限，那么你就理所当然的具备那些系统管理员该有的知识和技能。那么你其实可以使用 Djang-admin 或者任何类似的工具来轻松的对 StackOverflow 做很多设置和改造工作。毕竟如果你是一个 mods （懂如何 mod 的人）那么你肯定知道网站是怎么工作的，懂得如何利用专业工具去设置和改造一个网站。对啊！这不就得了！ 毋庸置疑，在开源开发者重做他们自己的 StackOverflow 的时候，他们也不会把任何 StackOverflow 在接口上面的失败设计纠正过来。即使是原版 StackOverflow 里面最愚蠢最失败的那个设计（即要求用户必须拥有一个 OpenID 并知道如何使用它）在某个将来最终被 StackOverflow 删除和修正掉了， 我相信正在复制 StackOverflow 模式的那些开源克隆产品也还是会不假思索的把这个 OpenID 的功能仿制出来。这就好比是 GNOME 和 KDE 多年以来一直在做的事情，他们并没有把精力放在如何在设计之初就避免 Windows 的那些显而易见的毛病和问题，相反的却是在亦步亦趋的重复着 Windows 的设计，想办法用开源的方式做出一个比拟 Windows 功能的系统。

开发者可能不会关心一个应用的上述设计细节，但是终端用户一定会。尤其是当他们在尝试去选择要使用哪个应用的时候，这些终端用户更会重视这些接口设计是否易用。就好像一家好的软件公司希望通过确保其产品在出货之前就有一流的质量，以降低售后维护支持的成本一样，懂行的消费者也会在他们购买这些产品之前就确保产品好用，以防在使用的时候不知所措，然后无奈的打电话给售后来解决问题。开源产品就失败在这里，而且相当之失败。一般来讲，付费软件则在这方面做得好很多。

这不是说开源软件没有自己的立足之地，这个博客就运行在 Apache、Django、PostgreSQL 和 Linux 搭建的开源系统之上。但是让我来告诉你吧，配置这些堆栈可不是谁都可以做的。老版本的 PostgreSQL 需要手工配置 Vacuuming 来确保数据库的自动清理，而即使是最新版本的 Ubuntu 和 FreeBSD 也仍然要求用户去手工配置他们的第一个数据库集群。

相比之下，MS SQL (微软的 SQL 数据库) 则不需要你手工配置以上的任何一样东西。至于 Apache …… 我的天，Apache 简直复杂到让我根本来不及去尝试给一个新用户讲解我们如何可以通过一个一次性的安装过程就能把虚拟机、MovableType，几个 Diango apps 和 WordPress 配置在一起并流畅地使用。单单是给那些技术背景还不错但并非软件开发者的用户解释清楚 Apache 的那些针对多进程和多线程的设置参数就已经够我喝一壶的了。相比之下，微软的 IIS 7 或者是使用了 OS X 服务器的那个几乎闭源的 GUI 管理器的 Apache ，在配置的时候就要简单上不止一个数量级了。Django 确实是一个好的开源产品，但它也 只是 一个基础构架，而并非是一个可以直接面向终端普通用户的商业产品。而开源真正的强项就 恰恰在 这种基础构架的开发和创新上，这也正是驱使开发者为开源做贡献的最本真的动力。

所以我的结论是，如果下次你再看到一个你喜欢的应用程序，请好好细心地揣摩一下这款产品，揣摩一下所有的那些针对用户的体贴入微的设计细节。而不是武断的认为你可以轻轻松松的在一周之内就用开源工具做一个和这个应用一摸一样的产品出来。那些认为制作和实现一个应用程序如此简单的人，十之八九都是因为忽略了软件开发的最终产品是要交给用户去用的。

via: https://bitquabit.com/post/one-which-i-call-out-hacker-news/

作者：Benjamin Pollack 译者：hopefully2333，yunfengHe 校对：yunfengHe，wxy

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