.. Kenneth Lee 版权所有 2016-2020
:Authors: Kenneth Lee :Version: 1.0
分支设计要领
git极大降低了拉分支的成本，但拉分支的成本从来不在分支管理工具上。
分支的数量是个很让人头痛的问题，因为它是个两难问题。增加分支会增加工作量，减少 分支会增加设计难度。
一个消息调度模块，同时用于科学计算和Web前端两个市场，如果分两个分支来维护，科学 计算分支就可以聚焦在通量上，Web前端就可以聚焦在Latency上，这两个算法显然不一样 ，前者更注重让CPU占满，减少调度的次数，后者更注重加大调度的频度，让高优先级的消 息可以尽快抢占。要在一个分支中同时实现这两者，显然设计难度很高，就算你仅仅是用 编译宏分割，但在避免熵增的设计原则下，你要扭合这两个逻辑都是需要付出不菲的额外 劳动的。
分两个分支就容易多了，这个显而易见，我就不解释了。
但如果你发现了一个公共的Bug，你又开始不爽了，我刚入行的时候，我们的软件做得相当 糟糕，所以同一个产品，有内蒙版本，锦州版本，福建版本，东莞版本……每次发现一个小 Bug，就要一个个版本修改，然后一个个上机调试，测试验证：改一行代码可能就要一个星 期。所以，这个时候你又恨死多分支了。
而同时，市场一线的支持人员却爱死了这个策略：刚刚搞定内蒙的客户，你福建的特性关 我鸟事，打死也不要合进来。
所以，你看，这又是一个道德经处理问题的经典模型——怎么调和这个“众人之所欲”。
所以，我的设计原则是“道法自然”，让这个分支序列自己生成。方法是：
一开始就只有一个分支，全部人力都在这个分支上
谁都可以要求开分支，但需要解决两个问题：
2.1 谁来提供人力来维持这个分支（本质上市场收益是否能支持这个分支的投入），这个 人力是否足够
2.2 为这个分支定义一个Topic，然后证明这个Topic和现有的所有Topic有足够的不同。这 同时也定义了这个分支的生命周期。
其实，这个决策模型很好地体现了无为和不争的的策略。一个技术决策，每个人都盯着架 构师，好像所有的投资是架构师的个人意愿，实际上不是，架构师的个人意愿是“继续给我 高工资就行了”，那几千万，几亿的利润，架构师也不想装自己口袋里。
所以，架构师在整个决策模型上就必须卸掉这个错误的用力方向，让决策面对市场和收益 。 所以，首先是研发和市场两股力量冲突：多少投入可以赚回多少钱。而分支，正是整个 问题面对的第一个决策。无论市场还是研发，都是如狼似虎等着上位的年轻人，你把他们 Assign到一个分支上，他们会用一切手段来证明这个分支才是正道，并表示其他一切都不 重要。一个组织如果让这样的力量正面交锋，所有的力量都会消耗到组织内部，而架构决 策，首先不是决策技术，首先是根据技术的特点去决策资源。一个队列用链表环还是用数 组，这个不用架构师去担心（很多情况下），市场会去削研发的，如果研发选不好这个东 西，你加进去也选不好，因为你根本没有那么多精力。如果你有那么多精力，你就不用招 人了，自己在家开发就好了。
而这个模型中，架构师真正的私货是最后那个决策，因为那个动作对谁都没有直接收益的 ，它保证了整个组织向前进，所有的解决现在问题获得的经验，最终变成组织存在下去的 动力，为组织不断上升提供支持。而其中的控制者，圣人，通过组织的上升达成自己跟着 上升的目的。这就是所谓以其无私，所以成其私。
最后补充一个观点：分支是今天大型软件构架设计中首先面对的问题，如果你不首先定义 好你的分支模型，很多研发和市场的讨论就会聚焦到“功能”和“特性”，不谈“分支”的功能 和特性都是耍流氓，这大部分情况是失去发展能力的开始，架构师需要非常慎重。另一个 方面，展开了架构分支，我们需要面对另一个常见问题，不同分支的质量要求是不同的， 你见过很多产品经理或者质量经理要求每个分支都达成相同的质量目标， 物或损之而益， 或益之而损，不是越多越好的。我们永远面对的不是“道理”，而是资源和目标之间的妥协 。