接手一个负分的 iOS 项目后我作了什么

半年前我加入一个刚刚拿到 A 轮资金的创业团队负责 iOS 项目。早期的时候公司生死未卜，只追求快速迭代找到一个正确的方向。这种早期默默无闻的团队也没什么工程追求，就是写的快就行了。可是肯定方向后要长期发展，就不能再野蛮生长了。 基于过去半年我在这个项目里的实践经验，和你们分享一下。

代码托管：自建 Gitlab

早期草根团队最省事的就是用 GitHub 了。可是团队人数增长后用 GitHub 的成本就很高了。普通的团队套餐每月每人 9 刀。另一个问题就是 GitHub 部署在国外，国内访问网络时常不稳定。听闻某跨国团队代码托管在 GitHub 上，某次重要会议期间 GitHub 没法正常访问。真是突如其来的父爱如山。 另一个缺点就是服务端若是要本身配置 CI 服务不太方便。若是部署在本身的服务器上，其余一些服务脚本也部署在一块儿，会有很大的自主权。 综合以后选择了主流的 Gitlab。

工程师的时间比机器贵

不少短视的团队以为配给工程师的设备太贵，挑个便宜点的就行了。一台好的电脑虽然贵点，但是长期下来节省下来的工程师的编译时间比机器贵多了。在设备上我跟公司建议那就配最新的 15 寸的 rmbp 呗，再来一个 dell 4K 显示器呗。后面发现键盘鼠标也重要啊，每一个人又补贴了 500 块的键鼠额度。 看到不少工程师还在用 air 开发，还有 mac mini 的。真的为这种傻逼公司感到心痛。我曾经在的某团队仍是 4 个终端用同一台电脑。每次编译的时候我就到南京路散个步。若是晚上要上线，能够去看个电影回来。

尽早招人

招人是团队发展过程当中很是重要的一环。 不少早期团队都低估了招人的难度和周期。由于不太知名的团队招人有两个缺点：

• 不能给出过高的薪水

  优秀的人才固然会比较市场上薪水。已经成名已久的 BAT 这种公司天然会有薪水的优点。创业公司虽然有期权，可是毕竟公司前途未卜。不少工程师也担忧公司会不会过阵子就倒闭的问题。

• 团队事情多且杂

  项目成熟后的迭代大可能是循序渐进，有稳定的节奏。每一个环节的都有很细分的专职人员。早期的项目由于项目仍是处于成长阶段，极可能半路作着看到直播火了，咱们加个直播的需求。或者作着作着发现竞品有个功能，管不了那么多咱们下个版本就上。或者 CEO 路过的时候忽然有了个想法，上线的时间又推后一下。

招人除了技术的硬指标，在早期团队还有一个工程团队文化的问题。一个几十我的的项目，里面某个特定的人的积极性对于项目实际上是不过重要的。他只要完成应该完成的工做。甚至和其余人不说话也影响不大。一个大的项目也不能由于任何一我的不在了就运行不下去。

可是早期团队，人就这么几个。有一我的对团队的使命认知不一致，平常行为里就会有不少摩擦。

我以前思考过团队文化是什么，怎么形容团队文化。后来看到一个说法感受挺贴切。文化是空气，无处不在。公司没有规定下班后社交平台上看到用户反馈须要你去回应，也不会规定你发现其余部门的产品有问题是不当回事仍是应该去和其余部门的人沟通，又或者看到一个更好的建议是否是要和公司提出来。这些行为背后的支撑就是团队文化。在团队里的人决定了价值观。

综合上面说的，招到一个匹配的技术人员，运气好的话几天就你能遇到，更常见的状况是可能要好几周的时间。固然若是情急之下招进来一我的，干了几个月后发现不合适就走了，对于团队的士气损害也挺大的。

因此考虑到项目将来的进展，要及时启动招人的计划。当你发现进度忙不过来的时候开始招人，这个时候你要抽时间去准备面试的事情，还要兼顾项目进度，会很焦头烂额。

转型 Swift

团队里的另外 3 个同事以前都没有写 Swift 的经验。可是考虑到将来的发展趋势，而且咱们的业务类型对动态化的要求没那么强。我坚持在团队里推行使用 Swift 编程。

我常常被问到的一个问题是你想用 Swift 可是团队里其余人不会用，会不会给项目推动带来困难。其实若是团队里有人正确的引导，帮他们解决上手过程当中的问题，再给一段时间过渡。很快他们就会退不回去。

下面介绍一下我把从 OC 迁移到 Swift 的过程。

先用 Swift 写好网络层的库。借着把经常使用的几个 OC Model 和 Swift 对象作好桥接。相似下面这样：

class SwiftUser {
    init(ocUser: OCUser) {
    }
    func convertOCUser() {
    }
}

