在某些行业里，人们可以根据一些测量标准判定一个人的生产力。比如，如果你是一个零件制造商，可以通过一个月你能够制造的零件数量来确定你的生产效率。如果你在客户服务中心工作，你解答了多少个客户来电，你的平均解答时间都会成为评判你的生产效率的依据。这些都是相当简单的案例，但即便你是一位医生，也可以通过你主刀的临床手术次数或者一个月你确诊的患者数量来确定你的生产效率。无论这些评判标准正确与否，但它们提供了一个通用的方法来评断一个人在给定时间内的执行能力。

然而在 IT 这方面，通过上述方法来衡量一个人的生产力是不可能的，因为 IT 有太多的变化性。比如，通过一个开发者编写的代码行数来衡量开发者所用的时间看起来很诱人。但是，编程的语言很大程度上能影响到根据这种方法得到的结论。因为一种编程语言的一行代码比用其他编程语言编写所花费的时间和难度可能会明显的多或少。

它总是这样不可捉摸吗？多年以前，你可能听说过或者经历过根据功能点来衡量 IT 工作人员的生产效率。这些措施是针对开发者们能够创建的关键特征来衡量开发者的生产效率的。但这种方法在今天也变得逐渐难以实施，开发者经常将可能已有的逻辑封装进内部，比如，按供应商来整合功能点。这使得仅仅是基于功能点的数目来估量生产效率难度加大。

这两个例子能够阐述为什么当我们 CIO 之间谈论 IT 生产效率的时候有时会引起争论。考虑以下这个假想中的谈话：

IT leader：“天啊，我想这些开发者一定很厉害。”

HR：“真的假的，他们做了什么？”

IT leader：“他们做了个相当好的应用。”

HR：“好吧，那他们比那些做了 10 个应用的开发者更好吗”

IT leader：“这要看你怎么理解 ‘更好’。”

这个对话比较有代表性。当我们处于上述的这种交谈时，这里面有太多的主观因素导致我们很难回答这个问题。当我们用一种有意义的方法来测试 IT 的效率时，类似上述谈话的这种问题仅仅是冰山一角。这不仅仅使谈话更加困难－它还会使 CIO 们很难展示他们的团队在商业上的价值。

确实这不是一个新出现的问题。我已经花费差不多 30 年的时间来思考这个问题。我得出的结论是我们真的不应该在谈论 IT 的生产效率这件事上面相互烦扰－因为我们永远不可能有结论。

我认为我们需要在改变这种对话同时停止根据生产能力和成本来谈论 IT 的生产效率，将目光集中于衡量 IT 的整体商业价值上。重申一下，这个过程不会很容易。商业价值的实现是一件困难的事情。但如果 CIO 们能够和商业人员合作来解决这个问题，就可以将实际价值变的更加科学而非一种艺术形式。

via: https://enterprisersproject.com/article/2016/8/why-measuring-it-productivity-so-challenging

作者：Anil Cheriyan 译者：LemonDemo, WangYueScream 校对：wxy

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

JavaScript 和其他编程语言有一个很大的不同，它不像单纯的一个语言，而像一个由众多方言组成大家族。

从 2009 年 CoffeeScript 出现开始，近几年出现了大量基于 JavaScript 语言，或者叫方言，例如 ES6、TypeScript、Elm 等等。它们都有自己的优势，且都可以被完美编译成标准 JavaScript。

所以，继上周的前端框架篇，今天带来 JavaScript 现状之方言篇，看一下大家对于 JavaScript 的方言是怎么选择的。

声明：下面的部分结论来自部分数据，这是在我想要展示完整数据时找到的最好的办法，这便于我分享我的一些想法。

注意：如果你还没有参与这个调查，现在就来参加吧，可以花十分钟完成调查然后再回来看这篇文章。

认知度

首先，我想看一下参与问卷调查的人是否知道下面六种语言：

