2017 移动端 iOS 年终工做总结-纯干货请自备酒水

主题：发展

内容大纲

观点：

• Swift 发展观
• ReactNative 发展观

进阶：

• 模块化
• Pods 依赖库及组件化
• 环境自动切换 + 自动化打包测试 + 线上质量监控

管理：

• 团队核心组成架构
• 硬件设备投入
• 例会和文档化
• 组织 CodeReview

工具：

• Gitlab 及 Git 相关规范
• Sketch 设计工具 + Zeplin 标注工具

成果：

• Github 原创开源项目 90+，共计 400+ 贡献力
• 参与维护开源项目 fastlane 20.5k（至2018.02.08）
• 完成 Swifter 功能展现应用研发

---

观点

Swift 发展观

Apple 在 WWDC 2017 大会上发布 Swift 4，Swift 4 带来了更快、更容易使用的 String 实现，能够保持 Unicode 的正确性，并增长对建立、使用广告管理子串的支持，它提升了开发者建立、使用和管理集合类型的能力，它支持结构化枚举类型的归档并容许对外部格式进行类型安全的序列化，包括 JSON 和 plist。

既然提到了 WWDC（developer.apple.com/wwdc/），相信 Swift 的发展观就没有太多争议了，近几年全部的官方演示视频都是基于 Swift 来演示的，做为 iOS 的开发人员可能会继续使用 Objective-C，可是若是对 Swift 是持抗拒心理的，那无疑对自身发展是不负责任的。

Apple 于 2017 年宣布 Swift 5 后会锁定 ABI，也就标志着这门语言会正式做为 iOS、macOS 的主流语言。同年 12 月，Apple 宣布会着手计划 iOS 和 macOS 的应用层面合并。配合 Apple 一直以来的对 Swift 幼儿教育以及在 AI、AR 等领域的推动，不难看出这门语言将来的发展潜力。

ReactNative 发展观

提到 ReactNative 就不得不说 FaceBook，其实如今主流的移动端开发规范就是这家公司设计的。固然除了 React 社区生态圈的加持和 Facebook 的大力推广之外，另一个最主要的缘由就是其在开发效率和应用性能方面取得了一个比较好的平衡：

• 开发效率经过 JS 工程实践，逻辑跨平台复用获得极大提高
• 性能则经过全 Native 的 UI 层获得知足

跨平台这一特性对于小公司的吸引力则更体如今节约用人成本上，对简单的需求能作到一端多用，随时变动线上内容。

对于已经正在运营的项目，彻底切 ReactNative 老是不太现实，其实大多数厂商的方法是对运营引流有影响的关键性页面（如：首页）进行 ReactNative 改版，这里可能就会引入一个 模块化 的概念，后面会有讲到。

对于想要入门的朋友，慕课网上一个入门级 ReactNative 教学还不错。

教学视频：coding.imooc.com/class/89.ht…

源码：github.com/crazycodebo…

进阶

模块化

模块化、组件化我后半年一直在调研的课题，对这些的研究也给我带来了从量变到质变的提高。

什么是模块化？

那么什么是模块化呢？《 Java 应用架构设计：模块化模式与 OSGi 》一书中对它的定义是：模块化是一种处理复杂系统分解为更好的可管理模块的方式。

咱们能够把软件看作是一辆汽车，开发一款软件的过程就是生产一辆汽车的过程。一辆汽车由车架、发动机、变数箱、车轮等一系列模块组成；一样，一款大型商业软件也是由各个不一样的模块组成的。

汽车的这些模块是由不一样的工厂生产的，一辆 BMW 的发动机多是由位于德国的工厂生产的，它的自动变数箱多是 Jatco（世界三大变速箱厂商之一）位于日本的工厂生产的，车轮多是中国的工厂生产的，最后交给华晨宝马的工厂统一组装成一辆完整的汽车。这就相似于咱们在软件工程领域里说的多团队并行开发，最后将各个团队开发的模块统一打包成咱们可以使用的 App 。

