探索前端重构之道-通天塔如何建成

构建卓越系统之必经之路－持续重构

通天塔的传说

《创世记》第11章

创11:1　那时，天下人的口音、言语，都是一样。

创11:2　他们往东边迁移的时候，在示拿地遇见一片平原，就住在那里。

创11:3　他们彼此商量说：“来吧！我们要作砖，把砖烧透了。”他们就拿砖当石头，又拿石漆当灰泥。

创11:4　他们说：“来吧！我们要建造一座城和一座塔，塔顶通天，为要传扬我们的名，免得我们分散在全地上。” 创11:5　耶和华降临，要看看世人所建造的城和塔。

创11:6　耶和华说：“看哪！他们成为一样的人民，都是一样的言语，如今既作起这事来，以后他们所要作的事，就没有不成就的了。

创11:7　我们下去，在那里变乱他们的口音，使他们的言语彼此不通。”

创11:8　于是，耶和华使他们从那里分散在全地上；他们就停工不造那城了。

创11:9　因为耶和华在那里变乱天下人的言语，使众人分散在全地上，所以那城名叫巴别（就是“变乱”的意思）。

通天塔的解说

宗教性的语言可能有些人无法理解，简单地描述：曾经有一群人，觉得自己比较牛，想建一座高塔，目标可能是为名利也可能是为了服务人民。 然而，神却只用了一个很小的伎俩就让人类放弃了这个想法:让他们有不同的语言，产生分歧，半途而废。

通天塔的传说其实是个寓言，这个寓言在描述一种关于构建大型项目和创业公司所面临的在不断演变的外部环境情况下， 构建一个近乎不可能 成功的复杂系统的情况。 譬如，一个小公司，小到几十个人，大到一两百人，甚至上千人的规模。 只是，这种体量跟真正的国际性大公司相比，仍然是 不堪一击，想真正成为一个卓越公司，譬如BAT等国内顶尖网络技术公司，譬如IBM等国际性百年大公司，其难度不亚于建一个通天之塔。 眼看他起高楼，眼看他宴宾客，只是最终是否能够基业百年真的是很难预测了。 而所谓的神的干扰，在现代社会就太多了，譬如核心人员的离职，管理团队内部的分歧，公司在关键决策博弈权衡等。 建通天之塔，必定要集结众人之力，团结一切可以团结之力量，此外也必须要不断有阶段性成果，持续不断的坚持积累， 才能鼓舞大家继续向前，最终达成目标。

公司本身的演变是 非常复杂的，创始人的胸襟，公司层面的决策，市场和政府的政策都会受到影像，这些不是本书所要阐述的话题。 本书企图对一个复杂系统的前端项目的构建，重构，维护做一些简单的探讨。 个人学识有限，只能对前端相关领域进行探讨。 万宗其实同源，现在技术社区一直提倡的全栈，其实在是在对某一方面进行深入研究后，知其然并自其所以然，从而触类旁通，举一反三。 很多思想和方法也是从其他语言中学习而来，其中一些理念对于其他语言的使用者应该也有些借鉴意义。

建立通天塔到底有多难

神的伎俩－－如何解决分歧。

文无第一，武无第二的框架和语言之争往往在不同公司不断上演。 框架的选型往往让很多人不能达成一致，很多人都会觉得是在委曲求全，频繁的架构变动甚至导致很多之前的积累功亏一篑（基于系统的自动化测试，单元测试等）。 可以理解的是很多程序员倾向于选择自己比较熟悉的技术栈，在一个团队中如何能够彼此协作，真正具有一定的生产效率就不仅仅是个人喜好的问题了。 不管是管事还是管人,如果架构的选择充满个人色彩，无法得到整个团队的支持，如何做到心往一处想 劲往一处使？ 对如何建塔产生分歧应该是常有的事情，如何解决这些人民内部矛盾？

人员流失－－如何让智慧得以传承。

在建造通天塔的过程中，人员流失几乎是肯定的，因为人的寿命有限啊。 铁打的营盘水做的兵，塔建成一半，之前做底层架构的技术人员不在了，拆塔重建还是以此为基础继续构建，如何让前人的智慧得以传承和发扬光大这是值得思考的问题。 如何在分工不同的情况下，让每个人感受到平等和尊重。重复的 业务代码撰写可能导致员工缺乏成就感，从而降低对公司的持续忠诚度，如何让那些搬砖头的感到自己在从事有意义的事情呢。 如果团队中的人员无法获得能力和技术的提升，一方面无法提高生产力，也会导致员工的倦怠心理。

长远规划－－如何看待技术演变。

很多重要决定都是在我们不完全具备所有信息的情况下做出的。 譬如我们的文理科分班，专业方向，第一份工作的选择。 我们在无法预知未来的技术发展的情况下，需要完成通天塔的基础工程，而后我们的很多工作基于这些基础进行构建， 我们必须确保这个基础足够健壮和稳固并具有很好的扩展性，即使之前的设计理念在未来看来显得不够灵活。 任何一次的推倒重来都会让通天塔的建设回到解放前，增加建造失败的概率。

可能的答案

当你提出问题的时候 其实内心里 已经有了想要的答案。 本书以“通天塔”的问题开始，但答案却已经给出: "持续不断的重构乃是构建通天塔的必有之径！"。 建立完善的标准和自己的一套框架，避免对于某个技术框架的个人喜好导致项目蒙上个人色彩； 自动化测试和完善的文档来保证智慧得以传承； 遵循最基本的设计模式和规范，不盲目追求新的技术，通过适配器等模式允许系统各个组成部分可以被 无缝替换和升级。

本书的机缘

最近一年，主要在重新实现一个原本外包的复杂业务系统(前端)，并不断重构和优化这个系统。 经过技术选型，初版上线的bug泛滥，上线后一个月的紧急修补问题，再到逐步优化，提取公共函数成为支持其他应用开发的框架，算是经历了一个完整的系统重构过程。 然而，为了实现技术栈的统一，经理提议要用新的技术栈再重构这个系统，虽然系统本身并不能说是非常复杂，然而也是两三个同事的近一年多的加班工作的成果，突然说要重构，而且 原来的代码一点不留，还是挺让人难以接受的。 更无法理解的是，其实从系统改造完成之后，这个系统本身也在不断被开发人员“重构”。 在经理眼里，这些重构都不是真的重构了。 难道只有使用新的技术栈重新实现一遍业务逻辑才算是重构吗？

对于构建和维护一个可用的复杂业务系统，大家的共识都是要“重构”，然而对于如何重构却有完全不同的理解。 在会议上，大家东说一句，西说一句，谁也说服不了谁。 会后仔细思量，还是自己对重构的概念理解不清，自然很难讲清楚，也说服不了别人。 在此根据自己的理解对前端系统的重构进行一些阐述，同时总结一下在系统重构方面所做的工作，也希望对同行有些帮助。