认清它，承认它，然后改变它。
1. 背景
首先介绍下脚手架的定义 —— 类似jeesite，ruoyi，pigX 这样的"平台/框架"，就是本文所定义的脚手架。
这里的脚手架并不是对于这些"平台/框架"的嘲讽，恰恰相反，即使只是从标题中也应该看得出笔者对于脚手架持支持态度。
作为实用主义者，我恰恰认为针对传统软件行业技术团队，这样的脚手架非常值得团队尝试一下，它能够帮助团队快速进入开发节奏，将精力集中到业务代码转换中，而非在低级的技术细节迷宫中循环往复，从而解放业务开发人员，促进技术栈统一等。
2. 矛盾
小到个人，大到团队，都会有自建脚手架的冲动和行动，而且团队规模越大，这样的自建脚手架往往都不止一套。
同样的案例落在笔者身上，在我逐步接手部门技术体系演进职责的过程中，亲眼见证了多套脚手架同步演化，合并，拆分，再合并，最后整体推倒从零开始所谓2.0，3.0等等。
为了在繁重的业务压力，以及各个小组多种脚手架之间谋求一个最大化的平衡和共性，兼顾脚手架针对新增业务需求的适应，技术沉淀等，我们被这些问题强拖着向前，走得心力憔悴。
在经过反复的推演，反思，最终痛定思痛之下，我们决定直面问题，放下"敝帚自珍"心态，从外部购买一套脚手架来支撑我们的新业务需求开发。
3. 理由
到了本文的重点部分。
做出这个决定并不轻松，君不见知乎等各类技术论坛里时不时爆发的争论“ruoyi这种xx设计得跟屎一样，它是怎么发展这么大的，怎么还好意思收费的”，“这个傻叉xx还好意思要钱，这不是个稍微有点经验的研发就能做得出来的东西吗？”等等言论喧嚣尘上。
同样的观点在笔者所在团队内部也出现过，甚至不少是当着我的面吐槽的，这也是本文出现的重要原因。并非为了逞口舌之气，只是相似的疑问一定不止这些人，而我也越来越不喜欢将同样的话反反复复地说，所以正好趁此机会一并落下来，方便之后的解释和回顾。
3.0 根本原因
对于传统软件技术团队而言，没有所谓专门的架构组进行脚手架的创建，维护和演化；自然也不会持续投入专门的精力和时间进行架构和问题的研发和思考。
甚至所谓的架构/平台组往往都是由各个业务研发小组中抽调技术骨干形成的虚拟团队，他们之间往往不会有团队成员的感觉，甚至往往只是技术团队内部自行组建，没有行政上的组织结构以及相应的职责任命。
商业化的脚手架，所针对的正是传统软件研发团队这种规模小，数量多的业务项目特点，可以帮助我们节省大量过往耗费在脚手架演化和磨合上的时间和精力。
这样我们可以将节省出来的时间和精力投入到脚手架的推广和个性化适配上，以及使用问题的快速反馈上来，这样能够实现最快的技术栈统一和知识沉淀，达到我们"技术有力支撑业务"的目的。
这既是本文标题的背景，也是最大的原因。
3.1 放下所有的历史包袱
自建脚手架并非什么心脏手术式的高精尖难题，过往我们也曾经推出过不少自建脚手架，但往往在实际实际的业务需求演进中，为了兼容紧急需求，对脚手架的诸多调整，无法进行深度反思和全局考量，为了追求进度而进行了相应的粗暴实现；而之后又因为缺乏事后的复盘和规整，导致这一粗糙方案被直接复用到之后的项目，最终导致脚手架里充满了各类粗暴实现，以及为了兼容这些粗糙实现而做出的一系列魔法操作，进一步加剧脚手架的问题。
最终的结果就是推出的脚手架不少，但最终能够健康存活，稳步演进的寥寥无几，大家对于既有脚手架心有厌恶，私下自建脚手架的情况时有发生。
商业级的脚手架之下，直接甩下历史包袱，采用新项目新脚手架的方式，将人员技术水平和开发效率快速提升起来。
3.2 不需要瞻前，只需要顾后
过往的脚手架中因为存在大量的历史兼容性代码，往往在每次演化过程中，加入新方案沉淀时候，都要考虑到既有那些魔法实现的影响，结果就是导致对于新需求的响应缓慢，造成业务研发部门对于进度不满，脚手架的落地阻力更大。
商业级的脚手架必然是经过诸多场景检验，并且这些商业脚手架为了收集最多的反馈，往往也会推出各自的开源版本，这样他们对于常用的问题场景都做过相应解决方案，并且这些解决方案之间已经完成了彼此磨合，对于业务型研发团队而言，不再需要这些问题上投入时间和精力。
3.3 真正的难点 - 持续优化
正如前文所说，自建脚手架并非什么心脏手术式的高精尖难题，但凡在这行业里待上数年，做过几个业务系统的，或多或少都私下搭过几个demo级玩具。
- 所谓的自己搭建脚手架，拿开源组件这么攒一下就是搭建的脚手架了，这里面的技术含量有多少，但凡做过demo的心里都清楚吧。
- 而且搭建完"基础框架"，然后呢？ 拿着真实项目把那些已经迭代数年的脚手架踩过的坑再挨个踩一遍，然后发现最终迭代出来的和开源产品越来越像？
- 我们现在身处环境和截至目前我们自身的积累，所作的事情既无法做到前无古人，也做不到后无来者 ；那我们何来的自信会比这些已经拼杀出来的前辈要牛的？ 无非就是因为场景更为具体，做出的假设更多，所以针对性的优化也更为激进，最终造成短期内看上去的效果更好，性能更优。
- 我们要的是解决问题，这才是根本。一个被越来越多人使用，持续稳定更新，有着商业团队维护的框架，在此基础上我们能够解放精力放在自身遇到的特异性业务问题的解决上，才是我们需要的。
笔者接手过一个平台项目框架，一眼就能看出它就是上面所说的demo级一点点搭建起来，在沉重的业务压力之下，谁踏马回给你所谓的"充裕时间"去所谓的重构？ 另外你所谓的充裕时间到底是多久？ 无限远吗? 你跑这上学来了？
而且你会付出额外的努力把你之前挖的坑填上吗？ 用你的行动回答这个问题，至少笔者从接手的项目里是没有看到这个迹象，你会？用你的行动回答这个问题，记住是额外的付出，不是等着别人给你安排任务，让其它人等着你的进度；是在满足不断增长的外来业务需要的前提下，将整个架构重构出来。（你不会觉得别人应该等着你把准备工作全做完了，再开始提需求吧？ 成熟一点吧！）
3.4 最难的部分 - 推广
正如一个成功的开源产品，最大的标志就是其活跃的社区。
对于一个脚手架，生命力的来源也是其周边的生态，而对于传统软件团队而言，这个生态很大程度上就是我使用你这套脚手架，在遇到问题的时候，能不能快速找到相应的解决。
如果是过往我们自建脚手架，那这个事情可就费劲了，你既要思考架构的演进，又要思考脚手架的推广，还要考虑如何回答各个小组反馈来的关于脚手架的问题等等。
三头六臂的你，很快也会因为孤立无援而败下阵来，不要以为初期的热血和口号能够帮你撑过去，这是一个非常长期的过程，并且很长一段时间内不会有什么正面反馈。
如果采纳商业级脚手架方案，那么架构的演进我们就不需要投入过多的精力，毕竟经典28原则也决定，对方所收集到的问题场景绝大部分都是和我们是类似的，虽然注定会有两成左右的差异，但相较而言我们所需要介入的精力就已经少了很多了。
而这节省下的80%精力，我们就可以全部投入到脚手架的推广，以及使用问题的快速反馈上来，通过我们介绍过的传统软件行业技术团队中如何做好知识沉淀等等诸多沉淀化方式，我们可以不仅可以快速建立起团队对于新脚手架的信心，同时也将文档沉淀，遇到问题先搜文档等的良好职业习惯潜移默化地传达给各个研发人员。 而这些在过往是不可想象地。
4. 补充
正如我一直在强调的"要分清楚目的和手段，想清楚哪个是你的目的，然后其它的就都只是手段而已，切不要被迷惑住双眼，把手段当作了目的"。
有力地支撑住业务变化才是我们的目标，脚手架只是手段，而已。