一款发动机、一款变数箱都不可能只应用于一个车型，好比同一款 Jatco 的 6AT 自动变速箱既可能被安装在 BMW 的车型上，也可能被安装在 Mazda 的车型上。这就如同软件开发领域里的模块重用。

到了冬天，特别是在北方咱们可能须要开着车走雪路，为了安全起见每每咱们会将汽车的公路胎升级为雪地胎；轮胎能够很轻易的更换，这就是咱们在软件开发领域谈到的低耦合。一个模块的升级替换不会影响到其它模块，也不会受其它模块的限制；同时这也相似于咱们在软件开发领域提到的可插拔。

20180906 更新 再谈模块化、组件化、插件化定义

• 模块化：一个可实现的单元，核心是内聚和分离，如登陆模块的抽离
• 组件化：也称构件，最理想状况下是与业务无关，强调复用，如可复用 Library
• 插件化：与组件化不一样，组件化在编译时合并模块，插件化在运行时合并模块，如可实现远程替换功能

模块化分层设计

上面的类比很清晰的说明的模块化带来的好处：

• 多团队并行开发测试；

• 模块间解耦、重用；

• 可单独编译打包某一模块，提高开发效率。

在《安居客 Android 项目架构演进》这篇文章中，做者介绍了安居客 Android 端的模块化设计方案，这里做者仍是拿它来举例。但首先要对本文中的组件和模块作个区别定义：

• 组件：指的是单一的功能组件，如地图组件（MapSDK）、支付组件（AnjukePay）、路由组件（Router）等等；

• 模块：指的是独立的业务模块，如新房模块（NewHouseModule）、二手房模块（SecondHouseModule）、即时通信模块（InstantMessagingModule）等等；模块相对于组件来讲粒度更大。

针对模块化做者的团队也定义了一些本身的游戏规则:

• 对于 Business Module Layer，各业务模块之间不容许存在相互依赖关系，它们之间的跳转通信采用路由框架 Router 来实现（后面会介绍 Router 框架的实现）;

• 对于 Business Component Layer，单一业务组件只能对应某一项具体的业务，个性化需求对外部提供接口让调用方定制;

• 合理控制各组件和各业务模块的拆分粒度，过小的公有模块不足以构成单独组件或者模块的，做者先放到相似于 CommonBusiness 的组件中，在后期不断的重构迭代中视状况进行进一步的拆分;

• 上层的公有业务或者功能模块能够逐步下放到下层，合理把握好度就好；

• 各 Layer 间严禁反向依赖，横向依赖关系由各业务 Leader 和技术小组商讨决定。

自从 Oasis Feng 在去年的 MDCC2016 上分享了模块化的经验后，模块化在 Android 社区愈来愈多的被提起。做者天然也不落俗的去作了一些研究和探索。安居客如今面临不少问题：例如全量编译时间太长（我这台13款的 MacBook Pro 上打一次包得花十多分钟）；例如新房、二手房、租房等等模块间耦合严重，不利于多团队并行开发测试；另外在17年初安居客从新将租房 App 捡起推广，单独让人来开发维护一个三年前的项目并不划算，因此做者但愿能直接从如今的安居客用户端中拆分出租房模块做为一个单独的 App 发布上线。这样看来模块化彷佛是一个不错的选择。

因此做者作模块化的目的大体是这样的：

• 业务模块间解耦

• 单个业务模块单独编译打包，加快编译速度

• 多团队间并行开发、测试

• 解决好租App须要单独维护的问题，下降研发成本

关于模块化组件化的生动解读来自安居客 Android 组组长张磊的博客 baronzhang.com

Pods 依赖库及组件化

组件化与模块化 安居客的 Android 团队内部成立了技术小组，基础组件的开发是技术小组很重要的一部分工做；模块化更多的是现有的方案受到来自业务上的挑战以及受到了 Oasis Feng 在 MDCC 上的分享和整个大环境的启发，如今正处于设计规划和 Demo 开发的阶段。