• 经典的 JavaScript: 97%
• ES6: 98%
• CoffeeScript: 99%
• TypeScript: 98%
• Elm: 66%
• ClojureScript: 77%

你可能觉得 100% 的人都应该知道『经典的 JavaScript 』，我想是有人无法抵抗在一个 JavaScript 调查中投『我从来没有听说过 JavaScript 』这个选项的强大诱惑吧……

几乎所有人都知道 ES6、CoffeeScript 和 TypeScript 这三种语言，比较令我惊讶的是 TypeScript 竟然会稍微落后于 ES6 和 CoffeeScript。

另一方面，Elm 和 ClojureScript 得分就要低得多，当然这也有道理，因为它们跟自己的生态环境绑定的比较紧密，也很难在已有的 App 中进行使用。

兴趣度

接下来，让我们一起看一下，哪一种方言吸引新开发者的能力更强一些：

要注意，该表是统计该语言对从未使用过它们的用户的吸引度，因为只有很少人没有用过经典 JavaScript，所以『经典 JavaScript 』这一列的数值很低。

ES6的数值很有趣：已有很大比例的用户在使用 ES6 了，没有用过的人中的绝大部分（89%）也很想学习它。

TypeScript 和 Elm 的状态差不多：用过的人不多，但感兴趣的比例表现不错，分别是 53% 和 58%。

如果让我预测一下，那我觉得 TypeScript 和 Elm 都很难向普通的 JavaScript 开发者讲明自己的优势。毕竟如果开发者只懂 JavaScript 的话，你很难解释清楚静态类型的好处。

另外，只有很少开发者用过 CoffeeScript，而且很明显几乎没人想去学。我觉得我该写一本 12 卷厚的 CoffeeScript 百科全书了……

满意度

现在是最重要的问题的时间了：有多少开发者用过这些语言，有多少人还想继续使用这些方言呢？

虽然经典 JavaScript 拥有最多的用户量，但就满意度来说 ES6 才是大赢家，而且我想现在已经能安全的说，ES6 可以作为开发 JavaScript App 默认的语言。

TypeScript 和 Elm 有相似的高满意度，都在 85% 上下。然后，只有可怜的 17% 的开发者会考虑继续使用 CoffeeScript。

快乐度

最后一个问题，我问大家在用现在的方式写 JavaScript 时是否感到快乐：

这个问题的答案和上一个问题的满意度想匹配：平均分达到 3.96 分（1 - 5 分），大家在使用 JavaScript 时候确实是快乐的。

不过很难说高分是因为 JavaScript 最近的一些改进造成的呢，还是发现 JavaScript 可能（仅仅是可能）没有大家认为的那么讨厌。总之，JavaScript 令人满意。

总结

如果说上次的赢家是 React 和 Vue，那此次调查的冠军毫无争议是 ES6 了。 ES6 并带来没有开天辟地的变化，但整个社区都还是很认可当前 JavaScript 演进方向的。

我觉得一年之后我们再来一次这样的调查，结果会很有趣。同时也可以关注一下 TypeScript、Elm 还有ClojureScript 有没有继续进步。

个人认为，当前 JavaScript 大家庭百花齐放的现象还只是一个开始，或许几年之后 JavaScript 就会变得非常不同了。

结语 & 敬请期待

对于我这样的调查来说数据越多就意味着数据越准确！越多人参加这个调查，那就越能代表整个 JavaScript 社区。

所以，我十分希望你能帮忙分享这个调查问卷：

• 在 Twitter 上
• 在 Facebook 上

另外，如果你想收到我下一个调查结果分析，前往 调查问卷主页 并留下自己的邮箱吧。

via: https://medium.com/@sachagreif/the-state-of-javascript-javascript-flavors-1e02b0bfefb6

作者：Sacha Greif 译者：eriwoon 校对：wxy

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

汽车可不单单是由引擎和华丽外壳组成的，汽车里还有许许多多的计算部件，而 Linux 就在它们里面跑着。

