谈组件化、平台化、自动化

        昨天部门内在讨论热火朝天的讨论一个问题，我们现在的代码量越来越大了，人也越来越多了，上线的时候放生冲突也多了，代码合并困难，线上版本回滚异常麻烦，一个功能模块的回滚会影响到其他模块的功能；

         组件化的关键目的就是为了程序模块化，使得各模块可以单独开发，单独测试，单独上线，单独回滚，减少各模块依赖关系，这样我们前端上一个功能模块，可以它的代码，单独放入svn中，避免了很多不必要的代码合并，减少冲突的发生，单独开发、单独测试、单独上线，可以尽可能小的模块化脚本，减少模块间冲突、耦合的机率，单独上线和回滚，可以加快产品迭代速度与线上回滚效果，试想一下，如果我上线一个模块，但是这个模块依赖另外一个公共的配置，这个公共的配置又耦合了其他模块，那我的这次上线会有多痛苦，我需要考虑这个模块与其他模块的关系，是否我的这个模块回滚会导致其他模块的不可用，我这个模块能否上线，上线会影响什么服务等等，而组件化会对这些问题迎刃而解，已不用关系你的上线对其他模块的影响，你的回滚会干扰其他模块，一切的一切就是你只用干好自己的事情就ok，这就是组件化的优势；

        再来说说平台化与自动化，平台化就是让你代码更加通用，维护成本尽可能的降低，这样我们就必须要实现一些公用的代码，通过代码配置自动的组装代码，我们可以认为我们的代码就是一块块积木，使用这可以把他们随意拼装成他们想要的样子，而开发者只用开发一块一块各种形状的积木，来满足不同的组装需求，这是一个非常理想化的结果，但是往往事宜愿为，我们想要平台化和自动化增强他的可维护性，势必要抽象出公共代码进行整体维护，而公共的部分影响项目组件化，某一个模块的回滚会影响，会连带影响公共代码部分的其他模块，那么平台化势必伤害组建化，这就需要我们权衡下我们的取舍是什么？一般情况下我们会主要关注平台化、自动化，分给组件化的份额会少一些，因为我们开发一个功能的时间往往会要多于一个模块的回滚时间和机率，这或许就是我们关注和平台化的原因吧！