Legos-React

上周《永不止步的前端》分享之后，从同学们的反馈来看，普遍都觉得react很酷，很值得尝试，但是webpack+gulp的方案有点重，有点颠覆现在的开发模式，所以贴心的罗德大神连夜折腾了一个legos4+reactjs的方案，目前已经在开发环境搭建完毕，亲测体验很ok，现在把使用文档丢出来：

legos增加react模块

已经在公共模块增加react模块如下图：

我写的demo业务模块如下图：

调用react模块代码如下（跟其他公共模块没什么两样^_^）：

define('test.react', function(require, exports, module){
    var _cacheThisModule_;
    var React = require('react');
    var $ = require('zepto');

    exports.init = function() {
        /**
         * Created by lordchen on 15/5/18.
         */

        var Timer = React.createClass({displayName: "Timer",
            getInitialState: function() {
                return {secondsElapsed: 0};
            },
            tick: function() {
                this.setState({secondsElapsed: this.state.secondsElapsed + 1});
            },
            componentDidMount: function() {
                this.interval = setInterval(this.tick, 1000);
            },
            componentWillUnmount: function() {
                clearInterval(this.interval);
            },
            render: function() {
                return (
                    React.createElement("div", null, "Seconds Elapsed very fast: ", this.state.secondsElapsed)
                    );
            }
        });

        React.render(React.createElement(Timer, null), document.body);

    }
});

恭喜大家，基于legos的一个酷酷的计时器react应用已经开发完成了

但是了解react的人应该都知道上面这种不是基于JSX的代码写起来太low了，而且html标签的优势也都消失殆尽了，需要把jsx模板转换的工具也集成进来，操作步骤如下：

1. 在static/js 目录下新建目录jsx
2. 下载安装nodejs
3. 安装react-tools

npm install -g react-tools

1. 设置jsx自动编译(记得关注文件路径，要先进入你本机代码所在目录)

jsx -w ./jsx ./module

看到上面的截图，表示jsx已经在watch./jsx 目录下地文件修改，并且实时在module目录下生成一个同名的编译后的js文件，接下来应该怎么做，相信大家都懂了。

不要犹豫了，赶紧尝试一下，有任何问题请随时咨询罗德大神，妹子优先~~

hello:

this is a test

This text will be italic
This will also be italic

This text will be bold
This will also be bold

_You _can* combine them*

• Item 1
• Item 2
  • Item 2a
  • Item 2b

Format:

http://github.com - automatic!
GitHub

legos 常见使用误区和一些小技巧

1. 在开发模式下转测或者发布*

2. 更新了模块，但是没有更新入口*

3. 没有使用combo 和local cache的功能*

我的建议 大的稳定的类库比如 jquery、zepto、react等都不要combo并且存到localstore里; cookie、url、validate等小的基础模块combo到业务模块里

4. 转测或者发布的版本没有压缩*

5.调试的时候在url后面加上mdebug=1,就可以进入调试模式*

美的三年

时光飞逝，日月如梭，来美的电商已经快三年的时光，三年仿佛一眨眼，又仿佛经历了沧海桑田。
前端团队从3个人发展到了20+，公司gmv从1千万到了10几e，000333也从16来到了34(还有一次除权)，最关键的是我已经从老司机变成了老腊肉，于是不由自主地开始感怀身世，总结过往，所以写下此文，既是对这几年工作的一个总结，也算是一个前端团队和前端leader成长经历的分享。

背景

那是2014年，我被从腾讯被卖到了京东，我们的小team刚刚做完微信购物入口的第一个正式版本，我拿到了天猫前端的p7offer，然后我最终选择了来到美的电商。

当时的故事是这样的，

原来的老领导a：一起去美的吧，我觉得不错，你负责前端，m哥（也就是我们的老大）觉得前端很重要

我：靠谱吗，在深圳吗

a: 我觉得靠谱，在

我：让我考虑一下...

初见

然后14年8月10号我就入职了，跟我一起去的还有腾讯的老同事，L哥和J哥（两个让我很幸福的男人）。说实话入职的第一天我们内心是崩溃的，空空的，矮矮的，暗暗的办公室，A哥亲自在弄网络，搭服务器，会有老鼠突然爬到裤管里，每天早上第一件事是把桌子上的老鼠尿擦掉...

当然作为富二代的我们很快搬到了现在高大上的办公室，我们后来也调侃过那些因为办公环境拒绝加入我们的同学，后来我们回头想想其实那半年的时光其实简单又快乐，自由而又有成就，但却也是第一次稍微地感受到了一个企业初创时期的艰难以及能够患难与共的可贵。

筑基

基础能力的搭建，是腾飞的前提，是我们做的第一件事，同时也是我一直坚持投入的事情，基础能力既包括团队的组建，也包括技术框架和工具的开发，而且两者是相辅相成的，因为优秀的开发者一定是对技术和业务有追求的人，对团队的逼格有要求的人，当时我们主要做了下面这些工作：