Linux 不只运行在你的服务器和手机（安卓）上。它还运行在你的车里。当然了，没人会因为某个车载系统而去买辆车。但是 Linux 已经为像丰田、日产、捷豹路虎这些大型汽车制造商提供了信息娱乐系统、平视显示以及其 联网汽车 （ connected car ） 的 4G 与 Wi-Fi 系统，而且 Linux 即将登陆福特汽车、马自达、三菱、斯巴鲁。

如今，所有的 Linux 和开源汽车软件的成果都已经在 Linux 基金会的 Automotive Grade Linux （AGL）项目下统一标准化了。

传统软件公司也进入了移动物联网领域。 Movimento、甲骨文、高通、Texas Instruments、UIEvolution 和 VeriSilicon 都已经加入 Automotive Grade Linux（AGL）项目。 AGL 是一个相互协作的开源项目，志在于为联网汽车打造一个基于 Linux 的通用软件栈。

“随着联网汽车技术和信息娱乐系统需求的快速增长，AGL 过去几年中得到了极大的发展，” Linux 基金会汽车总经理 Dan Cauchy 如是说。

Cauchy 又补充道，“我们的会员基础不单单只是迅速壮大，而且通过横跨不同的业界实现了多元化，从半导体和车载软件到 IoT 和连接云服务。这是一个明显的迹象，即联网汽车的革命已经间接影响到许多行业纵向市场。”

这些公司在 AGL 发布了新的 AGL Unified Code Base (UCB) 之后加入了 AGL 项目。这个新的 Linux 发行版基于 AGL 和另外两个汽车开源项目： Tizen 和 GENIVI Alliance 。 UCB 是第二代 Linux 汽车系统。它从底层开始开发，一直到特定的汽车应用软件。它能处理导航、通信、安全、安保和信息娱乐系统。

“汽车行业需要一个标准的开源系统和框架来让汽车制造商和供应商能够快速地将类似智能手机的功能带入到汽车中来。” Cauchy 说。“这个新的发行版将 AGL、Tizen、GENIVI 项目和相关开源代码中的精华部分整合进 AGL Unified Code Base （UCB）中，使得汽车制造商能够利用一个通用平台进行快速创新。 在汽车中采用基于 Linux 的系统来实现所有功能时， AGL 的 UCB 发行版将扮演一个重大的角色。”

他说得对。自从 2016 年 1 月发布以来，已有四个汽车公司和十个新的软件厂商加入了 AGL。Esso，如今的 Exxon， 曾让 “把老虎装入油箱” 这条广告语出了名。我怀疑 “把企鹅装到引擎盖下” 这样的广告语是否也会变得家喻户晓，但是它却道出了事实。 Linux 正在慢慢成为 21 世纪汽车的主要操作系统。

via: http://www.zdnet.com/article/the-linux-in-your-car-movement-gains-momentum/

作者：Steven J. Vaughan-Nichols 译者：XLCYun 校对：wxy

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

Linux 系统在早期的时候被人们嘲笑，它什么也干不了。而现在，Linux 无处不在！

我当时还是个在巴西学习计算机工程的大三学生，并同时在一个全球审计和顾问公司兼职系统管理员。公司决定用 Oracle 数据库开发一些企业资源计划（ERP）软件。因此，我得以在 Digital UNIX OS (DEC Alpha) 进行训练，这个训练颠覆了我的三观。

UNIX 系统非常的强大，而且给予了我们对机器上包括存储系统、网络、应用和其他一切的绝对控制权。

我开始在 ksh 和 Bash 里编写大量的脚本让系统进行自动备份、文件传输、提取转换加载（ETL）操作、自动化 DBA 日常工作，还为各种不同的项目创建了许多服务。此外，调整数据库和操作系统的工作让我更好的理解了如何让服务器以最佳方式运行。在那时，我在自己的个人电脑上使用的是 Windows 95 系统，而我非常想要在我的个人电脑里放进一个 Digital UNIX，或者哪怕是 Solaris 或 HP-UX 也行，但是那些 UNIX 系统都得在特定的硬件才能上运行。我阅读了所有的系统文档，还找过其它的书籍以求获得更多的信息，也在我们的开发环境里对这些疯狂的想法进行了实验。

