mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-24 02:20:09 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu.Wang
commit
0ca8bed7d5
@ -1,9 +1,11 @@
|
||||
使用极简浏览器 Min 浏览网页
|
||||
======
|
||||
|
||||
> 并非所有 web 浏览器都要做到无所不能，Min 就是一个极简主义风格的浏览器。
|
||||
|
||||
|
||||
|
||||
现在还有开发新的网络浏览器的需要吗？即使现在浏览器领域已经成为了寡头市场，但仍然不断涌现出各种前所未有的浏览器产品。
|
||||
现在还有开发新的 Web 浏览器的需要吗？即使现在浏览器领域已经成为了寡头市场，但仍然不断涌现出各种前所未有的浏览器产品。
|
||||
|
||||
[Min][1] 就是其中一个。顾名思义，Min 是一个小的浏览器，也是一个极简主义的浏览器。但它麻雀虽小五脏俱全，而且还是一个开源的浏览器，它的 Apache 2.0 许可证引起了我的注意。
|
||||
|
||||
@ -29,7 +31,7 @@ Min 号称是更智能、更快速的浏览器。经过尝试以后，我觉得
|
||||
|
||||
Min 和其它浏览器一样，支持页面选项卡。它还有一个称为 Tasks 的功能，可以对打开的选项卡进行分组。
|
||||
|
||||
[DuckDuckGo][6]是我最喜欢的搜索引擎，而 Min 的默认搜索引擎恰好就是它，这正合我意。当然，如果你喜欢另一个搜索引擎，也可以在 Min 的偏好设置中配置你喜欢的搜索引擎作为默认搜索引擎。
|
||||
[DuckDuckGo][6] 是我最喜欢的搜索引擎，而 Min 的默认搜索引擎恰好就是它，这正合我意。当然，如果你喜欢另一个搜索引擎，也可以在 Min 的偏好设置中配置你喜欢的搜索引擎作为默认搜索引擎。
|
||||
|
||||
Min 没有使用类似 AdBlock 这样的插件来过滤你不想看到的内容，而是使用了一个名为 [EasyList][7] 的内置的广告拦截器，你可以使用它来屏蔽脚本和图片。另外 Min 还带有一个内置的防跟踪软件。
|
||||
|
||||
@ -54,7 +56,7 @@ Min 确实也有自己的缺点，例如它无法将网站添加为书签。替
|
||||
### 总结
|
||||
|
||||
Min 算是一个中规中矩的浏览器，它可以凭借轻量、快速的优点吸引很多极简主义的用户。但是对于追求多功能的用户来说，Min 就显得相当捉襟见肘了。
|
||||
.
|
||||
|
||||
所以，如果你想摆脱当今多功能浏览器的束缚，我觉得可以试用一下 Min。
|
||||
|
||||
|
||||
@ -65,7 +67,7 @@ via: https://opensource.com/article/18/10/min-web-browser
|
||||
作者：[Scott Nesbitt][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[HankChow](https://github.com/HankChow)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,12 +1,13 @@
|
||||
推动 DevOps 变革的三个方面
|
||||
======
|
||||
|
||||
推动大规模的组织变革是一个痛苦的过程。对于 DevOps 来说，尽管也有阵痛，但变革带来的价值则相当可观。
|
||||
|
||||
|
||||
|
||||
避免痛苦是一种强大的动力。一些研究表明，[植物也会通过遭受疼痛的过程][1]以采取措施来保护自己。我们人类有时也会刻意让自己受苦——在剧烈运动之后，身体可能会发生酸痛，但我们仍然坚持运动。那是因为当人认为整个过程利大于弊时，几乎可以忍受任何事情。
|
||||
|
||||
推动大规模的组织变革得过程确实是痛苦的。有人可能会因难以改变价值观和行为而感到痛苦，有人可能会因难以带领团队而感到痛苦，也有人可能会因难以开展工作而感到痛苦。但就 DevOps 而言，我可以说这些痛苦都是值得的。
|
||||
推动大规模的组织变革的过程确实是痛苦的。有人可能会因难以改变价值观和行为而感到痛苦，有人可能会因难以带领团队而感到痛苦，也有人可能会因难以开展工作而感到痛苦。但就 DevOps 而言，我可以说这些痛苦都是值得的。
|
||||
|
||||
我也曾经关注过一个团队耗费大量时间优化技术流程的过程，在这个过程中，团队逐渐将流程进行自动化改造，并最终获得了成功。
|
||||
|
||||
@ -14,60 +15,64 @@
|
||||
|
||||
图片来源：Lee Eason. CC BY-SA 4.0
|
||||
|
||||
这张图表充分表明了变革的价值。一家公司在我主导实行了 DevOps 转型之后，60 多个团队每月提交了超过 900 个发布请求。这些工作量的原耗时高达每个月 350 天，而这么多的工作量对于任何公司来说都是不可忽视的。除此以外，他们每月的部署次数从 100 次增加到了 9000 次，高危 bug 减少了 24%，工程师们更轻松了，<ruby>净推荐值<rt>Net Promoter Score</rt></ruby>（NPS）也提高了，而 NPS 提高反过来也让团队的 DevOps 转型更加顺利。正如 [Puppet 发布的 DevOps 报告][4]所预测的，用在技术流程改进上的投资可以在业务成果上明显地体现出来。
|
||||
这张图表充分表明了变革的价值。一家公司在我主导实行了 DevOps 转型之后，60 多个团队每月提交了超过 900 个发布请求。这些工作量的原耗时高达每个月 350 人/天，而这么多的工作量对于任何公司来说都是不可忽视的。除此以外，他们每月的部署次数从 100 次增加到了 9000 次，高危 bug 减少了 24%，工程师们更轻松了，<ruby>净推荐值<rt>Net Promoter Score</rt></ruby>（NPS）也提高了，而 NPS 提高反过来也让团队的 DevOps 转型更加顺利。正如 [Puppet 发布的 DevOps 报告][4]所预测的，用在技术流程改进上的投入可以在业务成果上明显地体现出来。
|
||||
|
||||
而 DevOps 主导者在推动变革是必须关注这三个方面：团队管理，团队文化和团队活力。
|
||||
而 DevOps 主导者在推动变革时必须关注这三个方面：团队管理，团队文化和团队活力。
|
||||
|
||||
### 团队管理
|
||||
|
||||
最重要的是，改进对技术流程的投入可以转化为更好的业务成果。
|
||||
|
||||
组织架构越大，业务领导与一线员工之间的距离就会越大，当然发生误解的可能性也会越大。而且各种技术工具和实际应用都在以日新月异的速度变化，这就导致业务领导几乎不可能对 DevOps 或敏捷开发的转型方向有一个亲身的了解。
|
||||
|
||||
DevOps 主导者必须和管理层密切合作，在进行决策的时候给出相关的意见，以帮助他们做出正确的决策。
|
||||
|
||||
公司的管理层只是知道 DevOps 会对产品部署的方式进行改进，而并不了解其中的具体过程。当管理层发现你在和软件团队执行自动化部署失败时，就会想要了解这件事情的细节。如果管理层了解到进行部署的是软件团队而不是专门的发布管理团队，就可能会坚持使用传统的变更流程来保证业务的正常运作。你可能会失去团队的信任，团队也可能不愿意作出进一步的改变。
|
||||
公司的管理层只是知道 DevOps 会对产品部署的方式进行改进，而并不了解其中的具体过程。假设你正在帮助一个软件开发团队实现自动化部署，当管理层得知某次部署失败时（这种情况是有的），就会想要了解这件事情的细节。如果管理层了解到进行部署的是软件团队而不是专门的发布管理团队，就可能会坚持使用传统的变更流程来保证业务的正常运作。你可能会失去团队的信任，团队也可能不愿意做出进一步的改变。
|
||||
|
||||
如果没有和管理层做好心理上的预期，一旦发生意外的生产事件，都会对你和管理层之间的信任造成难以消除的影响。所以，最好事先和管理层之间在各方面协调好，这会让你在后续的工作中避免很多麻烦。
|
||||
如果没有和管理层做好心理上的预期，一旦发生意外的生产事件，重建管理层的信任并得到他们的支持比事先对他们进行教育需要更长的时间。所以，最好事先和管理层在各方面协调好，这会让你在后续的工作中避免很多麻烦。
|
||||
|
||||
对于和管理层之间的协调，这里有两条建议：
|
||||
|
||||
* 一是**重视所有规章制度**。如果管理层对合同、安全等各方面有任何疑问，你都可以向法务或安全负责人咨询，这样做可以避免犯下后果严重的错误。
|
||||
* 二是**将管理层的重点关注的方面输出为量化指标**。举个例子，如果公司的目标是减少客户流失，而你调查得出计划外的停机是造成客户流失的主要原因，那么就可以让团队对故障的<ruby>平均检测时间<rt>Mean Time To Detection</rt></ruby>（MTTD）和<ruby>平均解决时间<rt>Mean Time To Resolution</rt></ruby>（MTTR）实行重点优化。你可以使用这些关键指标来量化团队的工作成果，而管理层对此也可以有一个直观的了解。
|
||||
|
||||
|
||||
* 一是**重视所有规章制度**。如果管理层对合同、安全等各方面有任何疑问，你都可以向法务或安全负责人咨询，这样做可以避免犯下后果严重的错误。
|
||||
* 二是**将管理层重点关注的方面输出为量化指标**。举个例子，如果公司的目标是减少客户流失，而你调查得出计划外的服务宕机是造成客户流失的主要原因，那么就可以让团队对故障的<ruby>平均排查时间<rt>Mean Time To Detection</rt></ruby>（MTTD）和<ruby>平均解决时间<rt>Mean Time To Resolution</rt></ruby>（MTTR）实行重点优化。你可以使用这些关键指标来量化团队的工作成果，而管理层对此也可以有一个直观的了解。
|
||||
|
||||
### 团队文化
|
||||
|
||||
DevOps 是一种专注于持续改进代码、构建、部署和操作流程的文化，而团队文化代表了团队的价值观和行为。从本质上说，团队文化是要塑造团队成员的行为方式，而这并不是一件容易的事。
|
||||
|
||||
我推荐一本叫做《[披着狼皮的 CIO][5]》的书。另外，研究心理学、阅读《[Drive][6]》、观看 Daniel Pink 的 [TED 演讲][7]、阅读《[千面英雄][7]》、了解每个人的心路历程，以上这些都是你推动公司技术变革所应该尝试去做的事情。
|
||||
我推荐一本叫做《[披着狼皮的 CIO][5]》的书。另外，研究心理学、阅读《[Drive][6]》、观看 Daniel Pink 的 [TED 演讲][7]、阅读《[千面英雄][7]》、了解每个人的心路历程，以上这些都是你推动公司技术变革所应该尝试去做的事情。如果这些你都没兴趣，说明你不是那个推动公司变革的人。如果你想成为那个人，那就开始学习吧！
|
||||
|
||||
理性的人大多都按照自己的价值观工作，然而团队通常没有让每个人都能达成共识的明确价值观。因此，你需要明确团队目前的价值观，包括价值观的形成过程和价值观的目标导向。也不能将这些价值观强加到团队成员身上，只需要让团队成员在目前的硬件条件下力所能及地做到最好就可以了
|
||||
从本质上说，改变一个人真不是件容易的事。
|
||||
|
||||
同时需要向团队成员阐明，公司正在发生组织上的变化，团队的价值观也随之改变，最好也厘清整个过程中将会作出什么变化。例如，公司以往或许是由于资金有限，一直将节约成本的原则放在首位，在研发新产品的时候，基础架构团队不得不通过共享数据库集群或服务器，从而导致了服务之间的紧密耦合。然而随着时间的推移，这种做法会产生难以维护的混乱，即使是一个小小的变化也可能造成无法预料的后果。这就导致交付团队难以执行变更控制流程，进而令变更停滞不前。
|
||||
理性的人大多都按照自己的价值观工作，然而团队通常没有让每个人都能达成共识的明确价值观。因此，你需要明确团队目前的价值观，包括价值观的形成过程和价值观的目标导向。但不能将这些价值观强加到团队成员身上，只需要让团队成员在现有条件下力所能及地做到最好就可以了。
|
||||
|
||||
如果这种状况持续多年，最终的结果将会是毫无创新、技术老旧、问题繁多以及产品品质低下，公司的发展到达了瓶颈，原本的价值观已经不再适用。所以，工作效率的优先级必须高于节约成本。
|
||||
同时需要向团队成员阐明，公司正在发生组织和团队目标的变化，团队的价值观也随之改变，最好也厘清整个过程中将会作出什么变化。例如，公司以往或许是由于资金有限，一直将节约成本的原则放在首位，在研发新产品的时候，基础架构团队不得不共享数据库集群或服务器，从而导致了服务之间的紧密耦合。然而随着时间的推移，这种做法会产生难以维护的混乱，即使是一个小小的变化也可能造成无法预料的后果。这就导致交付团队难以执行变更控制流程，进而令变更停滞不前。
|
||||
|
||||
你必须强调团队的价值观。每当团队按照价值观取得了一定的工作进展，都应该对团队作出激励。在团队部署出现失败时，鼓励他们承担风险、继续学习，同时指导团队如何改进他们的工作并表示支持。长此下来，团队成员就会对你产生信任，并逐渐切合团队的价值观。
|
||||
如果这种状况持续几年，最终的结果将会是毫无创新、技术老旧、问题繁多以及产品品质低下，公司的发展到达了瓶颈，原本的价值观已经不再适用。所以，工作效率的优先级必须高于节约成本。如果一个选择能让团队运作更好，另一个选择只是短期来看成本便宜，那你应该选择前者。
|
||||
|
||||
你必须反复强调团队的价值观。每当团队取得了一定的工作进展（即使探索创新时出现一些小的失误），都应该对团队作出激励。在团队部署出现失败时，鼓励他们承担风险、吸取教训，同时指导团队如何改进他们的工作并表示支持。长此下来，团队成员就会对你产生信任，不再顾虑为切合团队的价值观而做出改变。
|
||||
|
||||
### 团队活力
|
||||
|
||||
你有没有在会议上听过类似这样的话？“在张三度假回来之前，我们无法对这件事情做出评估。他是唯一一个了解代码的人”，或者是“我们完成不了这项任务，它在网络上需要跨团队合作，而防火墙管理员刚好请病假了”，又或者是“张三最清楚这个系统最好，他说是怎么样，通常就是怎么样”。那么如果团队在处理工作时，谁才是主力？就是张三。而且也一直会是他。
|
||||
你有没有在会议上听过类似这样的话？“在张三度假回来之前，我们无法对这件事情做出评估。他是唯一一个了解代码的人”，或者是“我们完成不了这项任务，它在网络上需要跨团队合作，而防火墙管理员刚好请病假了”，又或者是“张三最清楚这个系统，他说是怎么样，通常就是怎么样”。那么如果团队在处理工作时，谁才是主力？就是张三。而且也一直会是他。
|
||||
|
||||
我们一直都认为这就是软件开发的本质。但是如果我们不作出改变，这种循环就会一直保持下去。
|
||||
我们一直都认为这就是软件开发的自带属性。但是如果我们不作出改变，这种循环就会一直持续下去。
|
||||
|
||||
熵的存在会让团队自发地变得混乱和缺乏活力，团队的成员和主导者的都有责任控制这个熵并保持团队的活力。DevOps、敏捷开发、上云、代码重构这些行为都会令熵增加速，这是因为转型让团队需要学习更多新技能和专业知识以开展新工作。
|
||||
熵的存在会让团队自发地变得混乱和缺乏活力，团队的成员和主导者的都有责任控制这个熵并保持团队的活力。DevOps、敏捷开发、上云、代码重构这些行为都会令熵加速增长，这是因为转型让团队需要学习更多新技能和专业知识以开展新工作。
|
||||
|
||||
我们来看一个产品团队重构遗留代码的例子。像往常一样，他们在 AWS 上构建新的服务。而传统的系统则在数据中心部署，并由 IT 部门进行监控和备份。IT 部门会确保在基础架构的层面上满足应用的安全需求、进行灾难恢复测试、系统补丁、安装配置了入侵检测和防病毒代理，而且 IT 部门还保留了年度审计流程所需的变更控制记录。
|
||||
我们来看一个产品团队重构历史代码的例子。像往常一样，他们在 AWS 上构建新的服务。而传统的系统则在数据中心部署，并由 IT 部门进行监控和备份。IT 部门会确保在基础架构的层面上满足应用的安全需求、进行灾难恢复测试、系统补丁、安装配置了入侵检测和防病毒代理，而且 IT 部门还保留了年度审计流程所需的变更控制记录。
|
||||
|
||||
产品团队经常会犯一个致命的错误，就是认为 IT 部门是需要突破的瓶颈。他们希望脱离已有的 IT 部门并使用公有云，但实际上是他们忽视了 IT 部门提供的关键服务。迁移到云上只是以不同的方式实现这些关键服务，因为 AWS 也是一个数据中心，团队即使使用 AWS 也需要完成 IT 运维任务。
|
||||
产品团队经常会犯一个致命的错误，就是认为 IT 是消耗资源的部门，是需要突破的瓶颈。他们希望脱离已有的 IT 部门并使用公有云，但实际上是他们忽视了 IT 部门提供的关键服务。迁移到云上只是以不同的方式实现这些关键服务，因为 AWS 也是一个数据中心，团队即使使用 AWS 也需要完成 IT 运维任务。
|
||||
|
||||
实际上，产品团队在迁移到云时候也必须学习如何使用这些 IT 服务。因此，当产品团队开始重构遗留的代码并部署到云上时，也需要学习大量的技能才能正常运作。这些技能不会无师自通，必须自行学习或者聘用相关的人员，团队的主导者也必须积极进行管理。
|
||||
实际上，产品团队在向云迁移的时候也必须学习如何使用这些 IT 服务。因此，当产品团队开始重构历史代码并部署到云上时，也需要学习大量的技能才能正常运作。这些技能不会无师自通，必须自行学习或者聘用相关的人员，团队的主导者也必须积极进行管理。
|
||||
|
||||
在带领团队时，我找不到任何适合我的工具，因此我建立了 [Tekita.io][9] 这个项目。Tekata 免费而且容易使用。但相比起来，把注意力集中在人员和流程上更为重要，你需要不断学习，持续关注团队的弱项，因为它们会影响团队的交付能力，而修补这些弱项往往需要学习大量的新知识，这就需要团队成员之间有一个很好的协作。因此 76％ 的年轻人都认为个人发展机会是公司文化[最重要的的一环][10]。
|
||||
在带领团队时，我找不到任何适合我的工具，因此我建立了 [Tekita.io][9] 这个项目。Tekata 免费而且容易使用。但相比起来，把注意力集中在人员和流程上更为重要，你需要不断学习，持续关注团队的短板，因为它们会影响团队的交付能力，而弥补这些短板往往需要学习大量的新知识，这就需要团队成员之间有一个很好的协作。因此 76％ 的年轻人都认为个人发展机会是公司文化[最重要的的一环][10]。
|
||||
|
||||
### 效果就是最好的证明
|
||||
|
||||
DevOps 转型会改变团队的工作方式和文化，这需要得到管理层的支持和理解。同时，工作方式的改变意味着新技术的引入，所以在管理上也必须谨慎。但转型的最终结果是团队变得更高效、成员变得更积极、产品变得更优质，客户也变得更快乐。
|
||||
DevOps 转型会改变团队的工作方式和文化，这需要得到管理层的支持和理解。同时，工作方式的改变意味着新技术的引入，所以在管理上也必须谨慎。但转型的最终结果是团队变得更高效、成员变得更积极、产品变得更优质，客户也变得更满意。
|
||||
|
||||
Lee Eason 将于 10 月 21-23 日在北卡罗来纳州 Raleigh 举行的 [All Things Open][12] 上讲述 [DevOps 转型的故事][11]。
|
||||
|
||||
免责声明：本文中的内容仅为 Lee Eason 的个人立场，不代表 Ipreo 或 IHS Markit。
|
||||
|
||||
@ -78,7 +83,7 @@ via: https://opensource.com/article/18/10/tales-devops-transformation
|
||||
作者：[Lee Eason][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[HankChow](https://github.com/HankChow)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[pityonline](https://github.com/pityonline)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -96,4 +101,3 @@ via: https://opensource.com/article/18/10/tales-devops-transformation
|
||||
[10]: https://www.execu-search.com/~/media/Resources/pdf/2017_Hiring_Outlook_eBook
|
||||
[11]: https://allthingsopen.org/talk/tales-from-a-devops-transformation/
|
||||
[12]: https://allthingsopen.org/
|
||||
|
||||
|
||||
@ -1,148 +1,138 @@
|
||||
# 关于 C ++ 的所有争论？Bjarne Stroustrup 警告他的 C++ 未来的计划很危险
|
||||
# 对 C++ 的忧虑？Bjarne Stroustrup 警告，关于 C++ 的某些未来计划十分危险
|
||||
|
||||
|
||||
|
||||
今年早些时候，我们**访谈**了 Bjarne Stroustrup，他是 C++ 语言的创始人，摩根士丹利技术部门的董事总经理，美国哥伦比亚大学计算机科学的客座教授，他写了[一封信][1]邀请那些关注编程语言演进的人去“想想瓦萨号！”
|
||||
今年早些时候，我们对 Bjarne Stroustrup 进行了采访。他是 C++ 语言的创始人，摩根士丹利技术部门的董事总经理，美国哥伦比亚大学计算机科学的客座教授。他写了[一封信][1]，请那些关注编程语言进展的人去“想想瓦萨号！”
|
||||
|
||||
毫无疑问，对于丹麦人来说，这句话很容易理解，而那些对于 17 世纪的斯堪的纳维亚历史了解不多的人，还需要展开说一下。瓦萨号是一艘瑞典军舰，由国王 Gustavus Adolphus 委托建造。它是在 1628 年 8 月 10 日首航时，当时波罗的海国家中最强大的军舰，但是它在首航几分钟之后就沉没了。
|
||||
这句话对于丹麦人来说，毫无疑问，很容易理解。而那些对于 17 世纪的斯堪的纳维亚历史了解不多的人，还需要详细说明一下。瓦萨号是一艘瑞典军舰，由国王 Gustavus Adolphus 定做。它是当时波罗的海国家中最强大的军舰，但在 1628 年 8 月 10 日首航没几分钟之后，就沉没了。
|
||||
|
||||
巨大的瓦萨号有一个难以解决的设计缺陷：头重脚轻，以至于它被[一阵狂风刮翻了][2]。通过这段翻船历史的回忆，Stroustrup 警示了 C++ 所面临的风险，因为现在越来越多的特性被添加到了 C++ 中。
|
||||
巨大的瓦萨号有一个难以解决的设计缺陷：头重脚轻，以至于它被[一阵狂风刮翻了][2]。通过援引这艘沉船的历史，Stroustrup 警示了 C++ 所面临的风险——现在越来越多的特性被添加到了 C++ 中。
|
||||
|
||||
现在已经提议了不少这样的特性。Stroustrup 在他的信中引用了 43 条提议。他认为那些参与 C++ 语言 ISO 标准演进的人（指众所周知的 [WG21][3]），正在努力地让语言更高级，但他们的努力方向却并不一致。
|
||||
我们现在已经发现了好些能导致头重脚轻的特性。Stroustrup 在他的信中引用了 43 个提议。他认为那些参与 C++ 语言 ISO 标准演进的人（被称为 [WG21][3]），正在努力推进语言发展，但成员们的努力方向却并不一致。
|
||||
|
||||
在他的信中，他写道：
|
||||
|
||||
> 分开来看，许多提议都很有道理。但将它们综合到一起，这些提议是很愚蠢的，将危害 C++ 的未来。
|
||||
>分开来看，许多提议都很有道理。但将它们综合到一起，这些提议是很愚蠢的，将危害 C++ 的未来。
|
||||
|
||||
他明确表示，不希望 C++ 重蹈瓦萨号的覆辙，这种渐近式的改进将敲响 C++ 的丧钟。相反，应该吸取瓦萨号的教训，构建一个坚实的基础，吸取经验教训，并做彻底的测试。
|
||||
他明确表示，他用瓦萨号作为比喻并不是说他认为不断提升会带来毁灭。我们应该吸取瓦萨号的教训，构建一个坚实的基础，从错误中学习并对新版本做彻底的测试。
|
||||
|
||||
在瑞士拉普斯威尔（Rapperswill）召开的 C++ 标准化委员会会议之后，本月早些时候，Stroustrup 接受了_《The Register》_ 的采访，回答了有关 C++ 语言下一步发展方向方面的几个问题。（最新版是 C++17，它去年刚发布；下一个版本是 C++20，它正在开发中，预计于 2020 年发布。）
|
||||
在瑞士<ruby>拉普斯威尔<rt>Rapperswill</rt></ruby>召开 C++ 标准化委员会会议之后，本月早些时候，Stroustrup 接受了 <i>The Register</i> 的采访，回答了有关 C++ 语言下一步发展方向方面的几个问题。（最新版是 C++17，它去年刚发布；下一个版本是 C++20，它正在开发中，预计于 2020 年发布。）
|
||||
|
||||
**Register：在你的信件《想想瓦萨号！》中，你写道：**
|
||||
**<i>Register：</i>在您的信件《想想瓦萨号！》中，您写道：**
|
||||
|
||||
> 在 C++11 开始基础不再完整，而 C++17 中在使基础更加稳固、规范和完整方面几乎没有改善。相反地，却增加了重要接口的复杂度，让人们需要学习的特性数量越来越多。C++ 可能在这种提议的重压之下崩溃 —— 这些提议大多数都不成熟。我们不应该花费大量的时间为专家级用户们（比如我们自己）去创建越来越复杂的东西。~~（还要考虑普通用户的学习曲线，越复杂的东西越不易普及。）~~
|
||||
>在 C++11 开始的基础建设尚未完成，而 C++17 基本没有在使基础更加稳固、规范和完整方面做出改善。相反地，却增加了重要接口的复杂度（原文为 surface complexity，直译“表面复杂度”），让人们需要学习的特性数量越来越多。C++ 可能在这种不成熟的提议的重压之下崩溃。我们不应该花费大量的时间为专家级用户们（比如我们自己）去创建越来越复杂的东西。~~（还要考虑普通用户的学习曲线，越复杂的东西越不易普及。）~~
|
||||
|
||||
**对新人来说，C++ 很难吗？如果是这样，你认为怎样的特性让新人更易理解？**
|
||||
**对新人来说，C++ 过难了吗？如果是这样，您认为怎样的特性让新人更易理解？**
|
||||
|
||||
**Stroustrup：**C++ 的有些东西对于新人来说确实很难。
|
||||
<b><i>Stroustrup：</i></b>C++ 的有些东西对于新人来说确实很具有挑战性。
|
||||
|
||||
换句话说，C++ 中有些东西对于新人来说，比起 C 或上世纪九十年代的 C++ 更容易理解了。而难点是让大型社区专注于这些部分，并且帮助新手和普通 C++ 用户去规避那些对高级库实现提供支持的部分。
|
||||
另一方面而言，C++ 中有些东西对于新人来说，比起 C 或上世纪九十年代的 C++ 更容易理解了。而难点是让大型社区专注于这些部分，并且帮助新手和非专业的 C++ 用户去规避那些对高级库实现提供支持的部分。
|
||||
|
||||
我建议使用 [C++ 核心准则][4] 作为实现上述目标的一个辅助。
|
||||
|
||||
此外，我的 “C++ 教程” 也可以帮助人们在使用现代 C++ 时走上正确的方向，而不会迷失在自上世纪九十年代以来的复杂性中，或困惑于只有专家级的用户才能理解的东西中。第二版的 “C++ 教程” 涵盖了 C++17 和部分 C++20 的内容，这本书即将要出版了。
|
||||
此外，我的“C++ 教程”也可以帮助人们在使用现代 C++ 时走上正确的方向，而不会迷失在自上世纪九十年代以来的复杂性中，或困惑于只有专家级的用户才能理解的东西中。这本即将出版的第二版的“ C++ 教程”涵盖了 C++17 和部分 C++20 的内容。
|
||||
|
||||
我和其他人给没有编程经验的大一新生教过 C++，只要你不去深挖编程语言的每个晦涩难懂的角落，把注意力集中到 C++ 中最主流的部分，在三个月内新可以学会 C++。
|
||||
我和其他人给没有编程经验的大一新生教过 C++，只要你不去深入编程语言的每个晦涩难懂的角落，把注意力集中到 C++ 中最主流的部分，就可以在三个月内学会 C++。
|
||||
|
||||
“让简单的东西保持简单” 是我长期追求的目标。比如 C++11 的 `range-for` 循环：
|
||||
“让简单的东西保持简单”是我长期追求的目标。比如 C++11 的 `range-for` 循环：
|
||||
|
||||
```
|
||||
for (int& x : v) ++x; // increment each element of the container v
|
||||
|
||||
```
|
||||
|
||||
`v` 的位置可以是任何容器。在 C 和 C 风格的 C++ 中，它可能看到的是这样：
|
||||
`v` 的位置可以是任何容器。在 C 和 C 风格的 C++ 中，它可能看起来是这样：
|
||||
|
||||
```
|
||||
for (int i=0; i<MAX; i++) ++v[i]; // increment each element of the array v
|
||||
|
||||
```
|
||||
|
||||
一些人报怨说添加了 `range-for` 循环让 C++ 变得更复杂了，很显然，他们是正确的，因为它添加了一个新特性，但它却让 C++ 用起来更简单。同时它还解决掉了传统 for 循环中出现的一些常见错误。
|
||||
一些人抱怨说添加了 `range-for` 循环让 C++ 变得更复杂了，很显然，他们是正确的，因为它添加了一个新特性。但它却让 C++ 用起来更简单，而且同时它还消除掉了使用传统 for 循环时会出现的一些常见错误。
|
||||
|
||||
另外的一个例子是 C++11 的标准线程库。它比起使用 POSIX 或直接使用 Windows 的 C API 来说更简单，并且更不易出错。
|
||||
|
||||
**Register：你如何看待 C++ 现在的状况？**
|
||||
**<i>Register：</i>您如何看待 C++ 现在的状况？**
|
||||
|
||||
**Stroustrup：** C++11 是 C++ 的最重大的改进版，并且在 C++14 上全面完成了改进工作。C++17 添加了相当多的新特性，但是没有提供对新技术的很多支持。C++20 目前看上去可能会成为一个重大改进版。编译器的状况和标准库实现的非常好，非常接近最新的标准。C++17 已经可用。持续改进了对工具的支持。已经有了许多第三方的库和许多新工具。而不幸的是，这些东西不太好找到。
|
||||
<b><i>Stroustrup：</i></b>C++11 中作出了许多重大改进，并且我们在 C++14 上全面完成了改进工作。C++17 添加了相当多的新特性，但是没有提供对新技术的很多支持。C++20 目前看上去可能会成为一个重大改进版。编译器的状况非常好，标准库实现得也很优秀，非常接近最新的标准。C++17 现在已经可以使用，对于工具的支持正在逐步推进。已经有了许多第三方的库和好些新工具。然而，不幸的是，这些东西不太好找到。
|
||||
|
||||
我在《想想瓦萨号！》一文中所表达的担忧与标准化过程有关，对新东西的过度热情与完美主义的组合拖延了重大的改进。“追述完美是优秀的敌人”，在六月份拉普斯威尔的会议上有 160 人参与。在这样一个数量庞大和多样化的人群中很难取得一致意见。这就导致了专家们更多地为他们自己去设计，而不是为了整个社区。
|
||||
我在《想想瓦萨号！》一文中所表达的担忧与标准化过程有关，对新东西的过度热情与完美主义的组合推迟了重大改进。“追求完美是获得优秀成绩的障碍”。在六月份拉普斯威尔的会议上有 160 人参与；在这样一个数量庞大且多样化的人群中很难取得一致意见。专家们也本来就有只为自己设计语言的倾向，这让他们不会时常在设计时考虑整个社区的需求。
|
||||
|
||||
**Register： C++ 是否有一个期望的状况，或为了期望的适应性而努力简化以满足程序员们在任意时间的需要？**
|
||||
**<i>Register：</i>C++ 是否有一个理想的状态，或者与之相反，您只是为了程序员们的期望而努力，随时适应并且努力满足程序员们的需要？**
|
||||
|
||||
**Stroustrup：** 二者都有。我很乐意看到 C++ 支持彻底保证类型安全和资源安全的编程方式。这不应该通过限制适用性或增加成本来实现，而是应该通过改进的表达能力和性能来实现。我认为可以做到这些，通过让程序员使用更好的（更易用的）语言可以实现这一点。
|
||||
<b><i>Stroustrup：</i></b>二者都有。我很乐意看到 C++ 支持彻底保证类型安全和资源安全的编程方式。这不应该通过限制适用性或增加性能损耗来实现，而是应该通过改进的表达能力和更好的性能来实现。通过让程序员使用更好的（和更易用的）语言工具可以达到这个目标，我们可以做到的。
|
||||
|
||||
终极目标不会马上实现，也不会单靠语言的设计来实现。为了让编程更高效，我们需要通过改进语言特性、最好的库、静态分析、以及规则的组合来实现。C++ 核心准则是我提升 C++ 代码质量的广泛而长远的方法。
|
||||
终极目标不会马上实现，也不会单靠语言设计来实现。为了实现这一目标，我们需要改进语言特性、提供更好的库和静态分析，并且设立提升编程效率的规则。C++ 核心准则是我为了提升 C++ 代码质量而实行的广泛而长期的计划的一部分。
|
||||
|
||||
**Register：对于 C++ 是否有明显的风险？如果有，它是如何产生的？（如，改进过于缓慢，新出现的低级语言，等等，从你的信中看，似乎是提议过多。）**
|
||||
**<i>Register：</i>目前 C++ 是否面临着可以预见的风险？如果有，它是什么？（如，迭代过于缓慢，新兴低级语言，等等……据您的观点来看，似乎是提出的提议过多。）**
|
||||
|
||||
**Stroustrup：**毫无疑问，今年我们已经收到了 400 个提议。当然，它们并不都是新提议。许多提议都与规范语言和标准库这一必需而乏味的工作相关，但是量大到难以管理。你可以在 WG21 的网站上找到所有这些文章。
|
||||
<b><i>Stroustrup：</i></b>就是这样。今年我们已经收到了 400 篇文章。当然了，它们并不都是新提议。许多提议都与规范语言和标准库这一必需而乏味的工作相关，但是量大到难以管理。你可以在 WG21 的网站上找到所有这些文章。
|
||||
|
||||
我写了《想想瓦萨号！》这封信作为一个呼吁。我感受到了这种压力，为解决紧急需要和赶时髦而增加语言特性，而不是去加强语言基础（比如，改善静态类型系统）。增加的任何新东西，无论它是多小都会产生成本，比如实现、学习、工具升级。重大的特性是那些改变我们编程思想的特性。那才是我们必须关注的东西。
|
||||
我写了《想想瓦萨号！》这封信作为一个呼吁，因为这种为了解决即刻需求（或者赶时髦）而不断增添语言特性，却对巩固语言基础（比如，改善静态类型系统）不管不问的倾向让我感到震惊。增加的任何新东西，无论它多小都会产生成本，比如实现、学习、工具升级。重大的特性改变能够改变我们对编程的想法，而它们才是我们必须关注的东西。
|
||||
|
||||
委员会已经设立了一个”指导小组“，这个小组由在语言、标准库、实现、以及实际使用领域中拥有极强履历的人组成。我是其中的成员之一。我们负责为重点领域写一些关于方向、设计理念和建议方面的东西。
|
||||
委员会已经设立了一个”指导小组“，这个小组由在语言、标准库、实现、以及工程实践领域中拥有不错履历的人组成。我是其中的成员之一。我们负责为重点领域写一些关于发展方向、设计理念和建议重点发展领域的东西。
|
||||
|
||||
对于 C++20，我们建议去关注：
|
||||
|
||||
```
|
||||
概念
|
||||
模块(提供适当的模块化和令人称奇的编译时改进)
|
||||
Ranges（包括一些无限序列的扩展）
|
||||
标准库中的网络概念
|
||||
```
|
||||
* 概念
|
||||
* 模块(适度地模块化并带来编译时的显著改进)
|
||||
* Ranges（包括一些无限序列的扩展）
|
||||
* 标准库中的网络概念
|
||||
|
||||
在拉普斯威尔会议之后，虽然带来的模块和网络化很显然只是一种延伸，但机会还是有的。我是一个乐观主义者，并且委员会的成员们都非常努力。
|
||||
在拉普斯威尔会议之后，这些都有了实现的机会，虽然模块和网络化都不是会议的重点讨论对象。我是一个乐观主义者，并且委员会的成员们都非常努力。
|
||||
|
||||
我并不担心其它语言或新语言会取代它。我喜欢编程语言。如果一个新的语言提供了其它编程语言没有提供的非常有用的东西，那它就是我们从中学习的榜样，当然，每个语言都有它自己的问题。许多 C++ 的问题都与它广泛的应用领域、大量的使用人群和过度的热情有关。大多数语言的社区都喜欢有这样的问题。
|
||||
我并不担心其它语言或新语言会取代它。我喜欢编程语言。如果一门新的语言提供了独一无二的、非常有用的东西，那它就是我们的榜样，我们可以向它学习。当然，每门语言本身都有一些问题。 C++ 的许多问题都与它广泛的应用领域、大量的使用人群和过度的热情有关。大多数语言的社区都会有这样的问题。
|
||||
|
||||
**Register：关于 C++ 你是否重新考虑过任何架构方面的决策？**
|
||||
**<i>Register：</i>关于 C++ 您是否重新考虑过任何架构方面的决策？**
|
||||
|
||||
**Stroustrup：** 当我使用一些新的编程语言时，我经常思考 C++ 原来的决策和设计。例如，可以看我的《编程的历史》论文第 1、2 部分。
|
||||
<b><i>Stroustrup：</i></b>当我着手规划新版本时，我经常反思原来的决策和设计。关于这些，可以看我的《编程的历史》论文第 1、2 部分。
|
||||
|
||||
并没有让我觉得很懊悔的重大决策，如果让我重新再做一次决策，几乎不会对现有的特性做任何不同的改变。
|
||||
并没有让我觉得很后悔的重大决策。虽然如果我必须重新做一次，我不能保证我不会改变这门语言的特性。
|
||||
|
||||
与以前一样，能够直接处理硬件加上零开销的抽象是设计的指导思想。使用构造函数和析构函数去处理资源是关键（RAII），STL 就是在 C++ 库中能够做什么的一个很好的例子。
|
||||
与以前一样，能够直接处理硬件加上零开销的抽象是设计的指导思想。使用构造函数和析构函数去处理资源是关键（RAII）；STL 就是解释 C++ 库能够做什么的一个很好的例子。
|
||||
|
||||
**Register：在 2011 年采纳的每三年发布一个标准的节奏是否仍然有效？我之所以这样问是因为 Java 为了更快地迭代，一直在解决需求。**
|
||||
**<i>Register：</i>在 2011 年被采纳的，每三年发布一个标准的节奏是否仍然有效？我之所以这样问是因为 Java 已经决定更快地迭代。**
|
||||
|
||||
**Stroustrup：**我认为 C++20 将会按时发布（就像 C++14 和 C++17 那样），并且主要的编译器也会立即遵从它。我也希望 C++20 比起 C++17 能有重大的改进。
|
||||
<b><i>Stroustrup：</i></b>我认为 C++20 将会按时发布（就像 C++14 和 C++17 那样），并且主流的编译器也会立即采用它。我也希望 C++20 基于 C++17 能有重大的改进。
|
||||
|
||||
对于其它语言如何管理它们的发行版我并不焦虑。C++ 是由一个遵循 ISO 规则的委员会来管理的，并不是由一个大公司或一个”创造它的权威“来管理。这一点不会改变。关于 ISO 标准，C++ 每三年发布一次的周期是一个激动人心的创举。标准的周期是 5 或 10 年。
|
||||
对于其它语言如何管理它们的版本，我并不十分关心。C++ 是由一个遵循 ISO 规则的委员会来管理的，而不是由某个大公司或某种“终生的仁慈独裁者”来管理。这一点不会改变。C++ 每三年发布一次的周期在ISO标准中是一个引人注目的创举。通常而言，周期应该是 5 或 10 年。
|
||||
|
||||
**Register：在你的信中你写道：**
|
||||
**<i>Register：</i>在您的信中您写道：**
|
||||
|
||||
```
|
||||
我们需要一个能够被”普通程序员“使用的条理还算清楚的编程语言，他们主要关心的是能否按时高质量地交付他们的应用程序。
|
||||
```
|
||||
>我们需要一个能够被”普通程序员“使用的，条理还算清楚的编程语言。他们主要关心的是，能否按时高质量地交付他们的应用程序。
|
||||
|
||||
对语言的改变是否能够去解决这个问题，或者还可能涉及到更多容易获得的工具和教育支持？
|
||||
改进语言能够解决这个问题吗？或者，我们还需要更容易获得的工具和教育支持？
|
||||
|
||||
**Stroustrup：**我努力去宣传我的理念 —— C++ 是什么以及如何使用它，并且我鼓励其他人也和我一样去做。
|
||||
<b><i>Stroustrup：</i></b>我尽力宣传我关于 C++ 的实质和使用方式的理念，并且我鼓励其他人也和我采取相同的行动。
|
||||
|
||||
特别是，我鼓励讲师和作者们向 C++ 程序员们宣扬有用易用的理念，而不是去示范复杂的示例和技术来展示他们自己有多高明。我在 2017 年的 CppCon 大会上的演讲主题就是”学习和教学 C++“，并且也指出 C++ 需要更好的工具。
|
||||
特别是，我鼓励讲师和作者们向 C++ 程序员们提出有用的建议，而不是去示范复杂的示例和技术，来展示他们自己有多高明。我在 2017 年的 CppCon 大会上的演讲主题就是“学习和传授 C++”，并且也指出，我们需要更好的工具。
|
||||
|
||||
我在演讲中提到构建支持和包管理器。这些历来都是 C++ 的弱点项。标准化委员会现在有一个工具研究小组，或许不久的将来也会有一个教育研究小组。
|
||||
我在演讲中提到了构建技术支持和包管理器，这些历来都是 C++ 的弱点项。标准化委员会现在有一个工具研究小组，或许不久的将来也会组建一个教育研究小组。
|
||||
|
||||
C++ 的社区以前基本上是很乱的，但是在过去的五年里，为了满足社区对新闻和支持的需要，出现了很多会议和博客。CppCon、isocpp.org、以及 Meeting++ 就是这样的例子。
|
||||
C++ 的社区以前是十分无组织性的，但是在过去的五年里，为了满足社区对新闻和技术支持的需要，出现了很多集会和博客。CppCon、isocpp.org、以及 Meeting++ 就是一些例子。
|
||||
|
||||
在委员会中做设计是非常困难的。但是，对于所有的大型项目来说，委员会又是必不可少的。我很关注它们，但是为了成功，关注和面对问题是必需的。
|
||||
设计一个委员会是非常困难的。但是，对于所有的大型项目来说，委员会又是必不可少的。我很忧虑，但是关注它们并且面对问题是成功的必要条件。
|
||||
|
||||
**Register：你如何看待 C++ 社区的流程？在沟通和决策方面你希望看到哪些变化？**
|
||||
**<i>Register：</i>您如何看待 C++ 社区的流程？在沟通和决策方面你希望看到哪些变化？**
|
||||
|
||||
**Stroustrup：**C++ 并没有企业管理的”社区流程“；它有一个 ISO 标准流程。我们不能对 ISO 的角色做重大的改变。理想的情况是，我们设立一个小的全职的”秘书处“来做最终决策和方向管理，但这种理想情况是不会出现的。相反，我们有成百上千的人在线来讨论，大约有 160 人在技术问题上进行投票，大约有 70 组织和 11 个国家在结果提议上正式投票。这样是很混乱的，但是在将来某个时候我们会让它好起来。
|
||||
<b><i>Stroustrup：</i></b>C++ 并没有企业管理一般的“社区流程”；它所遵循的是 ISO 标准流程。我们不能对 ISO 的条例做大的改变。理想的情况是，我们设立一个小型的、全职的“秘书处”来做最终决策和方向管理，但这种理想情况是不会出现的。相反，我们有成百上千的人在线讨论，大约有 160 人在技术问题上进行投票，大约有 70 组织和 11 个国家的人在最终提议上正式投票。这样很混乱，但是有些时候它的确能发挥作用。
|
||||
|
||||
**Register：最终你认为那些即将推出的 C++ 特性中，对 C++ 用户最有帮助的是哪些？**
|
||||
**<i>Register：</i>在最后，您认为那些即将推出的 C++ 特性中，对 C++ 用户最有帮助的是哪些？**
|
||||
|
||||
**Stroustrup：**
|
||||
**<i>Stroustrup：</i>**
|
||||
|
||||
```
|
||||
大大地简化了一般编程的概念
|
||||
并行算法 – 没有比使用现代化硬件的并发特性更好的方法了
|
||||
协程，如果委员会能够确定在 C++20 上推出。
|
||||
模块改进了组织源代码的方式，并且大幅改善了编译时间。我希望能有这样的模块，但是它还不能确定能否在 C++20 上推出。
|
||||
一个标准的网络库，但是它还不能确定能否在 C++20 上推出。
|
||||
```
|
||||
* 那些能让编程显著变简单的概念
|
||||
* 并行算法 – 如果要使用现代硬件的并发特性的话，这方法再简单不过了
|
||||
* 协程，如果委员会能够确定在 C++20 上推出。
|
||||
* 改进了组织源代码方式的，并且大幅改善了编译时间的模块。我希望能有这样的模块，但是还没办法确定我们能不能在 C++20 上推出。
|
||||
* 一个标准的网络库，但是还没办法确定我们能否在 C++20 上推出。
|
||||
|
||||
此外：
|
||||
|
||||
```
|
||||
Contracts（运行时检查的先决条件、后置条件、和断言）可能对许多人都非常重要。
|
||||
date 和 time-zone 支持库可能对许多人（行业）非常重要。
|
||||
```
|
||||
* Contracts（运行时检查的先决条件、后置条件、和断言）可能对许多人都非常重要。
|
||||
* date 和 time-zone 支持库可能对许多人（行业）非常重要。
|
||||
|
||||
**Register：最后你还有需要向读者说的话吗？**
|
||||
**<i>Register：</i>您还有想对读者们说的话吗？**
|
||||
|
||||
**Stroustrup：**如果 C++ 标准化委员会能够专注于重大问题，去解决重大问题，那么 C++20 将会是非常优秀的。但是在 C++20 推出之前，我们的 C++17 仍然是非常好的，它将改变很多人关于 C++ 已经落伍的旧印象。®
|
||||
<b><i>Stroustrup：</i></b>如果 C++ 标准化委员会能够专注于重大问题，去解决重大问题，那么 C++20 将会非常优秀。但是在 C++20 推出之前，我们还有 C++17；无论如何，它仍然远超许多人对 C++ 的旧印象。®
|
||||
|
||||
------
|
||||
|
||||
@ -151,7 +141,7 @@ via: https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/
|
||||
作者：[Thomas Claburn][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[qhwdw](https://github.com/qhwdw)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[thecyanbird](https://github.com/thecyanbird)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -160,4 +150,4 @@ via: https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/
|
||||
[2]: https://www.vasamuseet.se/en/vasa-history/disaster
|
||||
[3]: http://open-std.org/JTC1/SC22/WG21/
|
||||
[4]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md
|
||||
[5]: https://go.theregister.co.uk/tl/1755/shttps://continuouslifecycle.london/
|
||||
[5]: https://go.theregister.co.uk/tl/1755/shttps://continuouslifecycle.london/
|
||||
|
||||
Loading…
Reference in New Issue
Block a user