这样改造以后若是一个新的模块就能够彻底用 Swift 编写。一开始确定是用 OC 的思惟写 Swift 的代码。可是在熟悉了 Swift 语法后能够慢慢在 review 过程当中提出能够用更 Swift 的写法。 有些功能须要 OC 和 Swift 互相调用确实挺麻烦。若是让一个没 Swift 经验的上手就解决这些问题必定很气馁。因此在项目过程当中也要分配必定时间把老的 OC 代码重写了。好在原先的代码原本就很乱，须要重写。这样就随着业务推动中，Swift 比例愈来愈高。

这样通过一两个月后你们就慢慢熟悉了 Swift ，此时再去推动 RxSwift 等框架的使用。

理顺开发工做流

项目早期的时候需求千千万，一个迭代版本中应该开发多少功能呢？产品经理本能的就是靠拍脑壳。列了一页需求后表示这就是这个版本了。程序员都倾向于乐观估时间，作着作着半个月过去了。下个迭代的需求、UI 设计，交付前测试的工做都很混乱。

后来通过讨论肯定了两周一个迭代周期。开发过程当中发现某个需求这个迭代里没法完成就挪到了下个迭代中。每一个周期阶段要作什么你们都很明确。两周左右发布参考用户反馈也是一个比较好的节奏。

这里要强调的是开发过程前期的准备工做。主要指需求和 UI 图。大多数的需求设计都是围绕某个需求展开，可是这个需求要融入到现有体系里是有不少周边的工做要作的。好比产品提出用户资料里应该能够打标签。因而画了一个草图里有标签。对于他可能这个需求描述的很明确了，可是真正落地的时候就有其余工做要作。好比标签怎么删除？标签有字数限制吗？标签重复了怎么办？这些问题若是前期设计的时候产品没有表达清楚，就只能在开发的过程当中来回沟通。有一个经验丰富的开发者在前期就参与需求的讨论，和提出问题对于在后期开发有很大的帮助。

不用 Sketch 的设计师不是好设计师

我看到不少设计师沿用传统，一直使用 PS 。然而实际上业界使用矢量设计工具 Skecth 已经很广泛了。如今手机的屏幕尺寸更异，若是设计的时候不是矢量图，而是位图，作响应式的布局设计就会很不方便。实际上移动的 UI 设计若是用惯 Sketch ，绝对是生产力的极大提高。 可是和大多数人同样，不少设计师都会以为 PS 用的也挺顺手的，Sketch 没用过。其实 leader 是有义务去推进一些人，让美好发生。

以前我在的团队我就一直不断暗示不厉害的设计师才用 PS ，后来刺激了几周后他说他如今也能够用 Sketch ，后来慢慢项目 symbol 都凑齐了 PS 他也退不回去了。

固然也有很是老派的设计师，这种只能给他压力让他去被动改变。当时咱们团队有一个四十多高龄设计师，咱们也很为难。我当时想那算了，下个月若是你不能用 Sketch 出图就本身准备换个工做吧。固然做为一个团队也不能给个指示就甩手无论了。中间已经熟练使用 Sketch 的设计师会特别关注他的学习状态，及时指导。最后也获得了一个好的结果，他在被迫改变后发现 Sketch 确实更好用。

这里还有安利一个很好用的输出设计图的软件：zeplin。设计图直接采用标注的方式会很死板。程序员在查看过程当中能够本身查看到设计图的全部源信息效率会获得极大的提高。

接入 CI

不少团队改变代码里的宏来区别 app 里的环境，每次提交前改下宏。常在河边走，哪能不湿鞋。我还真遇到过提交 App Store 的时候，有人忘记改环境的宏，app 链接到的是测试环境。这里想说的不是发布前要仔细检查，而是这种状况就不该该发生。

实际上经过 Xcode 打包手动提交也是一个充满风险的过程。由于不时会出现本地改了几行代码，提交的时候把本地的代码也提交了。带来了未知的风险。

我经过配置 Xcode 里的 scheme、target 来区分环境。利用 fastlane 来完成自动打包上传的工做。结合 Gitlab 的 CI ，配置了 Gitlab runner，今后打包只须要点击一下按钮。下降了发布的人工操做风险。

咱们的组件是用 cocoapods 管理依赖的。配置了 Gitlab runner 后，组件的版本更新也放在远端工做，再也不基于本地。配置了 webhook 后，每次 job 完成后 slack 的 channel 里你们都会收到消息。

用好 Testflight，注重 beta 反馈

早期业务变化频繁，没有自动化测试，只能靠人工测试保证稳定。一开始团队选择了发布企业版的包来测试。固然企业版用户能够方便的下载安装，可是也有很多缺点。最大的缺点就是这个包和 App Store 的包是两个包，不同的 bundle id 。会致使一些跟包绑定的功能没法正常测试，好比微信登陆、支付后的跳转。