后来在大学里，我从我的同事那听说了 Linux。我那时非常激动的从还在用拨号方式连接的因特网上下载了它。在我的正宗的个人电脑里装上 UNIX 这类系统的这个想法真是太酷了！

Linux 不同于 UNIX 系统，它设计用来在各种常见个人电脑硬件上运行，在起初，让它开始工作确实有点困难，Linux 针对的用户群只有系统管理员和极客们。我为了让它能运行，甚至用 C 语言修改了驱动软件。我之前使用 UNIX 的经历让我在编译 Linux 内核，排错这些过程中非常的顺手。由于它不同于那些只适合特定硬件配置的封闭系统，所以让 Linux 跟各种意料之外的硬件配置一起工作真的是件非常具有挑战性的事。

我曾见过 Linux 在数据中心获得一席之地。一些具有冒险精神的系统管理员使用它来帮他们完成每天监视和管理基础设施的工作，随后，Linux 作为 DNS 和 DHCP 服务器、打印管理和文件服务器等赢得了更多的使用。企业曾对 Linux 有着很多顾虑（恐惧，不确定性，怀疑(FUD:fear, uncertainty and doubt)）和诟病：谁是它的拥有者？由谁来支持它？有适用于它的应用吗？

但现在看来，Linux 在各个地方进行着逆袭！从开发者的个人电脑到大企业的服务器；我们能在智能手机、智能手表以及像树莓派这样的物联网（IoT）设备里找到它。甚至 Mac OS X 有些命令跟我们所熟悉的命令一样。微软在制造它自己的发行版，在 Azure 上运行，然后…… Windows 10 要装备 Bash。

有趣的是 IT 市场会不断地创造并迅速的用新技术替代，但是我们所掌握的 Digital UNIX、HP-UX 和 Solaris 这些旧系统的知识还依然有效并跟 Linux 息息相关，不论是为了工作还是玩。现在我们能完全的掌控我们的系统，并使它发挥最大的效用。此外，Linux 有个充满热情的社区。

我真的建议想在计算机方面发展的年轻人学习 Linux，不论你处于 IT 界里的哪个分支。如果你深入了解了一个普通的家用个人电脑是如何工作的，你就可以以基本相同的方式来面对任何机器。你可以通过 Linux 学习最基本的计算机知识，并通过它建立能在 IT 界任何地方都有用的能力！

via: https://opensource.com/life/16/8/revenge-linux

作者：Daniel Carvalho 译者：H-mudcup 校对：wxy

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

当我们比较 Android 与 iPhone 的时候，很显然 Android 具有一定的优势，而 iPhone 则在一些关键方面更好。但是，究竟哪个比较好呢？

对 Android 与 iPhone 比较是个个人的问题。

就好比我来说，我两个都用。我深知这两个平台的优缺点。所以，我决定分享我关于这两个移动平台的观点。另外，然后谈谈我对新的 Ubuntu 移动平台的印象和它的优势。

iPhone 的优点

虽然这些天我是个十足的 Android 用户，但我必须承认 iPhone 在某些方面做的是不错。首先，苹果公司在他们的设备更新方面有更好的成绩。这对于运行着 iOS 的旧设备来说尤其是这样。反观 Android ，如果不是谷歌亲生的 Nexus，它最好也不过是一个更高端的运营商支持的手机，你将发现它们的更新少的可怜或者根本没有。

其中 iPhone 做得很好的另一个领域是应用程序的可用性。展开来说，iPhone 应用程序几乎总是有一个简洁的外观。这并不是说 Android 应用程序就是丑陋的，而是，它们可能只是没有像 iOS 上一样的保持不变的操控习惯和一以贯之的用户体验。两个典型的例子， Dark Sky (天气)和 Facebook Paper 很好表现了 iOS 独有的布局。