组件化 组件化不是个新概念，通俗的讲组件化就是基于可重用的目的，将一个大的软件系统拆分红一个个独立组件。

组件化的带来的好处不言而喻：

• 避免重复造轮子，节省开发维护成本；

• 下降项目复杂性，提高开发效率；

• 多个团队公用同一个组件，在必定层度上确保了技术方案的统一性。

如今的安居客有是三个业务团队：安居客用户 App、经纪人 App、集客家 App。为了不各个业务团队重复造轮子，团队中也须要有必定的技术沉淀，所以组件化是必须的。如今咱们须要提供更多的、职能单1、性能更优的组件供业务团队使用。根据业务相关性，咱们将这些组件分为：基础组件和业务组件。

阿里架构组一样是组件化的先驱者，如下是阿里架构组 Evans 对组件化的观点：

首先，个人理解分块化应该是有四种，组件化+模块化+插件化+解耦

第一，组件和组件实际上是没有什么鬼明确的约束 ，由于组件通常都是单独开发、单独测试，不能直接放到主项目中开发，测试也是单独针对性的测试 （里面涉及到短链+组件的生命周期+....）

第二，模块化个人理解是，怎么作好project的模块化的拆分，咱们内部一直在说越底层的模块，应该越稳定，越抽象，越具备高复用度，可是其实有一个壁垒就是怎么去提高模块的复用度，怎么去快速具有复用性高于代码复用性，这咱们就要作好每一个模块只作好一件事情，模块化结构要更加清晰，每一个模块都只作一件事情，具备良好的延展性和拓展性，希望不要出现下层模块依赖上层模块的现象，业务模块之间也尽可能不要耦合。好处是一样的功能模块，能够在多个app中复用，业务隔离了跨团队开发代码控制和版本风险都变小了。

第三，解耦其实理解很简单就是在基于模块设计原则上, 让模块之间没有循环依赖, 让业务模块之间解除依赖，不相互调用。

概况的理解就是

• 组件化：单独开发、测试、维护的开发模式
• 模块化：对 Project 进行拆分，根据业务、功能进行分类
• 解耦：模块设计原则上, 让模块之间没有非必要依赖

而组件化如今主流的作法是经过 CocoaPods 对要包装的内容进行打包，提交到公司的私有库（开源项目是公有库），进行平常维护及开发。

环境自动切换 + 自动化打包测试 + 线上质量监控

环境自动切换

Debug 和 Release 仅仅是编译选项的不一样，那么为何要区分 Debug 和 Release 版本呢？

Debug 和 Release，主要是针对其面向的目标不一样的而进行区分的。

Debug 一般称为调试版本，经过一系列编译选项的配合，编译的结果一般包含调试信息，并且不作任何优化，为开发人员提供强大的应用程序调试能力。

而 Release 一般称为发布版本，是为用户使用的，通常客户不容许在发布版本上进行调试。因此不保存调试信息，同时，它每每进行了各类优化，以期达到代码最小和速度最优。为用户的使用提供便利。

对于一些企业版应用或者有内部测试的需求其实还能够新增 Beta 版，收集核心用户的建议或者测试新开发的功能模块，对反馈作出迅速反应，灵活控制。

因为以前引入了组件化开发模式，全部我又加入了 UnitTest（单元测试）模式，只要用于对组件的分离化测试，快速定位问题。

切换环境的同时会对应切换应用的图标，能有效避免测试环节中的环境混淆和下降辨别成本。

自动化打包测试

关于自动化打包就不得不说在创业公司的经历，那时开发任务重，提测前经常加班到晚上 12 点，就算 bug 修完，也要等半个小时看着 Xcode 镇定自若的打包完成上传测试平台发邮件才能安心回家。

鉴于这种惨痛经历，利用闲暇时间就搞了个自动打包脚本，后期又整理一遍并适配 Xcode 8.2 以后的版本。 作的了三步配置，杜绝污染，一行命令自动上传。

