刘帅，腾讯CDC高级工程师，曾供职新浪、阿里巴巴、腾讯、百度、小米，参与过媒体、电商、工具等不同类型产品开发，也曾参与餐饮共享与互联网医疗创业，翻译过几本技术书籍，现在主要负责前沿工具及平台的研究与开发。
· 以下内容摘自于作者talk演讲稿
1. 缘起
2006年， 有一部电影——《墨攻》，讲的是战国时期，一个墨家弟子一个人守一座城的事，电影的故事是编的，今天我来讲一个真实的故事。
去年3月，广州有一个政务项目需要我们紧急支援，于是我老板把我扔过去，跟我说去两个星期就回来，然而，两周之后，变成了再过两个月后就回来，两个月后呢？这么说吧，今天我做完这个分享，又要去广州了，……
我还是太年轻。
2. 局面
到达广州之后，我大致了解了一下当时的情况。
这是一个政务小程序项目，开发团队由腾讯主导，以数字广东为中心团队，管理供应商共同开发，项目以业务模块为单位分成了很多个独立的小程序，离项目上线还有不到两个月。 但是很快我就接到一个任务，要把这些独立的小程序合并成一个，这是为什么呢？
3. 问题
其实像这样一个项目分拆成这么多独立小程序还是有很多问题的，通常我们会认为一个项目就一个小程序，比如我以前做“吐个槽”，别人找我要小程序码，我会给他这个。
但如果这个政务小程序以当时的方案做下去，别人找我要小程序码，我可能会给他这个。
这个真的一点都不夸张，到目前为止，供应商已经扩展到30多家，如果以当时的方案做下去，真的会有这么多小程序的。
用户使用的时候，小程序的最近使用记录会是这样的。
全都是各模块小程序的使用记录，其他小程序都无处安身了。
除此之外，还需要不断申请AppID，这个概念有点太技术，我讲个通俗的例子。
比如我要开一个店，那就需要办理一张营业执照，这没什么问题。
这个店有多个柜台，现在相当于每一个柜台都要办理一张独立的营业执照。
而且以后每新开一个柜台，都要再办理一张营业执照，想想就觉得很繁琐。
分成这么多独立小程序还有很多其他问题，比如说技术上数据的互通，安全管控，AppID的后续管理等等，就不一一列举了。
4. 解决方案
如此看来，必须要合并，也必然要合并，就看用什么方案来合并了。
4.1 合并源代码
当时有人提出合并源代码，这是个什么方案呢？我打个比方，假设这个项目是用Photoshop做一张电影海报。海报分成几个模块分配给供应商，这里的PSD文档就相当于小程序的源代码。
合并源代码就是把分配给供应商的各模块PSD文档重新收回，合并成一份完整的PSD文档。各团队在这份PSD文档的上去做自己所负责的模块。对应到小程序里的概念，整个项目只有一份源代码，生成一个小程序。这就是合并源代码方案。
但这个方案被我否决了。为什么呢？有3个问题。
-
切换成本
-
冲突风险
-
泄密风险
4.1.1 切换成本
有什么切换成本呢，我举个例子，这就好像很多独立的小公司现在合并成一个大公司，所有原小公司的组织架构都要调整。原来的总裁，现在变成了副总裁，原来的职能部门，比如人力、财务、行政部门，现在都合并在新的大公司了。整个公司内外要适应这种变化是需要成本的，但这种成本不会有任何的实际产出。
在我们的项目里也是一样的，要做这样的调整，也就是要给供应商加工作量，当然也会给我们自己增加工作量，供应商说，行啊，加钱！但即便花了这个钱，当时离项目上线只有不到两个月时间，这样的成本耗费没有任何实际收益。
4.1.2 冲突风险
原来各供应商只需在所负责模块的代码上开发，不用担心与其他团队相互之间的代码干扰和冲突。
但现在所有模块代码合并成一份，大家在一份代码上开发，就不可避免地存在干扰和冲突问题。
有冲突就有解决冲突的成本。根据过往的经验，解决冲突需要相关人员聚集到一起协商解决，所需时间从几分钟到数小时不等，这个时间成本还会随着模块数量的增加而呈指数级增长。
4.1.3 泄密风险
泄密风险就比较好理解了，原来各供应商都只能看到所负责模块的代码，看不到其他模块的代码。
但现在所有供应商都能看到整个项目的所有代码，保密性远不及原来的方案。
这是一个政府项目，对保密性的要求比一般项目更严格。除此之外，这些供应商之间相互也是有竞争关系的，也并不希望自己的代码被其他供应商看到。
4.2 生成合并
既然我否定了合并源代码方案，当然要提出自己的方案，不然就是耍流氓了。
我主张因地制宜，顺势而为，维持各模块源代码独立的现状，做一个工具，自动收集各模块源代码，校验规范，合并生成一个小程序。
牛逼吹出去了，那就动手做工具吧，我们办公地点就在珠江边上，于是我有机会见到了很多次凌晨4点的珠江江边，……
5. 做工具背后的小心机
好在那些凌晨4点下班的夜晚没有白费，我很快做好了工具并投入使用，但其实我做这个工具并不仅仅是为了合包，而是要对供应商实施有效的管控。
在此之前，我们对供应商的管控力度是很弱的。就拿规范来说，我们的规范早就写好了放在那里了，但落地效果很差，供应商懒得看，我们也懒得查，供应商说，我这个运行得好好的啊，为什么要过一遍这个规范，而我们自己也因为校验成本过高，而睁一只眼闭一只眼。
但现在不一样了，供应商做的东西要交付吧，我们交付的基本要求是能够成功合包，这也很合理吧，结果你现在交过来的代码合包失败，那你改不改？
所以，通过这个合包需求，我成功地把一个工具安插到了供应商的日常工作流程中。
6. 插入工具后的收益
工具投入使用后，很多问题都迎刃而解了。
6.1 公共模块的更新
工具投入使用之前，有一个很头疼的问题，我们的公共模块，供应商更新很滞后，因为当时更新都是手动更新，及其麻烦，而且动力不足，因为有时候不及时更新公共模块并不会立刻暴露问题，但长远看是有隐患的，必须保持各供应商使用的公共模块是最新的。工具投入使用后，我做了一个一键式更新公共模块的功能，公共模块的更新率显著提升。
6.2 技术客服
工具刚投入使用的时候，很多工程师每天都在群里问我有关合包的错误原因和解决办法，我发现大部分问题都是重复的，而我却需要一遍一遍地去解答，完全成了一个技术客服，严重占用我的时间和精力。
我就在工具上加一个诊断功能，将诊断结果及相关错误的解决办法详尽地罗列出来，就像医生诊断一样，为了方便记忆，这个功能就叫Doctor。
功能做好后，我只需告诉工程师如何使用，工程师就可以自行诊断错误并修复，而不再需要我一遍又一遍地人肉解答。
6.3 老板的诉求
过了一段时间之后，有一天，我正在专注地写代码，突然老板找我要最新的产品DEMO。
虽然思路突然被打断，多少有些生理上的不适，但毕竟这是老板。
你懂的。
好在生成的主要流程都已经自动化，很快我把最新版DEMO给到了梁生。
随后几天，梁生还是会毫无预兆地找我要最新的产品DEMO，虽然每次并不占用太多时间，但这样频繁地被打断思路还是有点难受，而我又不能拒绝，毕竟这是老板。
如何解救老板，解救自我呢？
老套路，我在工具既有的基础上稍加整合，做了一个一键式合成产品DEMO的功能，为了方便记忆，我把这个功能就取名叫BOSS。
当梁生再找我要DEMO时，我向他推荐了我的工具以及这个BOSS功能，后来，他就再没找我要过DEMO了。
但其时，难道这个需求真的是我为老板定制的吗？当然不是，我发现其实是有一个人群有这样的需求，一切非一线开发人员并且有需求和权限查看整体效果的人都会有这个需求，我的老板，兄弟团队的老板，老板的老板，或者其他职能的人，比如测试人员，都会有这个需求。
7. 总结
最开始，我只是要做合包，衍生出了一些规范，为了高效准确地校验规范，催生出了工具，工具实际实施了合包，也实现了部分工作的自动化，得益于自动化的高效性，又反向推动了更多规范的落地实施。
工具，承载着合包、规范、自动化。
如果我们再进一步看。
合包是什么？合包其实是我们实现与供应商合作开发模式的一种做法，是术。
规范是什么？规范就是我们制定的开发规章制度，是法，是必须遵循的原则。
自动化是什么？自动化在这里就是效率，是我们追求的生产理念，是道。
而工具，就是承载道、法、术的器，将复杂的问题简单化，帮助更多人更快达成目标。
上个月，另一个城市也要做一个类似的政务项目，因为保密要求，我不能透露是哪个城市。
但这一次，已经不需要我常驻在那里了，因为，我的工具在就够了。
以上，是我们前往广州辅助粤省事小程序工程管理的所做所想。
那么，定位为公司辅助的TEG，又该如何呢？悟道？循法？御术？造器？
观看视频：
如果您觉得内容不错
请点击屏幕右上角按钮【分享到朋友圈】分享内容
更多精彩内容请关注公众号：tx_cdc
本篇文章来源于微信公众号: 腾讯CDC体验设计