再有就是备份过程。 Android 可以备份，默认情况下是备份到谷歌。但是对应用数据起不了太大作用。对比 iPhone ，iCloud 基本上可以对你的 iOS 设备进行了完整备份。

iPhone 令我失望的地方

对 iPhone 来说，最无可争辩的问题是它的硬件限制要比软件限制更大，换句话来说，就是存储容量问题。

你看，对于大多数 Android 手机，我可以买一个容量较小的手机，然后以后可以添加 SD 卡。这意味着两件事：第一，我可以使用 SD 卡来存储大量的媒体文件。其次，我甚至可以用 SD 卡来存储“一些”我的应用程序。而苹果完全不能这么做。

另一个 iPhone 让我失望的地方是它提供的选择很少。备份您的设备？希望你喜欢 iTunes 或 iCloud 吧。但对一些像我一样用 Linux 的人，那就意味着，我唯一的选择便是使用 iCloud。

要公平的说，如果你愿意越狱，你的 iPhone 还有一些其他解决方案的，但这并不是这篇文章所讲的。 Android 的 解锁 root 也一样。本文章针对的是两个平台的原生设置。

最后，让我们不要忘记这件看起来很小的事—— iTunes 会删掉用户的音乐，因为它认为和苹果音乐的内容重复了……或者因为一些其它的类似规定。这不是 iPhone 特有的情况？我不同意，因为那些音乐最终就是在 iPhone 上没有了。我能十分肯定地这么说，是因为不管在哪里我都不会说这种谎话。

Android 的优点

Android 给我最大的好处就是 iPhone 所提供不了的：选择。这包括对应用程序、设备以及手机是整体如何工作的选择。

我爱桌面小工具！对于 iPhone 用户来说，它们也许看上去很蠢。但我可以告诉你，它们可以让我不用打开应用程序就可以看到所需的数据，而无需额外的麻烦。另一个类似的功能，我喜欢安装定制的桌面界面，而不是我的手机默认的那个！

最后，我可以通过像 Airdroid 和 Tasker 这样的工具给我的智能手机添加计算机级的完整功能。AirDroid 可以让我把我的 Android 手机当成带有一个文件管理和通信功能的计算机——这可以让我可以轻而易举的使用鼠标和键盘。Tasker 更厉害，我可以用它让我手机根据环境变得可联系或不可联系，当我设置好了之后，当我到会议室之后我的手机就会自己进入会议模式，甚至变成省电模式。我还可以设置它当我到达特定的目的地时自动启动某个应用程序。

Android 让我失望的地方

Android 备份选项仅限于特定的用户数据，而不是手机的完整克隆。如果不解锁 root，要么你只能听之任之，要么你必须用 Android SDK 来解决。期望普通用户会解锁 root 或运行 SDK 来完成备份（我的意思是一切都备份）显然是一个笑话。

是的，谷歌的备份服务会备份谷歌应用程序的数据、以及其他相关的自定义设置。但它是远不及我们所看到的苹果服务一样完整。为了完成类似于苹果那样的功能，我发现你就要么必须解锁 root ，要么将其连接到一个在 PC 机上使用一些不知道是什么的软件来干这个。

不过，公平的说，我知道使用 Nexus 的人能从该设备特有的完整备份服务中得到帮助。对不起，但是谷歌的默认备份方案是不行的。对于通过在 PC 上使用 adb (Android Debug Bridge) 来备份也是一样的——不会总是如预期般的恢复。