也是鉴于 Xcode 版本升级后的苦逼适配经历，最终选择了开源的 fastlane 包，今后搭上了组织的小火车，配合 Testflight 终于能够放心的玩耍了...

FastLane 是一种配置 iOS 和 Android 自动化 Beta 部署和发布的最简单的方法之一。它能够简化一些乏味、单调、重复的工做，像截图、代码签名以及发布 App。也能无缝衔接蒲公英、Fir等测试平台，这酸爽...

• 省时：每次将新版本推送到商店或Beta测试服务时，均可节省时间。

• 集成：集成当前开发环境中全部存在的工具和服务。

• 开源：100%基于MIT许可开源。

• 简单：简单的设置助手，几分钟配置便可使用。

• 运行：基于你的app和数据，运行在本地机器上。

• CI：集成几乎全部CI系统。

• 支持：支持iOS、Mac以及Android 应用。

• 自定义：根据自身须要扩展和定制fastlane，不依赖任何人。

• 命令行：不须要记住除fastlane之外的任何命令。

• 配置：能够在任何电脑上配置，包括CI服务器。

对于 Testflight，就像没故事的卓同窗所说的。

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

这里推荐配合测试的 SDK 质量监控服务——Bugtags，Bugtags 能够经过悬浮窗或者摇一摇的方式进行截图，并将捕获的 bug 图片上传到测试平台，其自身也包括 Crash 的自动上传。

线上质量监控 Crashlytics 成立于2011年，是专门为移动应用开者发提供的保存和分析应用崩溃信息的工具。

• Crashlytics 不会漏掉任何应用崩溃信息。在发生崩溃后，用户再次进入 APP 并联网状况下，日志自动上传。
• Crashlytics 能够象 Bug 管理工具那样，管理这些崩溃日志。例如：Crashlytics 会根据每种类型的 Crash 的出现频率以及影响的用户量来自动设置优先级。对于每种类型的 Crash，Crashlytics 除了会像通常的工具提供 Call Stack 外，还会显示更多相关的有助于诊断的信息，例如：设备是否越狱，当时的内存量，当时的 iOS 版本等。对于修复掉的 Crash 日志，能够在 Crashlytics 的后台将其关掉。
• Crashlytics 能够天天和每周将崩溃信息汇总发到你的邮箱。
• 提供在线的报告，解释崩溃缘由，甚至能给出是哪一行代码致使的崩溃。

Crashlytics 有配套的 macOS 应用 Fabric 用户体验值得国内 SDK 服务商学习。

2013 年 Twitter 对 Crashlytics 进行人才和服务的多重收购，一年后 Google 收购 Firebase，今后 Fabric 和 Firebase 这对好基友就成为了应用崩溃报告的黄金搭档。

管理

团队核心组成架构

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

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

技术团队作事就像古代的八抬大轿，公司业务就像轿子里的小娘子，团队文化就像抬轿子时喊的号子，团队里的每一个人就像是抬轿子的车夫。抬轿子的大多数人走的快，每一个人的步子齐，那轿子里的小娘子就坐得很舒服，若是哪一个环节出现问题都会对坐轿子的人有影响。

因此，车夫水平要挑好，号子要响亮提气，每一个人的步伐要协调，轿子就能平稳上路，但是若是想快点赶路，那可能就要尝试不一样的抬轿姿式，换更响亮的号子，排练更协调步子，甚至换个更轻的轿子、换个轮子...

硬件设备投入

接着上面的“花轿”说，硬件投入的重要性就不言而喻了，别人已经换上了带轮子的马车了，固然跑的飞快。

拿 Swift 的编译速度讲，MacBook Air 和 MacBook Pro 的处理器芯片和内存容量决定了两种电脑的编译耗时可能相差1倍左右，而一块外接显示屏能节省的频繁操做更是以少积多。

若是把一个工程师的薪资换算成时薪，配合硬件设备浪费掉的时间，将是一笔不那么明智的开销，固然若是你的工程师天天只是喝凉水看新闻，那请配给他一个保温杯和老花镜~

例会和文档化