1. 基于前端模块化的开发和集成工具legos4（基础版本来自腾讯高Tkp哥的团队）
2. 集成了sass和sinclude的csscombo体系
3. 在PHPCI框架的基础上二次开发，实现了跟后台c++的分布式调用框架，实现了多个web项目共享model和lib，helper等
4. 开发了一套发布系统（撸主任命名为芭蕉扇），实现脚本文件（php）和静态资源的可视化选择、发布、文件比较、回退，发布记录等（据我所知很多中小型都没有做这个工作，在转测和发布上都做得比较粗放，我觉得是不可取的）
5. IDC机器分set管理，静态资源cdn化，以及后面做的全站https等
6. php日志查询工具（日志记录，查询，筛选等）

以上就是我们在初期做的基础工作，也因为做了这些基础建设，我们才开始成为一个合格的前端的团队：

1. 有稳定可靠的js、css、cgi开发框架和规范，可以快速稳定的支持业务需求
2. 业务开发可以心无旁骛，公共问题有人处理，团队积累有机制保证
3. 从业务上线的第一天起问题就是可跟踪的，用户问题可以得到快速响应的
4. 新加入的同学觉得我们是靠谱的，专业的前端团队

招兵买马

人员招聘和培养，这也是一个重要而有意思的阶段，当时我们的团队在不到一年的时间快速扩大到了接近30人，
当时自己也膨胀得厉害，觉得自己兵强马壮，大业可期，什么都想做，什么都觉得能做，现在想来这种暴发户心态很幼稚，其实这个过程中，团队的效率和战斗力是有所下降的，对一部分同学的关注和培养也不够。还是要有合理的团队梯度，合理的产品和运营驱动，才能达到最优的状态。

这里也分享一下我搭建团队的思路，基本思路是筑巢引凤，开枝散叶，先搭建好业界比较先进的开发框架和模式，然后落实骨干人员（最好有1，2个前端网红），围绕框架和骨干招聘新同学，对于工作1，2年或者毕业生就降低技术上的要求，把重心放到工作态度，学习能力以及对技术的进取心上，目前团队很多小鲜肉都已经成长为了业务的中流砥柱，都是自己培养的（因为现成的好前端真的不是那么好找），这样在money比较有限，hc相对较多，业务压力也比较大的情况下就能比较快速的搭建一个有战斗力的团队，骨干比较care待遇，公司的成长，性价比；小鲜肉比较care个人的成长，团队的氛围；大家各取所需，其乐融融，就是一个比较健康的模式。

最后再说一下导师制和mini项目，这也是我们一直坚持的，每一个新入职的员工都有一个热情靠谱的导师，可以大大减少新员工的孤独感和流失率，可以大大加快新员工的融入和成长，还有一点其实在当导师的过程中，有天赋的同学自己也可以得到很大的成长，包括技术和管理上的，包括自信等，所以强烈推荐大家都建立并且严格执行导师负责制；还有mini项目也是从腾讯引入的，让新来的前后端同学一起做一个完整的有实际价值的小项目，通过实战学习基本技能和研发流程，加强团队协作和实际动手的能力，并且让新同学有了一个温暖上进的小圈子：）。

流量

这也是一个有故事的话题，当时天猫前端的老大也很意外我会选择去美的，他说得很直接，去美的做电商你们的流量从哪来？其实当时我无比认同他，我们的流量从哪来？其实现在这还是一个困扰我们的问题，流量从哪来？

答案也还是有的，流量从微信来，从百度来，从公司内部来，从app来，但怎么来，怎么不那么贵的来，这个过程就无比艰辛，无比煎熬而且不一定能复制了（友情提示，主要功劳来自运营的mmgg们，本人仅从开发角度分享一下浅见）

重点介绍一下微信的流量，基于美的品牌的美誉度，美的海量的产品，售后，我们做了美的会员、美的商城的服务号，把用户沉淀到服务号，让用户通过服务号享受报装报修、抽奖、新品试用、优惠券，积分等会员待遇。在一年多的时间内，服务号关注从10w增加到了700w。其中几个小点是我认为效果相对较好的：

1. 现金抽奖大转盘（我们应该是最早做的），目前总的数据是接近2kw的抽奖次数，接近300w的uv
2. 新品试用（申请->免费送->写评测），每期的申请数应该都是5000+，为官网积累了很多优秀的测评
3. 家电砍价，日uv峰值20w+
4. 集卡牌送家电,日pv峰值接近百万
5. 服务号管理和数据后台，这里主要提供多样的配置和数据统计（比如通过导购和师傅带来的关注统计，发放奖励），丰富的服务号玩法等

总的经验就是，服务号在初期还是不要玩小清新，酷炫也不是最主要的，还是真金白银的福利效果好，用户爱传播。其他还有内购，亲友码，接各种靠谱cps，百度保护费等，其实都是有效果的，我们现在也都在做，但在初创阶段，如果有品牌，有内容，我还是强烈建议运营好服务号，可以获取到一批相对忠诚而且性价比高的流量。

技术升级->next