咱们的业务里有聊天的功能，聊天记录是只存在本地的。并且咱们认为一个帐号只能在同一个平台上的一台设备登陆。这就致使用户测试的时候帐号会从 App Store 版本登出，这样聊天记录就没了。热心用户愿意试用咱们的 beta 版，可是也承担了不应有的代价。基于这点考虑在个人主导下咱们放弃了发布企业版的包测试的方式。而是改用利用 testflight 测试。

Testflight 有个较大的使用门槛，须要收集用户的邮箱，以后在 testflight 里输入苹果发出的邀请码才能开始测试。不少用户嫌麻烦就退出了，运营认为这样会给测试带来很大的不便。可是冷静了心态后其实事情并无那么糟糕。真正对这个产品有兴趣的用户不会由于要填个邮箱就放弃了。那些流失的只是普通的用户。用户使用了 Testflight 后，后续的测试包的发布也会收到更新。不会像企业版那样，只能手动的告诉用户咱们有新的测试包。当 beta 测试活跃用户超过 100 个会有一个质变。这些都是积极的重度用户，一群重度用户使用你的新版本几天，至少能够保证核心业务逻辑是没有纰漏的。

以前有人问过咱们使用 Swift ，线上出严重 bug 时无法动态修复，会不会带来不少问题。实际上由于有这样一环 beta 测试环节，不多出现严重的事故了。有一次意外是咱们的 Swift 版本升级到 4.0 的时候，一个枚举竟然对 iOS 8 设备不兼容（Xcode 并无提示咱们，苹果的锅）。那个版本也刚好是支持 iOS 8 的最后一个版本。咱们的测试用户里恰好没有使用 iOS 8 系统的。

Beta 测试的时候可让用户及时的反馈问题也是很重要的。若是我跟你反馈一个问题，又要看 app 版本，又要说在哪一个页面，还要说一下个人 userID。用户的脾气也是够好的。咱们在 app 集成了摇一摇反馈 bug 的功能，操做步骤，网络请求，设备信息等这些有效的信息都会一块儿收集起来。在后台能够方便的看到。告诉用户碰到问题摇一摇，描述一下问题就能够了。用户反馈后咱们会收到邮件，及时的反馈用户用户也颇有参与感。

摇一摇的功能并无对全部用户开放，只是针对某些特定咱们能联系到的用户开放。毕竟每个反馈工程师都须要跟进，若是面向全部用户开放，咱们会收到太多无效信息。常看到工程师讨论这些开发者功能的入口要藏在哪里，有的说在某个文本框输入特定字符，有的说在某个角落里点几下什么的。开发者面板的入口我选择配置在 universal link 里。这样用户不会在 app 里任何一个地方误触到达，只能经过咱们告诉他的连接经过跳转到达。

坚持 Code Review，加强技术交流

Code review 是一件神奇的事情。全部有素养的工程师都以为 code review 好，据咱们所知国外不少优秀的 IT 企业都很注重 code review，可是在国内却不多看到有团队执行 code review。或者中小团队里不多看到 code review。

可是我很看重 code review，从情怀的角度讲，这里面是工程师技艺的一种传承。一个方法名起的很差，从公司角度来看，这个项目同样会 work 。可是从工程师角度来讲，若是有能力，为何不帮助那些刚开始写代码的人一些指引呢？

做为一个 leader，在 review 的时候帮助成员成长，和只是看下代码是否是能完成功能最后会引向不一样的结果。看过一句颇有触动的话，如今不少 leader 知道本身的工做里须要管理其余人，可是却忽略了还须要 lead 。

老实说推动 code review 确实遇到不少阻力。有团队里的也有团队外的。团队外的见解是 code review 拖慢了项目进度。我做为一个核心的开发成员，天天超过 20% 的时间是没有可见的工做产出的。有时别人写的有问题被我打回去改，一个已经完成的功能又多花了几个小时。团队内遇到的问题是，不少成员不理解这项工做背后的价值。很容易就以为我早上没有推动项目进度，只是在坐在那里不知道在看什么。以为我 commit 的代码很少。最后我得到了团队“代码最少产出”奖。

对于我我的而言，其实不搞 review 我确定更轻松。这个功能我确定能把控全部细节，这样写只是很差而已，也不是不能用。我也大能够不对他们解释为何这样写是很差的。只要让他们按照个人 comment 改就能够了。

可是吃力不讨好的坚持是为了什么？

我刚工做的时候，出去旅游路上遇到一个大学教授。闲聊起来我说我请教你一个问题，中国古代的鞋子，会把花绣在鞋底。鞋底其余人又看不到，这样作的意义是什么。他回答说，咱们作事不是作给别人看的，最后仍是要过本身内心这一关。花绣在鞋底，别人看不到，你本身知道。

小编有本身的千人iOS开发交流群，欢迎如今正在逆风前行的大家入驻，群内有小编本身学习整理的一些书籍资料，能够进群自行下载！QQ群号：763164022 ！ 戳这里直接申请！