等吧，它会变好的。经过了很多失败的失望和挫折之后，我发现有一个应用程序，看起来它“可能”提供了一点点微小的希望，它叫 Helium 。它不像我发现的其他应用程序那样拥有误导性的和令人沮丧的局限性，Helium 最初看起来像是谷歌应该一直提供的备份应用程序——注意，只是“看起来像”。可悲的是，它绊了我一跤。第一次运行时，我不仅需要将它连接到我的计算机上，甚至使用他们提供的 Linux 脚本都不工作。在删除他们的脚本后，我弄了一个很好的老式 adb 来备份到我的 Linux PC 上。你可能要知道的是：你需要在开发工具里打开一箩筐东西，而且如果你运行 Twilight 应用的话还要关闭它。当 adb 的备份选项在我的手机上不起作用时，我花了一点时间把这个搞好了。

最后，Android 为非 root 用户也提供了可以轻松备份一些如联系人、短信等简单东西的选择。但是，要深度手机备份的话，以我经验还是通过有线连接和 adb。

Ubuntu 能拯救我们吗？

在手机领域，通过对这两大玩家之间的优劣比较，我们很期望从 Ubuntu 看到更好的表现。但是，迄今为止，它的表现相当低迷。

我喜欢开发人员基于这个操作系统正在做的那些努力，我当然想在 iPhone 和 Android 手机之外有第三种选择。但是不幸的是，它在手机和平板上并不受欢迎，而且由于硬件的低端以及在 YouTube 上的糟糕的演示，有很多不好的传闻。

公平来说，我在以前也用过 iPhone 和 Android 的低端机，所以这不是对 Ubuntu 的挖苦。但是它要表现出准备与 iPhone 和 Android 相竞争的功能生态时，那就另说了，这还不是我现在特别感兴趣的东西。在以后的日子里，也许吧，我会觉得 Ubuntu 手机可以满足我的需要了。

Android 与 iPhone 之争：为什么 Android 将终究赢得胜利

忽视 Android 那些痛苦的缺点，它起码给我了选择。它并没有把我限制在只有两种备份数据的方式上。是的，一些 Android 的限制事实上是由于它的关注点在于让我选择如何处理我的数据。但是，我可以选择我自己的设备，想加内存就加内存。Android 可以我让做很多很酷的东西，而 iPhone 根本就没有能力这些事情。

从根本上来说， Android 给非 root 用户提供了访问手机功能的更大自由。无论是好是坏，这是人们想要的一种自由。现在你们其中有很多 iPhone 的粉丝应该感谢像 libimobiledevice 这样项目带来的影响。看看苹果阻止 Linux 用户所做的事情……然后问问你自己：作为一个 Linux 用户这真的值得吗？

发表下评论吧，分享你对 iPhone 、Android 或 Ubuntu 的看法。

via: http://www.datamation.com/mobile-wireless/android-vs.-iphone-pros-and-cons.html

作者：Matt Hartley 译者：jovov 校对：wxy

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

Andreia Gaita 在 OSCON 开源大会上发表了一个题为跨平台开发者的自白的演讲。她长期从事于开源工作，并且为 Mono 工程（LCTT 译注：一个致力于开创 .NET 在 Linux 上使用的开源工程）做着贡献，主要以 C#/C++ 开发。Andreia 任职于 GitHub，她的工作是专注构建 Visual Studio 的 GitHub 扩展管理器。

我在她发表演讲前就迫不及待的想要问她一些关于跨平台开发的事，问问她作为一名跨平台开发者在这 16 年之中学习到了什么。

在你开发跨平台代码中，你使用过的最简单的和最难的代码语言是什么?

我很少讨论某种语言的好坏，更多是讨论是那些语言有哪些库和工具。语言的编译器、解释器以及构建系统决定了用它们做跨平台开发的难易程度（或者它们是否可能做跨平台开发），可用的 UI 库和对本地系统的访问能力决定了与该操作系统集成的紧密程度。按照我的观点，我认为 C# 最适合完成跨平台开发工作。这种语言自身包括了允许快速的本地调用和精确的内存映射的功能，如果你希望你的代码能够与系统和本地函数库进行交互就需要这些功能。而当我需要非常特殊的系统功能时，我就会切换到 C 或者 C++。