有哪些会？

当我打算写这个主题时，反思了下过去都参加过哪些会议，发现有时会莫名其妙的就参加了一些彻底无心义的会议。下面咱们先看看通常程序员都会碰到哪些会议。

需求会

这类会议通常是产品或项目经理召集，组织参与项目的程序员一块儿讨论需求并肯定排期。这类会议容易出的问题是，程序员到了会上才第一次知道需求，并陷入到需求细节的无休止讨论中。更好的方式是提早让程序员详细了解需求，会上只需敲定排期并让互相有协做依赖的程序员之间达成一致和造成承诺。

讨论会

这类会议的场景比较普遍，好比：项目进行过程当中同组程序员之间就设计或实现的讨论，或与其余组项目合做人之间的讨论等等。这类会议容易出现的问题是临时把一堆人拉到会上，而后陷入混乱的自由讨论，失去焦点。

还有一类讨论会叫头脑风暴会，也是容易把一堆人拉到会上，开动头脑风暴。现在遗憾的领悟到这是最没效率也没效果的方式。头脑风暴会须要就待解决的问题让参与人员提早准备，搜集或阅读材料，不一样人从不一样角度各自提出本身的观点或方案，而后到了会上将全部观点和方案列出来，再开动头脑，碰撞链接一下，看看能不能风暴出一些新的观点或方案去有效解决问题。

周例会

通常来讲一个部门或小组都会每周开个例会，例会容易被看成平常的例行工做而不被重视。例会应该有固定的时间和议程，并且例会是一群常常一块儿工做并熟悉的人开会。虽然开例会的人都在同一个部门，但并不意味着他们都会相互合做完成同一个项目或事情。因此，例会是经过了解各自工做来完成了解整个部门或小组工做进展的机会，而不是每周固定的休闲时光。固然咱们也能够在每周的例会留出一段自由讨论时间，能够畅所欲言，增长工做以外交流。

除了周例会，有些实施敏捷方法的团队也会开每日站立会，每日站立会的通常内容是：

• 昨天干了什么
• 今天计划干什么
• 遇到了什么障碍

每日站立会议的主要目的是让团队成员互相交流互通工做状况，而不是为了让经理们了解状况而召开的会议。每日站立会不是一个团队的人站一圈各自说下工做状况，由于曾经发现彼此并不关心对方工做内容的人站一圈开这个站立会，其意义何在？

分享会

部门内、公司内或行业内都会有各种不一样规模分享会，想清楚你为何要去参加一个分享会？通常来讲我只有两个缘由，我对分享的内容感兴趣，这应该是大部分人参会的缘由。另外一个，即便分享内容我已经很熟悉，那么参会的缘由通常就是对分享人感兴趣，想要去经过这个分享了解分享人。

还有一种状况多是碍于面子参加一些彻底没兴趣的分享会，恩，这种仍是尽可能规避吧。

临时会

总会碰到这种状况，忽然有我的过来叫你临时去参加个会，而后你就一脸懵逼的去了。这种会彷佛属于身不禁己，很差规避，这类会议可能是非计划性的任务驱动型会议。英特尔前 CEO 安迪·格鲁夫说过：

在现实中，有 20% 的状况还得靠任务导向会议来解决。但若是经理人将超过 25% 的时间用在应急的任务导向会议上，这个组织就必定有了毛病。 这种类型的会议随时召开，并且会针对具体状况产生决策，若这种临时紧急的任务驱动会议太多了，那问题确定出在平时的工做中。

总结会

多是项目上线或产品发布后的总结会，也多是线上故障后的经验教训总结会。我之前开过的不少总结会都变成了领导的总结会，关于这类会你们有什么好想法吗？

对于以上这些千奇百怪的会议，因而有人制做了这幅漫画：

其实呢，凡事都有两面性，最难把控的永远是人，做为有效的讨论活动，会议本事没有问题，精耕细做也会在必定程度上保证质量。重要的是会议的气氛、主题以及控场力。

