实例分析京东详情页前端开发

　　简介
　　详情页也叫做单品页，域名以「item.jd.com/skuid.html」为格式的页面。是负责展示京东商品SKU的落地页面。主要任务是展示商品相关信息，如价格、促销、库存、推荐，从而引导用户进入购买流程。同时单品页有很多版本。一般分为两类。一类我们通常看到的「通用类目详情页」——所有类目都可以使用，一类是不经常看到的「垂直属性详情页」——一些有特殊属性的商品集合
　　
　　首先，由于详情页量大（SKU数十亿）、高并发（日PV数十亿）等特性，在很长的一段时间里，单品页都是后端程序生成静态页面使用CDN来解决量大、高并发的问题。
　　其次。单品页涉及的「三方」系统特别多，比如促销、库存、合约、秒杀、预售、推荐、IM、店铺、评价社区等。而单品页的主要任务就是展示这些系统的信息，并且适当的处理他们之间的逻辑关系，而这些系统的接口一般都使用异步Ajax来完成，因为其一CDN无法做到页面的动态化，其二一些系统的信息对实时性要求特别高（价格、秒杀），即使使用后端动态渲染也很难做到无缓存零延迟。
　　基于上面两个原因，注定了单品页是一种重多系统业务逻辑展示型页面，重前端页面。我大概汇总了一下页面上异步接口，总共约有30个，页首屏的接口特别重要，接口之间几乎都有耦合关系：
　　
　　前端的发展历程
　　混沌时期
　　混沌时期的单品页并没有前端开发的概念。核心的功能脚本只有三个：促销价格（promotion.js）、库存地区（iplocation.js）、其它逻辑（pshow.js）。这三个脚本分别是三个不同团队的同事负责维护，当时我刚进入京东的时候在UED部门，负责页面脚本整体的维护工作和pshow的开发。那时候我自己维护的pshow.js脚本压缩后只有80kb，所有的代码都是过程式的，没有任何使用模式和代码技巧，JS最多也只被用来做个判断渲染DOM。那时候的前端工作内容只在UI层面，写样式和一些交互脚本。
　　这个阶段给我最深刻的感觉是单品页后端模板很少维护（后端架构是最老的aspx版本）。大多数的改动都要用Java去动态渲染。因为后端页面是一个生成器生成的。如果页面后端模板有改动那么就需要全量的生成一次，过程可能需要几个小时。
　　初见端倪
　　当我接手这个项目时刚好有一次大改版，就在这时候老大说页面上的脚本都要放在我们手里维护。然后就是一大波的重构、重写。基本上pshow被重写了大概80%其它的因为业务逻辑的问题并没有完全重写，只是做了些代码层面的优化。
　　有一个模板引擎叫trimPath，知道这个的估计都算老前端了。最早的客户端Java MVC模式代表作品，只到现在还在使用。这个阶段像评价这种完全异步加载的模块特别适合使用模板引擎来减少维护的工作量。这个时候虽然页面上的代码并不都是我们写的，但基本上前端对页面的Java有了控制权，接下来的事情就是寻找机会逐个优化。
　　这段时间是最痛苦的时候，维护的工作统一到前端。然后后端几乎没有变化，只是在一段时间将后台的架构从aspx过渡到了java。本质上并没有什么改变。前端却做了比以前更多的事情，也是在这个时候我接手了大量的维护工作（包含全站公共库的维护）使得我意识到了一些自动化、工程化方面的重要性，后文会主要讲解，顺便说下，那时候前端自动化工具Grunt刚面世，但是我自己却用的是apache ant，不过不久就切换到了Grunt来构建项目。
　　拨云见日
　　单品页不仅重系统逻辑，也重维护。在这段时间里一方面有正常的维护类需求要做，一方面自己也不断的学习新知识为以后的改版做铺垫。不过就在这时单品页有历史意义的一次技改出现了——单品页动态化技改。关于后端部分的改造细节可以去亿级商品详情页架构演进技术解密了解。
　　总的来说这次的改版后很多数据直接从后端读取，不再从前端异步获取而且我们也做过一些异步加载的优化，多接口combo从统一服务吐出给前端使用。这时前端就不用再为异步接口的加载时苦脑了，只需要专注系统接口的逻辑。
　　随着这次技改，前端的代码也迎来了模块化的时代。我们把所有的前端代码都进行了模块化然后基于SeaJS重写，配合Nginx concat功能实现了本地模块化开发，线上服务端合并。