概述
Why Scripting
Why Swift
使用 SPM 搭建开发框架
项目里的文件
将代码划分为 framework 和 executable
构建 Xcode 项目
开始动手
定义程序入口
Hello,World
增加依赖
安装/更新依赖
参数解析
Argument Parser
编写单测
安装工具
调试技巧
让开源社区加速你的开发
总结
概述
最近在工作中过程中参与了两款 Swift 命令行工具的开发::
Nezuko(未开源) ,一款面向美团壳工程的,类
create-react-app
的脚手架工具。ImportSanitizer[1],一款能够修复不规范头文件引用方式的自动化工具。
在整个开发过程中,我们体会到了 Swift 带来的一些变化,当然这里既有好的,也有坏的,不过总的来说,使用 Swift 进行脚本开发还是一件让人愉悦的事情,所以我们迫不及待的邀请你,也就是这篇文章的读者,和我们一起加入 Swift 开发的大军中!
这篇文章通过 Step-By-Step 的方式,指导你完成一个基于 Swift 的命令行工具,不过在开始之前,我们先聊聊为什么要写脚本,以及为什么选用 Swift。
Why Scripting
对于软件工程师来说,我们经常会遇到这样的工作,例如重命名设计师提供的图片素材,在海量的数据中提取一些特定信息。这种工作有一些共性,就是它的逻辑很简单,就像代码里的 if-else
一样,只要你够严谨,就一定能得到想要的答案,
但这种机械性的工作很容易因为人为的因素导致错误,例如手抖,眼瞎,以及间歇性失忆,哈哈,而这时候,机器会显得比人靠谱多了!
同时,重复同样的工作是一件低效的事情,我们完全可以通过编写相应的代码将任务自动化,这将极大的提升我们的工作效率。
当然可能有人会说,我还是自己弄吧,但你不觉得这种重复的,机械性的工作很无聊么,我们可是要改变世界的工程师啊!
Why Swift
至于为什么使用 Swift 写脚本,我想有人可能会给出这样的答案:
swift 真的太棒了,我喜欢 Swift,它是最好的语言!我要用它写后端,要用它写前端,用它写 iOS,写 Android,用它写 CLI,总之,我要用它解决一切的编程问题!
但说实话,这是一个很主观的判断,并不应该成为我们使用 Swift 写 CLI 的客观因素,在实际使用了一段时间后,我认为下面几个因素才是我们使用 Swift 编写脚本的主要原因:
降低了 App 开发者编写脚本的门槛,减少了上下文切换的负担
Swift 提供了一些真的很不错的内置库,例如 combine,core graphics,urlsession 等
可以将 App 里的代码引入脚本,避免重复工作
关于前两点,我想大家应该会比较好理解,毕竟每次在 Swift 代码和 Bash,Ruby,Python,JavaScript 中切换,会让我产生一种深深的抗拒感,另外在 iOS 上已经得到证明的 core graphics 有理由让我们相信它的品质,同时天然内置的 Combine 让我们在异步编程上有了很好的体验,这让我想起被 JavaScript 里 yield 支配的恐惧,问我为什么要用 yield,不妨来试试 React + Redux + Redux-Saga 的大礼包呀!
关于最后一点,我想展开说说,一方面是因为它基于我真实的开发体验,另一方面是它确实让我真正意识到 Swift 写脚本的优势所在。
在年初的时候,我曾经一度痴迷 SpriteKit,并尝试开发一款属于自己的横版过关游戏,这其中涉及到大量的图片处理,例如使用 Animation 的方式将多张静态图片整合成动态效果,大体的效果就像下面的 gif 一样
这背后的代码大概如下所示,通过读取相应顺序和数量的图片构建 gif 动画
Animation(
name: "Units/swordsman/male/attack/right",
frameCount: 8,
duration: 1.12,
tintColor: .blue
)
虽然看起来代码不多,手写一下就 ok 了,但你得知道,就这样一个杂兵角色,就会有攻击,跳跃,行走,跑动等等等动作,再加上各个方向,以及特殊效果,如果再考虑到,我们的游戏里面大概有 20 多个兵种和 4 个英雄,我想你大概已经体会到这个工作的痛苦了!
在一开始,我用的是 Ruby 来解决重复代码的生成工作,但这里为了减少上下文切换,我将采用 Swift 类型的伪代码来做展示,方便大家快速理解
let unitKinds = ["swordsman", "archer", "knight", "catapult"]
for kind in unitKinds {
guard let config = try? File(path: "\(kind.identifer)/Config") else {
continue
}
try codeGenerator.generateCode(from: config)
}
虽然这么写已经帮我节省了不少时间,但我还是得每次手动维护 unitKinds 数组,并保持它与游戏中的模型数据同步,这其实也挺烦人的,不是么?