高效会议的三个要诀： 1.提早通知议题并发给参会人相关资料，不要求可参加可不参加的人 2.会议必须有主持人，引导你们时刻盯住会议主题 3.要有会议纪要，会后对会议结论、行动计划、负责人、进度表和考核目标的提炼总结

我以前遇到一个项目领导就颇有特点，因为采起封闭式敏捷开发模式，须要天天肯定工做内容，调节各部门间工做进展，因此须要天天作午会，可是当时并不枯燥并且团队协做融洽，由于在例会事后有组织抽签买饮料、零食和惩罚倒霉鬼的活动，现在想来，他确实是一个优秀的组织者。

以上这些会议内容来自博客园的 mindwind，让咱们同情他一刻钟~

文档化 文档化和例会同样是充满争议的举措，本质上是为了让一切有据可查，方便后期查阅和减小交接工做负担。但也不乏反对者，认为是在浪费时间，形势主义。

仍是同样的道理，稳定的方法不会错，难把握的是我的。把每个帐号密码整理保存也是文档化。保持会议记录、工做聊天日志也能在必要时不接受飞来的横“锅”~

组织 CodeReview

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

做为一个 leader，在 review 的时候帮助成员成长，和只是看下代码是否是能完成功能最后会引向不一样的结果。看过一句颇有触动的话，如今不少 leader 知道本身的工做里须要管理其余人，可是却忽略了还须要 lead 。 老实说推动 code review 确实遇到不少阻力。有团队里的也有团队外的。团队外的见解是 code review 拖慢了项目进度。我做为一个核心的开发成员，天天超过 20% 的时间是没有可见的工做产出的。有时别人写的有问题被我打回去改，一个已经完成的功能又多花了几个小时。团队内遇到的问题是，不少成员不理解这项工做背后的价值。

一样的感触来自上面提到的那家公司，负责咱们的小组组长是一名有着 6 年移动端开发经验的优秀工程师，在一套严格的代码规范要求和 code review 的锻炼下，个人成长几乎是肉眼可见的（对比回看以前的代码），他对咱们的指导也是无私且专业的，以致于我如今依然在感谢着他。

CodeReview 的方式

• 开 Code Review 会议
• 团队内部会整理 Check List
• 团队内部成员交换代码
• 找出可优化方案
• 多问问题，例如：“这块儿是怎么工做的？”、“若是有XXX 状况，你这个怎么处理？”
• 区分重点，优先抓住设计，可读性，健壮性等重点问题
• 整理好的编码实践，用来做为 Code Review 的参考

CodeReview 的内容

[1]架构/设计/常规 1.单一职责原则 这是常常被违背的原则。一个类只能干一个事情，一个方法最好也只干一件事情。比较常见的违背是一个类既干UI的事情，又干逻辑的事情，这个在低质量的客户端代码里很常见 2.行为是否统一，例如： 1)缓存是否统一 2)错误处理是否统一 3)错误提示是否统一 4)弹出框是否统一 5)…… 3.代码污染 代码有没有对其余模块强耦合 4.重复代码-->应该抽取 5.开闭原则 6.面向接口编程 7.健壮性 1)是否考虑线程安全 2)数据访问是否一致性 3)边界处理是否完整 4)逻辑是否健壮 5)是否有内存泄漏 6)有没有循环依赖 7)有没有野指针 8)是否检查了数组的“越界“错误 9)…… 8.错误处理 9.改动是否是对代码的提高 新的改动是打补丁，让代码质量继续恶化，仍是对代码质量作了修复 10.效率/性能 1)关键算法的时间复杂度多少？有没有可能有潜在的性能瓶颈 2)客户端程序对频繁消息和较大数据等耗时操做是否处理得当

[2]代码风格 1.可读性 衡量可读性的能够有很好实践的标准，就是 Reviewer 可否很是容易的理解这个代码。若是不是，那意味着代码的可读性要进行改进 2.命名 1)命名对可读性很是重要 2)是否跟系统属性命名形成冲突 3)英语用词尽可能准确一点，必要时能够查字典 3.函数长度/类长度 1)函数太长的很差阅读 2)类太长了，检查是否违反的 单一职责 原则 4.注释 恰到好处的注释,不是注释越多越好 5.参数个数 不要太多，通常不要超过 3 个