你使用的跨平台开发工具或者抽象层有哪些？

我的大部分跨平台工作都是为其它需要开发跨平台应用的人开发工具、库和 绑定 （ binding ） ，一般是用 MONO/C# 和 C/C++。在抽象的层面我用的不多，更多是在 glib 库和 友元 （ friends ） 方面。大多数时候，我用 Mono 去完成各种跨平台应用的，包括 UI，或者偶然在游戏开发中用到 Unity3D 的部分。我经常使用 Electron（LCTT 译注：Atom 编辑器的兄弟项目，可以用 Electron 开发桌面应用)。

你接触过哪些构建系统？它们之间的区别是由于语言还是平台的不同？

我试着选择适合我使用的语言的构建系统。那样，就会很少遇到让我头疼的问题（希望如此）。它需要支持平台和体系结构间的选择、构建输出结果位置可以智能些（多个并行构建），以及易配置性等。大多数时候，我的项目会结合使用 C/C++ 和 C#，我要从同一源代码同时构建不同的配置环境（调试、发布、Windows、OSX、Linux、Android、iOS 等等），这通常需要为每个构建的输出结果选择带有不同参数的不同编译器。构建系统可以帮我做到这一切而不用让我（太）费心。我时常尝试着用不同的构建系统，看看有些什么新的变化，但是最终，我还是回到了使用 makefile 的情况，并结合使用 shell 和批处理脚本或 Perl 脚本来完成工作（因为如果我希望用户来构建我的软件，我还是最好选择一种到处都可以用的命令行脚本语言）。

你怎样平衡在这种使用统一的用户界面下提供原生的外观和体验的需求呢？

跨平台的用户界面的实现很困难。在过去几年中我已经使用了一些跨平台 GUI，并且我认为这些事情上并没有最优解。基本上有两种选择。你可以选择一个跨平台工具去做一个并不是完全适合你所有支持的平台的 UI，但是代码库比较小，维护成本比较低。或者你可以选择去开发针对平台的 UI，那样看起来更原生，集成的也更好，但是需要更大的代码库和更高的维护成本。这种决定完全取决于 APP 的类型、它有多少功能、你有多少资源，以及你要把它运行在多少平台上？

最后，我认为用户比较接受这种“一个 UI 打通关”了，就比如 Electron 框架。我有个 Chromium + C + C# 的框架侧项目，有一天我希望可以用 C# 构建 Electron 型的 app，这样的话我就可以做到两全其美了。

构建/打包系统的依赖性对你有影响吗 ?

我依赖的使用方面很保守，我被崩溃的 ABI（LCTT 译注：应用程序二进制接口）、冲突的符号、以及丢失的包等问题困扰了太多次。我决定我要针对的操作系统版本，并选择最低的公有部分来使问题最小化。通常这就意味着有五种不同的 Xcode 和 OSX 框架库，要在同样的机器上相应安装五种不同的 Visual Studio 版本，多种 clang（LCTT 译注：C语言、C++、Object-C、C++ 语言的轻量级编译器）和 gcc 版本，一系列的运行着各种发行版的虚拟机。如果我不能确定我要使用的操作系统的包的状态，我有时就会静态连接库，有时会子模块化依赖以确保它们一直可用。大多时候，我会避免这些很棘手的问题，除非我非常需要使用他们。

你使用持续集成（CI）、代码审查以及相关的工具吗？

基本每天都用。这是保持高效的唯一方式。我在一个项目中做的第一件事情是配置跨平台构建脚本，保证每件事尽可能自动化完成。当你面向多平台开发的时候，持续集成是至关重要的。没有人能在一个机器上构建各种平台的不同组合，并且一旦你的构建过程没有包含所有的平台，你就不会注意到你搞砸的事情。在一个共享式的多平台代码库中，不同的人拥有不同的平台和功能，所以保证质量的唯一的方法是跨团队代码审查结合持续集成和其他分析工具。这不同于其他的软件项目，如果不使用相关的工具就会面临失败。

