后端技术 by Tim Yang

又一次团队沙龙，这是一个每周一期的活动，探讨技术或团队一些问题。

首先，介绍一下本次讨论的背景，参与讨论的是一个多团队的部门，每个团队有不同的职责方向。因此，大部分跨团队的各种技术或协作问题也会碰到，典型的一些场景：

• 需要升级一个公共库，但是通常并没有一个职能部门来负责公共库升级事项（即使成立也可能最终成为“全国假日办”之类的机构）。
• 或者是当你负责一个被依赖的模块，当你需要升级时候，发现不少使用方对老版本的feature依赖比较严重，而他们没有精力（或兴趣）迎合升级做大的修改。
• 团队多了之后，缺少全局的依赖管理，调用之间可能会出现循环依赖的情况（还有间接的循环依赖更复杂）
• 引入新的第三方库，可能有些团队觉得方便就直接引入了，但又造成了内部使用方法不统一的问题。如果部署在相同的节点，还会对别的模块带来污染的问题。
• 部分相似的功能大家重复开发，比如一些开关降级工具、发号器等。另外一个层面，A team在开关降级方面新开发了一些实用的feature，但是B team也用不上
• 从team leader的角度，首要关心的问题是项目的进度及交付目标。因此软件结构的合理性、代码的优雅性以及系统的可扩展性等层面，可能出现优先级未得到保证的情况。“等忙过这一阵，一定要好好重构”，但由于拖延症，长期得不到实现。

在正式展开讨论之前，介绍一下《人件》原书第三版（感谢华章）中的一个黑衣团队章节。说的是一公司，软件在客户那里出现了很多问题。但由于开发工程师是一群非常有个性也聪明的人，从来不认为自己的代码有问题。因此解决这个问题，公司引入了一群非常有才能的测试工程师，为了更加有个性，他们开始都穿上黑色的衣服，系统一旦有BUG他们就可怕地笑起来，他们的测试根本不是在支持开发人员，而是乐于将软件与工程师放到一种不是测试而是折磨的工序下面；他们还经常聚在一起研究出十分可怕的测试策略，他们一些变态的想法与测试方法让开发工程师望而生畏，欲哭无泪。由于这样一个机制，软件工程师在交付之前自己会进行各种极端的健壮性及正确性判断，最终这个团体逐渐形成自已的个性，也发展了一种渴望并期待发现产品缺陷的哲学。这个机制在不断有人离开的情况下仍然在团队内完好保存。

但是在重构这个问题，如上面几点所说，团队找不到一种类似凯文·凯利《失控》中描述的机制，不健康的问题第一时间得到了处理。这个可能也是在不少公司同样存在。因此一些主要提出的方案观点如下。

体检及手术式

由于上面提到的各种问题，技术体系的健康遭到侵蚀，各个团队还承担各自业务压力，大家的人力资源宽裕程度也不一，因此第一种观点对这些不能及时消除的隐患的存在表示理解，也能意识彻底解决问题的复杂性，但隐患也不能长期不理，因此提出跨团队巡检队定期检查的思路，并将发现的问题列举出来，在约定的时间内完全解决。

这个做法的逻辑有点类似生活在帝都的IT民工们，在糟糕的雾霾环境下承担着工作的重压，身体健康状况自然不好保证，但也无力改变现状，因此只好通过每年体检来发现身体大的隐患，并尽早排除。

改变导向式

这种观点的出发点是人都有惰性，即使有合理的重构理由，在系统还可以勉强运作的前提下，人是没有充足动力去做改变。即使这时候有人跳出来大声疾呼，也不能得到充分的支持与理解，造成了一种机制上的潜在障碍，让健康问题不能第一时间得到解决。

《人件》第34章标题就是改变成为可能，其中提到，因为人们都不喜欢改变，而你想促成改变的发生，所以你就站在了人性的对立面，自然你就会受到他人的挑战。

“People hate change…
and that’s because people hate change…
I want to be sure that you get my point.
People really hate change.
They really, really do.”
– Steve McMenamin, The Atlantic Systems Guild, 1996

为了避免这个情况出现，团队需要实行一种“改变为先”的共识 — 只要有人提出一种新的升级（新版本、框架、工具等），团队其他成员原则上不可以提出反对意见。尤其在公共工具库方面，倾向采用在框架配置层面强制升级，再让所有成员被动升级的做法。

《人件》中有关改变的观点则引用萨提亚模型(Satir model)，其主要观点是，改变需要至少经过4个阶段，其中的3、4阶段如果没有经历，改变不可能真正落地。因此对于软件开发这样一个以人为本的实践活动，充分意识到混乱也是新事务出现以后的一个必经之路，但混乱不是终点站，有很多团队在做改变时候，从3直接又回去2了。

多数派决策式

这种观点的出发点是大的系统、背后大的团队以及成员的关注点及诉求点的多元性。比如

张三：关注点在存储的成本及效率，由于精力原因，对于公共组件库采用跟随策略，并期望最小的参与成本。
李四：喜欢尝试新框架，如果团队引入了某个公共的开源框架，对社区每个小的升级迭代充满兴趣，希望将每个版本即时引入到公共库中，并希望所有团队调整自己的代码，跟随及时升级。

在认可团队多元化价值观的前提下，这个问题不能简单总结成采用某种“稳健型”或者“积极参与型”的思路来决策。但为了团队重构的机制能够存在并运作，可以由各团队选出一名技术代表，每周来讨论一次公共的技术重构事项，并按照多数派的意见进行执行。

当然上面只是部分主要观点，由于本次讨论各方参与激烈，本文章不做结论，欢迎大家留言介绍你们团队在系统重构方面的做法及机制，希望能从中找到类似上文《人件》或《失控》中描述方法类似效果。

对微博平台技术沙龙感兴趣的朋友，可以在微博关注话题 #平台技术沙龙# 或微信搜索公众号“WeiboArch”（a.k.a 微博平台架构）来参与。