传统软件行业技术团队的发展 - 做好技术栈统一

1. 前言

对于一个团队而言，规模越大，对于标准化，统一化的需求也就越发强烈。而传统软件行业中技术团队因为其自身特点（传统软件行业中技术团队的发展(现状篇)），对于标准和统一的推进处于一种游离态：

1. 承认规范和统一很重要，但实际执行时却总是不断让位于迫在眼前的业务压力。
2. 建立的标准纸面化，规范订立出来之后，万里长征就算是要到尽头了，剩下的就只需要下面这些组员遵照着执行就得了，这点小事就不要再来烦我了，这一块的问题就算是解决了。
3. 标准的推陈出新。针对某类问题，得出个规范来协调各方的操作规范，过两天觉得另外一种方式好像更好，咱们要不试试那个？

“大幅降低团队的沟通成本，减少系统的维护成本”，这些标准化和统一所能带来的好处，并不能让"统一"这件事自行发生，我们需要结合自身团队特点，通过不断对比理想和现实，制定循序渐进的实施路线。

本文接下来的部分，我们探讨传统软件行业中，技术团队如何切实做好技术栈统一。

2. 历程

过去这些年，面对技术栈不统一，同一类技术问题反复解决，各自为战的状况，我们按照时间顺序，尝试了多种方案。

2.1 平台化

传统软件项目特点是项目规模小，周期短，数量多；这类背景下，基于开源组件搭建一套通用的解决方案平台， 之后以此为基础，在新项目中推广和迭代这套平台，寄希望于实际项目的历练，将绝大部分解决方案直接集成到平台里，最终实现理想中的搭积木式开发模式。
不过理想很丰满，现实很骨干，实践中我们发现这种单一的方式存在诸多问题：
a. 传统软件行业项目开发周期确实短，但维护周期长，导致平台在优化过程中，要不断考虑兼容既有版本的问题。
b. 业务需求紧急导致项目组与平台维护之间容易面临利益冲突，经常出现项目组等不及平台的改进而自行选择实现方式，而当这个项目组被安排接手另外一个项目时，他们很大可能不会选择基于最新的平台版本，而是选择他们之前已经熟悉的那个旧版本，也就是平台版本出现自行分支，并随着时间的发展不断增加。
c. 平台无专人负责维护。平台维护名义上虽然是指定给了某几个人，但实际上这份职责十有八九属于兼职，这导致平台发展缺乏规划，解决方案思考深度不足等问题，随着时间的发展，平台越来越复杂，脆弱。
d. 平台化这一解决方案粒度太粗。平台作为大一统的解决方案集合，已经接入的项目组不可能因为某几个新增功能或优化选择进行平台升级。平滑迁移诱惑巨大，但其中涉及的巨量精力投入对于传统软件行业技术团队而言，性价比并不高。
e. 以上这些问题交织在一起，相互影响，导致平台的演进举步维艰，慢慢地各方都开始刻意回避与其的交集。

2.2 组件化。

针对上述平台化的种种弊端，我们很自然地想到通过减小版本更新影响范围，来快速响应需求。解决方案组件化也就顺理成章地提上日程。

这一步在试行过程中，也是碰到了一系列问题：

1. 依然是业务紧急下的短期利益与长远利益的冲突。
2. 组件化虽然将版本更新的粒度细化，但版本更新，平滑升级等这些问题并没有被解决。平台化遭遇的那些问题，组件化并没有幸免。
3. 组件化加快需求响应速度的同时，也让组件与既有项目之间出现冲突的可能性大大增加。
4. 臆想中的主动参与组件维护人员并没有出现。

2.3 文档化

平台化和组件化的效果大幅低于预期，这一现实让我们不得不重新审视团队：

1. 传统软件行业技术团队中，对研发人员的约束力并不强。薪资的吸引力，以及业务压力等诸多影响因素，负责人与组员之间就进度和质量商量着来的现象并不鲜见。
2. 部门主管对项目团队施加技术影响的机会其实很有限。除了最开始确定项目技术框架，以及某些项目组遇到无法快速解决的技术问题外，其他时间领导即使有心，也只能感慨无力回天。

以上这些原因，加上平台化和组件化下暴露的种种弊端，让我们开始正视一直被我们刻意回避的方式：解决方案文档化。

之所以一直回避这个方案，原因其实很容易想到：

1. 很少有人喜欢写文档，即使已经在理智上百分百赞同文档的重要性。
2. 偷懒，想走捷径。对，不论如何粉饰，根源其实都是它。我直接把方案整成代码，然后告诉你怎么调用就完事了。

而解决方案文档化的优势，总结下来：

1. 老生常谈的沉淀。文档更容易让一类问题的多种解决方案共存，并将选择权交给使用者，这可以大幅降低使用者的抵触，也能潜移默化地对使用者进行影响，让他们参与到文档化的建设中来。
2. 传统软件行业技术应用程度浅，重复率高等特点也使得文档化的工作量并不大，且ROI颇高。一般四/五轮迭代之后，某类解决方案就只剩下机械式地复用了，慢慢地问题解决方案也就统一了。
3. 相较于平台化和组件化这两种方式要求比较高的技术水平，文档化则是真正的全民参与。遵循“你的疑问不是第一个，也不会是最后一个”，任何人只要有意愿，都可以作出贡献，而且这类贡献属于与技术能力关系并不大，有助于团队的全面发展。

