内容修改: 小木箱
内容原创: 快手小红书 Android 架构与开发流程比照
B站视频: 小红书、快手的技能沉积 & 架构考虑 | BaguTree周六茶话
导言
Hello，咱们是让常识变得更简略的BaguTree ，欢迎来到BaguTree周六茶话系列教程。
今天BaguTree共享的主题是 《 小红书、快手的技能沉积 & 架构考虑 》 ，BaguTree从五个方面将 《 小红书、快手的技能沉积 & 架构考虑 》 解释清楚。
第一个方面是共享人介绍。 第二个方面是共享的原因。 第三个方面是小红书、快手技能沉积。 第四个方面是架构考虑。 最终一个方面是Q&A。
假如你吃透了 《 小红书、快手的技能沉积 & 架构考虑 》 ， 那么将会协助你更轻松的从互联网小厂过渡到互联网中大厂。
一、共享人介绍
Flywith24一开端不在知名互联网公司作业， 经过持续性学习，不断提高个人行业影响力，于2021年，顺畅参加快手。于2023年，顺畅参加小红书。
二、共享的原因
Flywith24在BaguTree共享 《 小红书、快手的技能沉积 & 架构考虑 》 主题主要有两个原因。
第一个原因是: Flywith24刚毕业时一向想了解大公司的开发流程以及架构，但网上资料寥寥无几。 现在也是阅历了一些大型互联网公司， 希望经过对外输出提炼， 协助大家到达学以致用的意图，技能上少走弯路。
第二个原因是: BaguTree是一个大佬云集的渠道，经过BaguTree共享自己在互联网中厂作业心得，能够知道更多志同道合的Android朋友。
三、小红书、快手技能沉积
开发言语
小红书的 Android App 的上架时刻比快手晚三年半，因此两个 App 的技能选型有着非常大的区别，从开发言语上来说:
快手Kotlin浸透率
快手许多老代码是 Java 写的，新增代码鼓舞（不强制）运用 Kotlin。
小红书Kotlin浸透率
小红书代码全 Kotlin（部分自研库内运用的是 Java），新增代码强制运用 Kotlin，全面拥抱JetPack组件。
研制流程
由于快手和小红书Android研制流程比较挨近， 所以咱们不去刻意的区分。 统一的说一下: 快手和小红书研制流程主要分为产品、研制、版别三个维度。
产品
首要， 产品依据优先级能够从需求池选择需求，并确定哪些需求能够入版。
然后， 每周固定时刻， 产品会和Team Leader进行需求预评。
最终， Team Leader给R&D分配需求使命， 产品和对应R&D拉会进行需求详评。
研制
R&D参加完需求详评后， R&D会提供需求排期包含: 开端时刻、DeadLine等等。
假如需求开发周期较长， 那么R&D要额定开需求技能评审会议。
假如需求开发周期较短， 那么R&D直接进入开发阶段。
在开发阶段中， R&D需求注意Git协作标准、CodeReview标准。
关于Git协作标准:
首要， 个人需求分支是依据develop分支进行衍变。
然后， 依据需求分支进行开发、自测、提测， 提测结束，需求分支才能合到feature分支。
其次， 运用Gitlab的MR功用将feature分支合入dev分支。
接着， 选择一个适宜的时刻，协作产品、QA、UI等进行showCase，确保主链路功用完好性。
showCase结束前， 开发要进行自测， 自测结束后，再提测。
showCase经往后，假如涉及到UI改动， 那么产品、UI会进行走查。
最终， 走查结束， 产品规划以为功用OK， 进入CodeReview环节。
关于CodeReview标准:
CodeReview有几个很重要的准则
- 功用完好性
- 功用安全性
- 可拓展性
- 可修改性
- 可重用性
…….
进入提测阶段， 测验经过测验渠道不断地提Bug， 假如没有发现严重的Bug， 那么才能合入版别分支。
最终， 在某个固定时刻， 快手会封版，并将Dev分支改成Release分支。
一旦封版，那么非特定状况不允许兼并需求。
版别
版别的迭代需求开发、测验、产品等各个方面的资源支撑。快手、小红书迭代周期是一周一迭代， 也便是班车制。
为什么叫班车制呢?
比方像咱们的公交车， 假如赶不上这一趟公交车， 那么咱们就必须等下一辆公交车。
版别迭代也相似， 假如需求赶不上发版节奏的话， 那么就需求流动到下一个版别。
在发版流程， 由于App的体量较大， 每次发版首要走灰度流程， 灰度期间进行小规划的放量。
在灰度期间， 咱们要观测是否有严重的Bug。 假如有严重的Bug， 那么就要进行紧迫修正， 提高用户体验。
灰度流程分为灰度1、灰度2和比照灰度等。假如灰度期间没有堵塞性问题， 那么能够提交商场审核。
假如商场审核经往后, 那么进行全量发布。
开发结构
接下来， 咱们说一下快手和小红书的自研开发结构。 快手开发结构用的是MVPs， 小红书开发结构用的是LCBs， MVPs和LCBs中心思维都是组合。
快手MVPs
长处
快手内部依据MVP思维封装的研制结构MVPs， MVPs结构中的Presenter数据来源， 依据依靠注入结构去完结的。
最中心的当地是Presenter， Presenter是一个Tree。 父Presenter能够有子Presenter的， Presenter内部封装了对View的持有， 父Presenter内部是作为一个最小的逻辑单元， 这样完结的长处是更便利的进行ABTest。
缺陷
View处理比较涣散
MVPs最大的缺陷是View处理比较离散。
快手MVPs是依据多个Presenter对不同View进行处理， 由于View的操作比较离散的。
Presenter责任并不明确，而Presenter内部View逻辑写在一块儿。假如某个View的状况呈现了反常，那么难以追溯。
案例
比方在快手上下滑动的事务模块里边， 依据咱们事务组创建了一个叫”形态复用”的功用。
意图是将UI页面的UI元素进行笼统， 比方快手状况栏底部有一些描绘案牍、音乐信息、信息区等。
咱们把一切Element笼统成一个Group， Group责任是组织Element， 控制Element的优先级、数据联通等。 这样就符合了Java规划准则的依靠倒置准则。
比方头像区域能够笼统成一个AvatarAndFollow， 这儿面有三个概念咱们要去了解， 第一个概念咱们叫ElementView， 第二个概念咱们叫Model， 第三个概念咱们叫Element。
其间， ElementView是UI上可复用最小单元， 内部持有了View的引证。
其间， Model运用了单向数据流， Model和View进行绑定。
其间， Element完结了上层的事务到Model的转化， 数据流向是单向的， 涉及到一个事情流向。
最终， 经过点击事情、长按事情和双击事情等可观察事情进行监听， 完结数据和UI的绑定。
小红书LCBs
原理
小红书的LCBs架构主要分为三个部分
- Linker: 导航、页面跳转
- Controller: 处理事务逻辑
-
Rx观察数据流
-
- Builder: 构建LCB的人物
缺陷
- 内部运用Dagger， Dagger不是针对Android移动渠道规划的结构， Dagger会出产各种临时文件， 使包体积变大
- LCBs节点的颗粒度较粗
- LCBs无标准的通讯逻辑
- 架构组规划的LCBs V1不兼容LCBs V2
四、架构考虑
WHAT: 什么是架构形式?
用百科全书来说: 架构形式(architecturalpattern)是软件架构中在给定环境下，针对常遇到的问题的、通用且可重用的处理方案。相似于软件规划形式但掩盖规划更广，致力于软件工程中不同问题，如计算机硬件性能约束、 高可用性、事务危险极小化。一些架构形式会经过过软件结构完结。
而软件结构， 通常是指为了完结某个业界标准或完结特定根本使命的软件组件标准， 也指为了完结某个软件组件开发时， 提供标准所要求之根底功用的软件产品。
常见的架构（Architecture）有:
- MVC
- MVP
- MVI
- MVVM
- Clean Architecture
- VIPER
常见的软件结构（Framework）有：
- Square-Workflow
- Airbnb-Mavericks
- Uber-RIBs
WHY: 为什么自研事务架构?
大型的互联网公司是一个多元化协作的进程， 协作无处不在，例如：道路上的司机/行人在规则约束下与其他司机/行人协作，完结安全驾驶。
所以一个适宜的结构应该满意以下两点：
- 适应事务需求，提高效率
- 约束老司机们的骚操作，降低犯错概率
规划越大互联网公司， 假如没有适宜的事务架构， 那么危险性越高。
比方: 快手光Android大概有几百人， 几百人会同时往一个库房里边提交代码。
假如几百个人开发经验、编码风格都不一样，代码没有强制性的约束， 那么代码质量不会太高。
这也是FlyWith24以为一个互联网公司要自研事务架构的根本原因。
WHAT: 什么样的事务架构适宜企业?
没有最佳实践， 只要愈加适宜。当前事务架构不必定满意未来的事务架构。事务架构需求跟着事务的不断迭代， 不断优化。
WHEN: 什么时分要去优化事务架构?
当咱们事务遇到通用性的问题需求去处理， 为了处理这样通用性问题， 咱们需求优化和改造适宜企业的事务架构。
五、Q&A
gaolhjy Say: 项目办理中， 如何防止需求延期?
Flywith24 Say: R&D评估使命做多久？要求R&D有必定的事务评估能力，假如产品不遵守规则，需求不断变更，导致R&D研制时刻拉长， 需求延期导致提测反常， 那么会触发复盘流程。
假如R&D引入了三方库， 导致线上问题， 那么也会触发复盘流程 & CodeReview机制。
假如没有在DeadLine完结事务需求， 那么也会触发复盘流程。
! Say: CodeReview的形式和流程是怎样的?
Flywith24 Say: CodeReview， R&D能够说又爱有恨， 大家希望他人的代码注释完好， 逻辑谨慎， 可是自己开发的时分， 不希望去了解他人的代码。
快手， 首要gitLab提交MR的时分， 触发pine line动作， 流水线有许多节点，每一个节点都是堵塞式的操作， 假如有一个节点无法经过， 那么下面的节点没办法正常进行。具体节点包含: 编译查看、代码质量查看、包体积查看、言语案牍查看等等， CodeReview是作为流水线中的其间一个节点去做的。一般是放在提测之后进行的。然后CodeReview会依据版别Owner、TL等进行+1操作。测验结束后会有+2操作。
小红书， 运用的是Uber的传统CR机制， 提完MR之后， 会交给同组的同事进行CR。
匿名 Say: 排期周期是否允许刻意拉长?
Flywith24 Say: 在快手， 我学到一个关键词: Buffer， 排期时刻留Buffer， 由于中心可能有修Bug、开会打断自己， 要给自己留一下缓冲时刻， 防止延期。
ShaJia Say: 小红书招人吗?
Flywith24 Say: 小红书现在还有几个Android HC， 感兴趣能够联系我， Base地在广州和北京。
gaolhjy Say: 刚刚说到研制周期相似于班车，那请问：假如本周由于放假补班、度假，怎么办呢？假如开发延期了，怎么办呢？
Flywith24 Say: 从年头的时分，快手整个一年一切版别是有规划的，是自动跳过节假日的。
新年的新年活动会进行一些延迟的一些发展，会确保新年活动的周期内代码的一个稳定性。
至于开发延期了怎么办？作为开发确保不延期， 即保质保量保交付是根本的要求。
gaolhjy Say: 小红书、快手作业时刻段，开会与研制的时刻份额大概是怎么样的？
Flywith24 Say: 其实有许多会议对R&D来说是无用会议。 可是周会、周报和晨会， 其实是很有必要的。
我在快手那个小组是没有周会的， 我在小红书的周会是在一个会议室里边进行交流。
交流内容包含但不限于自动抛出危险点、OKR进展跟进和技能点共享等。
gaolhjy Say: 关于研制不遵从开发标准，小红书、快手有哪些软办理及硬性办理呢?
Flywith24 Say:
快手会有一些强制性标准， 比方多言语案牍， 前期会在xml里边手动增加， 后期产品经过渠道配置案牍， R&D长途获取配置后， 去跑本地的脚本， 相当于强制性标准， 包体积标准、图标的标准等等也算是。
咖啡洒在键盘上 Say: Bug需求建使命，并且保护使命状况吗？提测有对Bug率有要求吗？
Flywith24 Say: 需求! 据我所知快手OKR是没有Bug率的查核的， 可是有渠道会去专门的计算Bug率。
不知所云 Say: 在快手和小红书的作业时刻是怎样的？
Flywith24 Say:
快手是双休的，员工手册说是非弹性作业日，早上打卡的时刻区间为 9:30 – 10:30，午休去除 1.5小时，算计满 8 小时即可。
小红书是大小周，周六是双倍薪酬，一般是10:00到22:30左右。
总结&规划
本次共享， Flywith24在BaguTree讲解了 《 小红书、快手的技能沉积 & 架构考虑 》 的方方面面， 包含Kotlin浸透率、研制流程、MVPs 和 LCBs开发结构。 也经过4H方法论考虑了一个合理的事务架构模型需求具备的特质。
假如你想参加BaguTree周六茶话， 那么能够经过BaguTree官网、B站、抖音、 、微信大众号和常识星球找到咱们。
假如你对Flywith24的生长阅历感兴趣， 那么你能够经过github、B站、、微信大众号、博客、小专栏、语雀、CSDN 、微博和常识星球找到他。
咱们是让常识变得更简略的BaguTree ，下周六将是肖会给咱们带来的AI相关课程， 咱们不见不散~
