开发者的自白_跨平台开发者的自白

开发者的自白

安德烈娅·盖塔 （ Andreia Gaita ）在今年的OSCON上发表了题为《 跨平台开发人员的自白》的演讲。 她是长期的开源和Mono贡献者，主要使用C＃/ C ++开发。 Andreia在GitHub工作，她专注于为Visual Studio构建GitHub扩展管理器。

在安德烈亚（Andreia）发言之前，我赶上了她的面纱，询问有关跨平台开发以及她作为跨平台开发人员16年的经验。

您发现最容易和最难开发的跨平台代码语言是什么？

与哪种语言是好的无关，而更多的是针对那些语言可用的库和工具。 可用于语言的编译器/解释器/生成系统确定了使用它们进行跨平台工作的难易程度（甚至是否可行），可用于UI和本机系统访问的库确定了与操作系统集成的深度。 考虑到这一点，我发现C＃是跨平台工作的最佳选择。 该语言本身包含允许快速本机调用和准确的内存映射的功能，如果您希望代码与OS和本机库对话，则确实需要此功能。 当我需要非常特定的OS集成时，我会切换到C或C ++。

您使用了哪些跨平台工具包/摘要？

我的大部分跨平台工作都是为其他人开发工具，库和绑定，以使用Mono / C＃和C / C ++开发跨平台应用程序。 除了glib和朋友之外，我在该级别上没有使用太多抽象。 对于包含UI的任何跨平台应用程序，我主要依靠Mono；对于偶尔的游戏开发，我主要依靠Unity3D。 我时不时和Electron一起玩。

您构建系统的方法是什么，它随语言或平台的不同而变化吗？

我尝试选择最适合我使用的语言的构建系统。 这样，它将（希望）减轻我的头痛。 它需要考虑平台和体系结构的选择，对构建工件位置（对于多个并行构建）要精明，并且要具有可配置性。 大多数时候，我有将C / C ++和C＃结合在一起的项目，我想从同一源代码树（Debug，Release，Windows，OSX，Linux，Android，iOS等）同时构建所有不同的配置。 ），并且通常需要选择并调用每个输出构建工件具有不同标志的不同编译器。 因此，构建系统必须让我完成所有这些工作，而又不能过多地干扰我。 我不时尝试不同的构建系统，只是为了看看有什么新功能，但是最后，我还是回到了makefile以及shell和批处理脚本或Perl脚本的组合来驱动它们（因为如果我想要用户，为了构建自己的东西，我最好选择一种随处可用的命令行脚本语言。

您如何在对本机外观的需求与对统一用户界面的需求之间取得平衡？

跨平台的用户界面很难！ 多年来，我已经实现了多个跨平台的GUI，这是我认为没有最佳解决方案的一件事。 基本上有两种选择。 您可以选择一个跨平台的GUI工具包，并以一个小的代码库和较低的维护成本，在所支持的所有平台上做一个不太合适的UI。 或者，您可以选择开发特定于平台的UI，这些UI外观和感觉都是本机的，并与更大的代码库和更高的维护成本很好地集成在一起。 决定实际上取决于应用程序的类型，它具有多少功能，拥有多少资源以及要运送到的平台数量。

最后，我认为使用Electron之类的框架，用户对“一个UI可以全部统治”的容忍度有所增加。 我有一个Chromium + C + C＃框架辅助项目，希望有一天能够让我用C＃构建Electron风格的应用程序，从而为我提供两全其美的方法。

对您而言，构建/打包依赖关系是否成问题？

对于依赖项的使用，我非常保守，因为它破坏了ABI，冲突的符号和缺少的软件包而被多次咬伤。 我确定要定位的操作系统版本，并选择依赖项中可用的最低公分母版本，以最大程度地减少问题。 这通常意味着拥有五个不同的Xcode和OSX Framework库副本，在同一台计算机上并排安装的五个不同版本的Visual Studio，多个clang和gcc版本以及一堆运行各种其他发行版的VM。 如果我不确定目标操作系统中的软件包状态，则有时会静态链接，有时会链接子模块依赖项，以确保它们始终可用。 最重要的是，除非我真的非常需要那里的东西，否则我会避免出现前沿优势。

您是否使用持续集成，代码审查和相关工具？

每时每刻！ 这是保持理智的唯一方法。 我在项目上要做的第一件事是设置跨平台的构建脚本，以确保所有内容尽早实现自动化。 当您针对多个平台时，CI是必不可少的。 每个人都不可能在一台机器上构建平台的所有不同组合，而且一旦不构建所有平台，就将在不知不觉中破坏某些东西。 在共享的多平台代码库中，不同的人拥有不同的平台和功能，因此，保证质量的唯一方法是将跨团队的代码审查与CI和其他分析工具结合使用。 它与其他软件项目没有什么不同，只是存在更多的故障点。

您是依靠自动构建测试，还是倾向于在每个平台上构建并在本地进行测试？

对于不包含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绑定，它允许C＃应用程序嵌入Web浏览器视图，而那是个麻烦。 有一次，我有一个基于Linux的Winforms应用程序，该应用程序在Windows上运行，并且其中带有嵌入式GTK视图，该视图正在运行Mozilla浏览器视图。 CppSharp项目（前身为Cxxi，前身为CppInterop）是我开始为C ++库生成C＃绑定的项目，以便您可以从C＃调用C ++类并为其创建实例，并为其子类化。 这样做的方式是，它将在运行时检测您将在哪个平台上运行，以及使用什么编译器来创建本机库并为其生成正确的C＃绑定。 那很有趣！

您认为未来的跨平台开发方向如何？

我们构建本机应用程序的方式已经在改变，我感觉各种桌面操作系统之间的视觉差异将变得更加模糊，从而使跨平台应用程序的构建变得更加容易，这些应用程序可以很好地集成而无需完全本机化。 不幸的是，这可能意味着在充分利用OS的潜力方面，应用程序的可访问性将变得更差，创新性也将降低。 我们知道如何很好地进行工具，库和运行时的跨平台开发，但是跨平台应用程序开发仍有许多工作要做。

翻译自: https://opensource.com/business/16/5/oscon-interview-andreia-gaita

开发者的自白