工具

Gitlab 及 Git 相关规范

Gitlab 对于代码仓库开源首选 GitHub，不开源如今也有许多服务商，如：Gitee 等，若是有钱任性 GitHub 普通的团队套餐每月每人 9 刀，但我相信大多数中小企业会选择 Gitlab。

还有就是服务端若是要本身配置 CI 服务不太方便。若是部署在本身的服务器上，其余一些服务脚本也部署在一块儿，会有很大的自主权。 综合以后选择了主流的 Gitlab。

第三方仓库均可能遇到父爱如山般的维护时期。

Git 相关规范 Git 相比 SVN 能避免大多数非人为问题，这点相信已经不须要论证了。可是那些人为的问题怎么办，那固然须要规范了。

• 首先，作好分工，特别是 Storyboard 和 XIB 多种，尽可能避免出现多人修改同一个文件。

• 每一个人的全部开发工做都只在本身的分支开发。例如小明开发，你就在本地切换到本身的 xiaoming_gittutorial 分支而后进行开发。

• 每一个人只容许在本身的分支直接push远程分支。

合并的时候必须遵循如下条件：

• 首先，本地切换到develop分支。git pull

• 例如你是小明，那么在 pull 到远程的 develop 最新的内容以后。 git merge xiaoming_gittutorial

• 若是出现 conflict 那么清除 conflict 以后，commit 而后把本地 develop push 到远程的 develop。

• 每完成一个功能就提交一次，不要累计代码。

• 保证主分支代码永远可运行，版本完整（用于脚本自动化发测试包）。

这样的流程有什么好处呢？

• 几乎不会出现 conflict。

• 你永远也不会污染 develop 分支。

每次都是在本地 merge 完清除了 conflict 以后再 push 会远端，那么别人更新本地 develop 分支，再合并的时候，就算出现 conflict 也只会是本身最新代码产生的 conflict。

Sketch 设计工具 + Zeplin 标注工具

移动端也属于前端，是作直接和用户打交道的事情，固然也包括设计狮，设计狮是一种很厉害的猫科动物，他们有着使人恐惧的像素眼和血统中的强迫症。（以上我喝多了说的，不要当真哈~）

Sketch 做为一款移动时代设计师新宠，天然有其存在的道理。

• 自动保存和版本管理
• 矢量编辑和完美像素
• 智能参考线
• 自由编辑元素
• 布尔运算
• 单图层多重混合模式
• 四舍五入像素数值取整
• 共享样式和组件
• 优秀的输出
• 分配间距
• 移动设备模版
• 自带格栅
• 出色的文字渲染
• 丰富的插件（标注、内容填充）
• 多种软件高度配合
• 旋转复制
• 手机实时预览

Zeplin 面向的用户是设计师和前端（Web、Mobile）工程师，至关于作的是中间桥梁这一块，核心功能为标注、Style Guide、备注文档与简单的团队协做。

• sketch支持多画板，便于同时预览，占用内存较ps小不少
• sketch支持导出flinto，便于制做交互动效原型
• zeplin解放设计师的双手，今后告别切图和标注
• zeplin下降工程师的沟通成本，提升设计还原度

Abstract 就是一个借助 Git 对 Sketch 文件进行版本控制的软件。

详情参见《Git 与 Sketch 的神奇邂逅：Abstract》 （sspai.com/post/40595）

成果

年终总结

• Github 原创开源项目 90+，共计 400+ 贡献力
• 参与维护开源项目 fastlane 20.5k（至2018.02.08）
• 完成 Swifter 功能展现应用研发

Swifter 是一款基于 Swift 开发的，采用 MVVM 模式、RxSwift 函数式响应编程、组件化和 ReactNative 等技术的技术示例应用。