时间来到了2016，前端在node生态的助推下，有了爆发性的增长，我们身处其中，就有一种一觉醒来，穿越了的感觉，曾经引以为豪的legos似乎有点跟不上时代了，seajs, requirejs, grunt, backbone, agular一下子都out了，这个世界突然成了webpack，vue的天下。所以，虽然很不舍陪伴我们2年多的legos，我们还是半被迫地升级了我们的整个前端开发框架，命名为next，在我的git上有开源一个基础版next，欢迎有兴趣的同学star&fork。

next主要构成如下：

1. 基于gulp和webpack完成了模块化构建的配置，支持vue，react等mvvm；支持sass,less；支持外部引用全局lib（移动端zepto，pc端jquery），支持混淆；支持代码检查；支持开发模式和发布模式；也支持本地和服务端打包等，以上都是wp的基本功能，通过配置文件的定制完成
2. 结合我们本来的开发模式，自动上传开发环境，自动生成和上传sinclude文件
3. 结合我们的发布系统，实现自动新建发布单，自动生成项目脚手架等

通过这次升级，我们的js，css，mvvm甚至后面的小程序全部都统一到了一个框架和体系里，并且通过ssi（server side include），和我们的php无缝整合，组内的同学几乎都毫无违和感地切换到了新框架，业务上也没有任何影响，旧的模块，旧的业务代码都可以直接使用，开发效率有了小幅度的提升，最重要的是我们更好地融入了npm生态，可以更快地跟上社区的节奏，同时也可以给社区做一些小小的贡献，团队有了更广阔的空间和更多的可能性。

其他在技术上我们还做了以下尝试（大部分都来自我们的工具小王子奇哥）：

1. mos(midea operation sys)美的电商运营平台-主要频道和全站运营位包括app，小程序的运营都通过这个平台完成
2. 卖场工具 - 日常卖场全部都由运营自己完成（主要widget有各种商品单元、秒杀、预售、领券模块等），一般2小时一个卖场
3. 服务号第三方平台美极客，因为后期我们需要支持多个服务号的运营，所以通过这个第三方平台的方式来完成各个服务号的用户授权、菜单、自动回复、用户分组、数据统计等。根据我们的经验，通过这样的方式，运营活动的迁移和复用成本会大大降低
4. 基于phantomjs和阿里码栈的自动化测试和运营工具（用来爬数据以及帮助运营做重复的表单提交工具，谁用谁知道）
5. 天猫旗舰店的设计套版工具等（主要功能是用excel的商品数据套版批量生成商品主图和聚划算图片），保守估计可节省40%的设计人力
   ...

类似的事情还有很多，其中既有mos，卖场工具这种我们驾轻就熟，非做不可的工具，也有套版工具、码栈这些原来我们怎么都想不到的但是其实运营很需要的场景，所以资深的开发要有开放和务实的心态，要更多地跳出技术本身看问题，这样才能用自己的技术去更好地解决实际问题，一点点地创造价值。

我们的产品

吹了半天的牛，大家是不是已经有点想打我...最后还是要交上我们的答卷，也做个小广告：）

• 买家电，来美的，正品保证，全场包邮，来 美的商城

  

• 学烘焙，来kaoker,一起烘焙好时光

  

• 最全最美会员权益，尽在美的会员，小美在等你哦
  

• 首款图文语音直播小程序美课美聊

  

• 美的分销员，欢迎成为万元户

  

javascript的健壮性

今天常规访问我司首页的时候，突然发现商品价格拉不出来了，打开控制台一看，错误提示如下：
check了一下发现是取类目数据的接口没有走https请求，导致SearchNavData没有取到，整个页面的js挂掉，
出问题的代码如下：

if(SearchNavData && SearchNavData.length > 0){
            var SearchNavDataLength = SearchNavData.length;
            ...

修复了这个bug之后，越想越觉得这个问题不能小瞧，而且这个问题还有一定的普遍性（近期已经发现了2次，而且都导致重要功能出问题），所以写一篇小文章来探讨一下写js代码时候应该考虑的健壮性。

首先要说的是通过数据接口往页面注入变量已经是比较通用的做法（比如上文中提到的类目数据就是后台直接推送更新为js文件），但是这个做法有一个很明显的副作用就是接口有异常的时候会直接导致变量undefined，如果我们像普通程序员那样写上面那样的代码，页面就挂了，那么文艺的程序员会怎么写呢？

方法1：

先判断，如果undefined就return掉

if (typeof(SearchNavData) == "undefined") {
    return false
}else{
    ...
}

方法2：

try catch

      try{
            if(SearchNavData){
                ...
            }
        }

        catch (e)
        {
            alert(e.description);
        }

方法3：

不要直接用注入的变量，在程序内定义一个新的变量

//这里的{}也可以改成一套比较固定的类目数据，会更友好
var SearchNavData = window.SearchNavData || {};
...

以上三种方法，大家可以根据需要选用，强烈建议和要求大家不要再裸用不在控制范围内的变量，
我个人比较推荐方法3。：）

ok，that's all。 希望对大家有帮助，这个问题其实还可以延伸：比如对象key值不一定存在，数据长度可变、值类型不一定可控的情况下，怎么写出健壮的js代码呢，后面有需要我们再探讨。