2.4 阶段性小结

纵观以上演化历程，其实就是一个不断被迫直面现实，解决问题的过程。

1. 一开始就想要进行平台化建设，就是寄希望于一次性解决所有问题；之后的组件化，文档化则是在意识到一步到位不现实之后，逐步调整得到的方案。
2. 事物的发展有着其内部自有规律。技术发展确实可以让后来者享受红利，让后来者以更快速的速度翻越前辈曾经遇到的高山，但这并不意味着你可以直接省略这些步骤。

3. 究其原因

针对上述历程中遇到的问题，让我们尝试汇总下其原因：

1. 项目需求不断演进的同时，平台本身也在发展，没有专门的团队维护，平滑过渡本身也是一个非常考验个人和团队能力的要求，破坏性升级之下导致小组很容易在已有基础上修修补补，平台优化各自为战，发展进入停滞。
2. 历史原因造成各项目技术框架依赖不一致， 导致虽然都是属于平台内解决方案，但无法保证升级的平滑，很容易出现依赖冲突，缺失等问题。
3. 既有人员对熟悉技术的固守。如果研发人员熟悉了某类问题的一种解决方案，那之后如果不强势介入，十有八九这个方案会落到他经手的每个项目里，即使针对这类问题框架里已经存在。
4. 指导性/监管力量不足，底层则会恣意生长，按照自己的思路形成秩序。如果你不能进行事前或者事中的及时介入，一线自己会寻找问题的解决方案，并且会在团队内固化该方案。最终敝帚自珍也吧，自私也吧，造成小范围自嗨，进而出现小组脱离整个团队独自演化的问题，这种场景下平台化/组件化/文档化这些方式都将不再具备任何效果。

4. 如何做到技术栈的统一：

4.1 平台化，组件化，文档化，三方案并行。

上述三个方案各有其优缺点，为了最大化地覆盖问题场景，确保持续推进，我们需要综合应用这三个方案：

1. 平台化主要是针对新项目。传统软件公司内部培训体系很弱，人员培养基本都是直接在正式项目里边干边学。针对这样的特点，在新项目建立之初团队强制要求以平台为基础，可以快速建立起一个统一的技术栈基础。
2. 组件化主要针对历史项目，用于解决某类问题(例如操作office，附件上传下载等)，实现问题的快速响应，解决方案的沉淀。并且经过多轮考验的组件会作为默认基础依赖集成到平台中，形成互补。
3. 文档化的受众也是以历史项目为主。传统软件技术团队管理权限不足的问题决定了很多改变只能用潜移默化影响的方式实现，而文档化解决方案正是这一需求的典型实现，通过提供已验证的，详细步骤的解决方案来吸引团队成员熟悉和使用，进而逐步形成针对某类问题的团队统一方案，进而降低系统维护成本。

4.2 强化过程检查

对于传统软件技术团队而言，过程检查基本都是形同虚设。不论负责人，还是实际的组员，大家都会非常默契地将系统验证时机不断后延，直到系统马上要进行客户验收，迫不得已才会组织少数几次集成测试，至于测试效果如何？相信大家都有切身感受，“集成地狱”这个业内鼎鼎有名的词能够传承这么些年，已经很说明问题了。

在传统软件技术团队中推行制度，需要被牢记的一条准则是对其执行情况的检查，尤其是在初期，绝对不能以人工力量的投入作为必要条件。检查操作里人工占比和制度最终落地的失败率成反比，人工检查步骤多一步，制度落地概率就降低一成。

因此，过程检查落地的最佳实践是审视现有研发流程，找出可能的门禁设置点——例如代码提交阶段的静态质量检查，提交日志格式规范检查，非文档里推荐的问题解决方案的检查等等，这些机器自动检查能够协助我们在问题发生初期进行及时的介入，实现低成本地纠正问题，确保团队在技术栈统一的道路上不断前进。

5. 后记

传统软件行业里，对于技术栈的统一更多是处于一种间歇性踌躇满志，持续性放任自流的态度。

但这并不意味着传统软件行业里都是不思进取之辈，传统软件行业的特点以及真实存在的人员素养差异确实让传统企业在技术体系的构建上步履蹒跚，进步缓慢。

表面上看不到并不代表改变没有发生，一次次的铩羽而归只是代表我们当下的认知与现实情况不符，只是代表我们需要进一步调整自身来适配当下的环境。

也许你会不忿，你会不甘，你会哀怨自己为何要选择和这帮人一起共事？ 你会想要离开，去追逐更好的发挥才能的地方，这都是人之常情。

但如果因为各种原则你选择留下，那还请不要灰心，不要放弃，既然你已经做到了这一步，那为什么不继续坚持下去，毕竟能够走到一步的，一定是花费诸多额外时间和精力自我训练，希望不被茫茫人海淹没的，所谓为了自己心中的骄傲，继续寻找破局的办法吧。

6. 参考

1. 传统软件行业技术团队中如何做好知识沉淀