你依赖于自动构建测试，或者倾向于在每个平台上构建并且进行本地测试吗？

对于不包括 UI 的工具和库，我通常使用自动构建测试。如果有 UI，两种方法我都会用到——针对已有的 GUI 工具的可靠的、可脚本化的 UI 自动化少到几乎没有，所以我要么我去针对我要跨我所支持的平台创建 UI 自动化工具，要么手动进行测试。如果一个项目使用了定制的 UI 库（比如说一个类似 Unity3D 的 OpenGL UI），开发可编程的自动化工具并自动化大多数工作就相当容易。不过，没有什么东西会像人一样双击就测试出问题。

如果你要做跨平台开发，你喜欢用跨编辑器的构建系统，比如在 Windows 上使用 Visual Studio，在 Linux 上使用 Qt Creator，在 Mac 上使用 XCode 吗？还是你更趋向于使用 Eclipse 这样的可以在所有平台上使用的单一平台？

我喜欢使用跨编辑器的构建系统。我更喜欢在不同的IDE上保存项目文件（这样可以使增加 IDE 变得更容易），通过使用构建脚本让 IDE 在它们支持的平台上去构建。对于一个开发者来说编辑器是最重要的工具，学习它们是需要花费时间和精力的，而它们是不可相互替代的。我有我自己喜欢的编辑器和工具，每个人也可以使用他们最喜爱的工具。

在跨平台开发的时候，你更喜欢使用什么样的编辑器、开发环境和 IDE 呢？

跨平台开发者被限制在只能选择可以在多数平台上工作的所共有的不多选择之一。我爱用 Visual Studio，但是我不能依赖它完成除 Windows 平台之外的工作（你可能不想让 Windows 成为你的主要的交叉编译平台），所以我不会使用它作为我的主要 IDE。即使可以，跨平台开发者的核心技能也是尽可能的了解和使用大量的平台。这就意味着必须很熟悉它们——使用该平台上的编辑器和库，了解这种操作系统及其适用场景、运行方式以及它的局限性等。做这些事情就需要头脑清醒（我的捷径是加强记忆），我必须依赖跨平台的编辑器。所以我使用 Emacs 和 Sublime。

你之前和现在最喜欢的跨平台项目是什么？

我一直很喜欢 Mono，并且得心应手，其它的项目大部分都是以某种方式围绕着它进行的。Gluezilla 是我在多年前开发的一个 Mozilla 绑定 （ binding ） ，可以把 C# 开发的应用嵌入到 Web 浏览器页面中，并且看起来很有特色。我开发过一个 Winform 应用，它是在 linux 上开发的，它可以在 Windows 上运行在一个 Mozilla 浏览器页面里嵌入的 GTK 视图中。CppSharp 项目（以前叫做 Cxxi，更早时叫做 CppInterop）是一个我开始为 C++ 库生成 C# 绑定 （ binding ） 的项目，这样就可以在 C# 中调用、创建实例、子类化 C++ 类。这样，它在运行的时候就能够检测到所使用的平台，以及用来创建本地运行库的是什么编译器，并为它生成正确的 C# 绑定 （ binding ） 。这多么有趣啊。

你怎样看跨平台开发的未来趋势呢？

我们构建本地应用程序的方式已经改变了，我感觉在各种桌面操作系统的明显差异在慢慢变得模糊；所以构建跨平台的应用程序将会更加容易，而且对系统的集成也不需要完全本地化。不好的是，这可能意味着应用程序易用性更糟，并且在发挥操作系统特性方面所能做的更少。库、工具以及运行环境的跨平台开发是一种我们知道怎样做的更好，但是跨平台应用程序的开发仍然需要我们的努力。

via: https://opensource.com/business/16/5/oscon-interview-andreia-gaita

作者：Marcus D. Hanwell 译者：vim-kakali 校对：wxy

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