技术架构

算法

对称二叉树

给定一个二叉树，检查它是否是镜像对称的。

例如，二叉树 [1,2,2,3,4,4,3] 是对称的。

但是下面这个 [1,2,2,null,3,null,3]，则不是镜像对称的

我的解法是采用先序遍历和后续遍历得到结果，然后对比两个遍历结果，首尾是否相等。

    var isSymmetric = function(root) {
        if(!root) return true;
        var arr1 = [];
        var arr2 = [];
        inOrder(root, arr1, arr2);
    
        var res = arr1.some((item, index) => {
            var _num2 = arr2.pop()
            if(_num2 === undefined || _num2 !== item){
                return true
            }
        });
        if(!res && !arr2.length){
            return true;
        }
        return false
    };
    const inOrder = (root, arr1, arr2) => {
        if(root === null){
            arr1.push(false)
            arr2.push(false)
            return ;
        }
        arr1.push(root.val);
        inOrder(root.left, arr1, arr2);
        inOrder(root.right, arr1, arr2);
        arr2.push(root.val)
    }

更好的解法，在递归的过程中就进行对比，将对比结果直接返回，空间复杂度会降低。

    var isSymmetric = function (root) {
        return helper(root, root)
    };
    
    function helper(l, r) {
        if (l == null && r == null) return true;
        if (l == null || r == null) return false;
        return (l.val == r.val) && helper(l.left, r.right) && helper(l.right, r.left)
    }

技术为业务服务，在做技术架构的时候更多的是要在成本和业务要求之间寻找平衡。业务要求为第一优先级，在保证业务需求的基础上尽可能的降低成本。这个成本有技术架构本身的成本，也有团队成员的学习成本，还有后期的维护成本，并且技术架构还需要根据未来的业务变化进行不断的演进。最终达成高效高质量的推进业务。

底层建设

面向中小型前端技术团队，在建立技术架构的时候应该从全盘考虑。底层建设指的是选择适合的技术栈 + 脚手架，建立整个基本的开发流程。

技术栈统一有好处也有坏处，好处是降低学习成本，降低项目间的维护成本，并且强依赖单一技术栈也会加强对深度的了解。缺点就是不能全面的衡量一个业务最适合什么样的技术栈，可能有更合适的方案，但是由于技术栈的限制只能退而求其次。

脚手架统一是为了不让团队成员在构建项目时重复的去关注周边环境的设施。通过脚手架统一整个工作流程，让整个工作流程模块化、组件化、自动化、规范化、标准化。并且统一的环境配置可以降低学习成本，在升级的时候也可以做到一处升级全栈业务就进行升级了，但是缺点也是定制化程度降低，一处升级了所有业务，但是也需要大量的回归测试。

站在整体效率上看我比较倾向统一技术栈和底层开发模式，从目前技术架构的实践上来看是达到了我的预期，高效高质量推进业务。

SPA or MPA

这两种架构已经是当前非常主流，优缺点也非常明显的架构了，SPA 单页面，更流程的交互，页面与页面之间的切换，构建富应用能更加得心应手。缺点初始资源加载太大，很多不会被用户使用到的资源也加载进来了。这个可以一定程度上的优化。首次白屏时间较长，并且不利于爬虫爬取

MPA 按需加载，首次白屏时间不长，访问哪个页面加载哪个页面的资源，能做 SEO，但是页面与页面之间跳转的时候有白屏时间，不太流畅，页面之间的状态不容易保存。

解决方案

底层建设考虑好了之后，往上在去做各种业务形态的解决方案的时候就要好做一些了，基础的基调已经定下来了。

前端在建立解决方案的时候更多的是考虑端，我们的业务分为五端，每端根据当前的业务形态建立对应的技术解决方案。技术栈 + 工程化 + 端的调整。

在每个端的解决方案构建的过程中，逐渐将工程化也统一起来，相同的目录，组件化拆分方式，引入其他模块的方式等等，这些的统一进一步的降低了项目间的维护成本和学习成本，也降低了团队成员离职所带来的风险。

端的调整，我认为不同的端会有不同用户习惯和业务侧重。不同的端 PC、自助机、web，这些会有不同的用户习惯，现在 PC 上处理的大部分是重信息、多交互的功能，自助机上处理的是服务落地、硬件交互、简介信息的处理，web 是移动端便捷操作，内容适中，精致的交互。这几大类我认为是不同端的用户习惯不同。

之前有人问过我同是移动端为什么说用户习惯不一样，我觉得同是移动端用户的交互习惯可以差不多，但是业务侧重点会有不同。由于现在的寡头 APP 效应其实 web 的流量占得很小，我觉得 web 比较类似流量小一些的微信公众号的业务侧重，微信公众号我们期望快速拉新，简要服务提供。小程序我们期望高质量的服务承接和落地。APP 我们期望用户留存，提供业务服务的闭环。

也就是说不同的端，我们可能需要采用不同的解决方案去承接不同的业务。

技术架构

以上是根据当时的业务情况构建的各端技术解决方案，更深入的工程化搭建还需要具体分析业务，但是这里就不进行深入了。每端的解决方案都能单独说很多，这里只是笼统的讲了一下技术架构应该怎么去做，上面每端的方案仅仅是技术方案，不能称为架构。从全局出发才能看到整个团队的技术架构。