D6500a70a3e94c445f6b73d80db62162
个人日常工作中所使用的一些工具

很多朋友会好奇我每天工作的时候用的一些工具和工作流程什么的。总体来说,我还是很相信“工欲善其事,必先利其器”这句话的。今天就介绍 (以及吐槽) 一下我现在正在“服役”的 LINE Live iOS 团队和我自己所偏好使用的一些工具吧。

开发设备

LINE 对开发者职位的员工是相当大方的,入职肯定是当年的高配或者顶配设备。一般是最新款的 rMBP 15 寸和 iMac 27 寸自选。如果选择了 iMac 的话,还会搭配一台 12 寸的 MacBook 作为开会或者 presentation 时候使用的电脑。另外,不论如何选择,会配置一台 27 寸的 Dell 外接显示器,你可以根据需求选择 4K 版本或者 2K 版本。

工作设备自发售日期起满三年,会有设备部门的同事询问需不需要更新电脑。更新的话就是当年的顶配整体换掉原来的设备。我最近入职正好三年,顺势也换了一波,现在我用的是主力一台 16GB,2T Fusion 的 iMac 27-inch 2017,开会一台 MacBook 2016,以及一个 4K 外接显示器。

本机编译速度暂时满意。

工位一瞥:

项目管理

这方面更多的是公司的选择,我们使用了 Atlassian 的一套方案。

策划,会议记录

使用 Confluence 搭建的 wiki。像是公司章程,社员指引什么的不必说,都是热门的 wiki 条目。关于项目的策划和会议记录,也都使用 wiki 的方式进行记录,并在团队之间交流。用 wiki 记录策划案的好处在于,所有的更改都有迹可循,历史版本也都无法篡改,这让开发侧在延长工期的时候”有迹可循“,也能让策划组在更改需求的”稍有顾忌“。 :)

但就算如此,一份需求改个三四十次依然是家常便饭。心还是累。

会议记录的话毫无创意,依然使用了 Confluence。其实个人感觉这很不适合,因为这样一来,会议记录员的职责就被无限放大了。通常会议的发起者同时需要担任会议记录者,这样的好处是可以预先准备会议的 wiki 页面资料,让参会者尽快进入会议上下文。但是 wiki 本身的互动能力比较弱,基本只有全文的 comment,想要只对某一句话或者某个部分进行评注和交流,十分困难。如果有可能的话希望能换成更加互动的方式。

总体来说,Atlassian 毕竟是大厂,Confluence 的这一套东西相当稳定,搜索功能也很满意。另外,公司内的文化还是很自由的,除了某些极为机密的资料,其他团队的 wiki 都是开放搜索和阅览的。有时候比较闲就会有时间去看一看别的 team 的撕逼交流方式,以及某些私有格式和信息,都很有意思。

Issue 追踪

一套叫做 LINE Bug Tracking System 的东西,其实就是自架的 JIRA。其实我们不仅用它来做 issue tracking,也变相相当于开发的进度管理:Manager 评估和分解任务后,为每个小任务创建 issue,然后分发给对应的负责人;负责人在实现后根据 merge 和 deploy 的情况变更 issue 状态,并打上版本号,最后 QA 部门验证确认后关闭 issue。这样,只需要看当前版本的剩余 issue 数量就可以大体预估发布时间了。

当然另外一个主要用途就是修 bug。基本上 minor 级别的 bug 由 QA 和客户支持部门进行创建,然后团队的工程师每天抽出一点时间去进行认领。如果能够确定在某个未来版本进行修复,那么就进入到和新功能开发类似的流程中。对于 major 和以上级别的 issue,则是按照分工模块直接指派对应人员和预计修正版本。

我们没有使用任何热修复的手段,这主要得益于 QA 部门相当给力。他们有一整套行动规范和回归测试的列表,用来保证每次新版本发布的时候对现有功能也能够进行一定的测试。因为策划基本会把各种交互都进行考虑,所以 QA 部门会按照策划书对边界状况也进行确认。我自己软件开发做到今天,个人感觉,核心功能和实现与边界条件和错误处理所消耗的开发时间几乎是持平的。不过很多时候良好的架构可以让后者轻松不少。

交流

全公司使用 Slack 企业版作为聊天工具。Slack 的第三方支持和强大的各种 bot 在企业聊天工具里独树一帜,同时,公司也允许大家自己创建各种 bot。于是 Slack 频道里现在欣欣向荣,各种查询某个人的工位啊,查看某个会议室是否有空啊,中午随机点餐周围的外卖便当啦,让集成环境帮自己编译某个分支啦。公司为了鼓励员工打开脑洞创造机器人,还举行了 Slack bot 的总奖金 100 万日元的比赛。种种此类,LINE 整个公司环境对开发者来说还是相当友好的。

回到聊天和沟通的需求,除了搜索比较给力以外,Slack 其实和其他的一些聊天软件区别并不大。

开发工具

这大概是和开发者关系最紧密的部分了。LINE 在给开发者良好的环境这方面做的相当好,在提高效率方面很舍得花钱,这点必须要赞一下。

GitHub 企业版

这是显而易见的最优选。业余时间我也是 GitHub 的用户,所以上班和下班体验相同这一点给我带来的便利非常明显。LINE 的 GitHub 企业版的升级也紧跟 GitHub 本身的升级,所以各种新的 feature 都可以用到。我们的 iOS 团队在开发时使用 Pull Request 进行 merge 和 review,因为负责直播 app 的 Live 的 iOS 队伍比较小,所以简单暴力地采用全员 review 的方式。不过很多时候开发周期也比较紧张,对于代码和自己负责的部分比较远的情况,大概就是只能检查一下基本逻辑。这样的好处是团队全员都对整个项目有必要的了解,不存在某块代码只能某人来负责这种尴尬情况。

Zeplin

我们使用 Zeplin 来标注设计图并发送个工程师。Live 项目组的 Design 团队是韩国那边的,空间上的不同加上语言上的差异,造成了交流上异常困难。在引入 Zeplin 之前我们使用 wiki 的方式来进行 UI 标注,但是结果不是特别理想,韩国团队那边的办事风格显然没有日本这边严谨,所以很多地方会出现漏标或者错误。这时候要的沟通又经常由于翻译软件的问题,会出现各种花式误解。Zeplin 的话直接从 PS 或者 Sketch 的设计图中导出和标注,确实能省不少事儿。

但是设计团队对于 Zeplin 的掌握还欠火候,对于需要考虑响应式设计的地方也还是有评注不足的情况发生。但是这些大抵都是设计团队和设计师个人水平/经验的问题了。对于 Zeplin 这个工具本身而言的话,我是没有什么怨言的。

持续集成

持续集成的硬件上,我们采用了社内机房自架 Jenkins 的方式。具体的 infrastructure 细节我不是特别清楚,但是全社大概有数十个可以同时运行的 worker。CentOS 和 macOS 都有一些,对于我这样的 iOS 开发来说,那打交道的显然都是 Mac 的 worker 了。

Jenkins

top Created with Sketch.