前端框架的选择、构建和升级
前端框架的选择和构建要基于对业务的支持能力、自身扩展能力、团队对框架的守护能力等几个因素综合考虑。抽象开来比较多个框架的优劣几乎没有任何意义，否则我们将总是会陷入一种抽象的理论探讨而无法进入实际落地的尴尬境地。
如果需要自己从头构建框架应该考虑什么？
目前识别出来的有如下几点非常关键：
1. 可扩展性。
2. 可测试性。
3. 模块化。
4. 开发友好性。
可扩展性：
一个框架如果能够具有可扩展性，能够持续不断的自我更新，那么他就像一个可以不断自我学习提升的人，不管他目前的状态如何都可以不断的从其他的框架(其他人)身上学到新的知识，但他就有无限的可能性，具有很大的潜力去做到自己想做的人。
可测试性:
这框架如果一开始构建的时候，你就一直注意它的质量，给他提供一些单元测试的代码，那么就好像一个人他可以不断地进行自我反省，通过不断的试错来发现每次变化的结果是好是坏来保证它的每一步都是一个正确的、自我提升的过程，而不是一个低级的错误的重复。如果我们对对这个框架进行少量的修改或者是彻底的重构，都可以对它重新进行验证和测试，那么就好像一个人掌握了一个不断试错的能力，他可以不断地通过一些小的事情去验证自己的想法，那么他已经具备了成为一个大师的基础素质了。
模块化:
我们说模块的话指的是什么呢？我们需要把一个框架分为几个模块，每个模块之间尽量解耦，模块内部就有比较紧密的关系，就好比一个人他他把自己的这个技能分成多块，每一块技能他都有足够的深度。每一块技能内部都可以具有独当一面的能力，而技能与技能之间有可以互相促进，但不会因为其中的一部分能力的拓展影响另外一种能力，而导致另外一种能力的退化。每个能力的独自发展的能力可以保证在需要的时候对某个能力进行维持、加强。
开发友好性：
我们所看到的几乎所有产品真的越来越注重用户体验，那我们的框架也要注重用户体验，我们要了解我们的用户是谁，他们希望看到的是什么，哪怕是一个小小的改进，可能对于框架本身来说并没有一个很大的影响，但是对于使用这个框架的人却感觉非常优雅。譬如：一个API接口的调整，框架的文档撰写，这都是对用户体验的一个关注，如果我们不断的去关注这些体验，那么我们的用户就会对我们的产品特别满意，因为我们很多时候说技术并非是决定产品命运的唯一因素，我们的用户才决定了我们的产品的未来发展方向和这个产品到底可以走多远，只有用用户不断去使用、支持、给框架提建设性的意见，然后我们不断进行修复完善这样的架构框架，才能够真正长治久安。
框架需要升级了怎么办？
框架升级所面临的问题非常一致，一个是目前在用的已经生产在用的技术，一个是可能解决目前框架很难解决好的问题的方法，如果直接使用新的技术，带来风险，一直使用旧的技术又无法无法享受使用新的框架所带来的优点。
一种比较切实可行的框架升级的方法是什么呢？
对目前的这个前端框架进行梳理重构，保证目前的逻辑清晰，同时去研究新的技术学习新框架的特点，然后用自己的方式将新的技术运用到目前的框架当中去。
如果新的技术它确实有独到之处，那我们在学习过程中学习不仅仅是他的一些代码，对我们是他的想法和思路，同时由于我们对自己的代码也非常熟悉，通过在源码级别的一个掌握，我们就可以把新的思想应用到我们的代码当中。
以下，我们以编辑器框架为例进行框架的一些讨论:
如果我们的编辑器框架具有支持不断自主更新的能力，那么我们最终想达到的多人协同编辑这个目的就可以实现，那么这个框架就没有上限，它就可以不断的去自我成长，去实现自己的最终目标，根据业务的需要去扩展自己的能力。
我们的编辑器有充分的单元测试保证，那我们做一些小的重构，一些大的改进，都可以通过测试来保证我们的修改是正确的，不会引入给我们带来麻烦，那这样的一种心理上的一个保证就可以使得开发人员乐于参与其中的，每一个开发人员都会积极努力的去改进这个框架，编辑框架就会往好的方向去发展。
框架自身的能力可能是包罗万象的，如果我们能够把它划分到不同模块之中，那我们的新人加入时，就可以选择某个某个模块进行深入学习，尽早具有开发生产力，而我们在需要的时候也可以对某个模块进行重构，同时保证另外一个模块的功能仍然保持正常。
当我们的开发人员抱怨说，某些方法需要反复撰写最基础的代码进行，会引入一些错误时，我们应该考虑将这些代码进行封装，提取出一个比较好的抽象的接口，这样的话让我们开发人员去调用这样的接口，而不是反反复复重新去拷贝复制那些基础的代码，这样的话我们开发人员就会感觉体验得到了提升，那么他也会乐于参与框架的开发，因为这对他们的开发也是有好处的。