主题：发展
内容大纲
观点：
- 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…
进阶
模块化
模块化、组件化我后半年一直在调研的课题，对这些的研究也给我带来了从量变到质变的提升。
什么是模块化？
那么什么是模块化呢？《 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。为了避免各个业务团队重复造轮子，团队中也需要有一定的技术沉淀，因此组件化是必须的。现在我们需要提供更多的、职能单一、性能更优的组件供业务团队使用。根据业务相关性，我们将这些组件分为：基础组件和业务组件。
