杂谈产品灰度上线的研发模式

星期五, 6月 4th, 2010

传统的产品研发模式大致可以分为：产品调研-架构评估-产品启动-需求分析-产品设计-产品开发-产品发布七大阶段。本人在公司经历过大大小小的项目数以百计，发觉这些阶段一直以来都是以一条直线的形式串行着：从产品调研到产品发布，总是一拖到底。这样的做法对于范围比较大，周期比较长的项目，尤其是用户体验类项目而言，存在较大的弊端：我们很可能在没有足够清楚用户需求的情况下，定制了过多的辅助功能，这样即拉长了项目周期，又无谓的投入了过多的人力，在资源如此宝贵的今天，浪费资源实在太过奢侈，我代表春哥鄙视之…

言归正传，切入今天要谈的话题 —-“产品灰度上线的研发模式”。何谓“灰度上线”，简单点理解就是按产品需求优先级，抽出核心需求，在满足用户基本要求的情况下快速上线，并通过限制流量、白名单等机制进行产品试用，以此收集用户的意见，从而萃取出用户潜在的需求，形成后续更有针对性的设计方案。

和传统研发模式相比，这么做唯一的区别就在于将原先一锅粥式的需求和功能点进行了轻重缓急的排序，并以此将项目从原来的单长线作战转化为多迭代短线循环，让产品的生命周期不再昙花一现。

迭代开发

如此一来，需求分析阶段显得尤为关键，我们必须清晰的将需求按优先级归纳分类为几个序列，如：p1,p2,p3…核心功能和必备的体验在p1序列，辅助功能点和辅助型体验列在p2序列，争执不定的需求点可以放在p3序列。需求排序后，我们可以将项目发布点有序的分成（>2期），第一期只确保主要的核心功能和基础体验快速灰度上线，随后通过用户访谈、产品的tracker&session数据、业务数据等手段分析出用户对产品的真实反应，并以此调整二期需求，该加的加，该砍的砍，做到有的放矢。

查看全文 »

Tags：, | 评论[8] | 共有1,154次浏览

再议构建前端UI组件的新思路

星期三, 6月 2nd, 2010

近日，看了玉伯写的《构建前端UI组件的新思路》一文，让我追忆起去年自己分享的一篇P文《随感协同开发的JS设计模式》，有几分共鸣……

话说去年支付宝新版收银台项目中，我就小试了一把这种组件编码模式，点滴心得，这里和大家做一个交流：

回顾一下之前说到的抽象类，对设计模式有所了解的同学可能会觉得有些眼熟，没错，初一看，觉得它很像一个抽象工厂，但是结合下面的基础类来看，你会发觉我并没有在各基础类中，重写getVessel,show,hide等方法，而是直接继承了抽象类中的这些方法。一定会有人不解为什么要这么做，无他，就因为他是JS,而非JAVA。一定的偶合度换来足够的灵活在我看来一点都不过分，更何况这个抽象类是必须确保绝对稳定的，他在成形后不允许被随意修改那是必须的。

  1. AP.widget.basic = new AP.Class({
  2.   setOptions:function(options){
  3.     //接口设置
  4.   },
  5.   initialize:function(targets,options){
  6.     //初始化方法，目的是建立targets子集元素和某方法的关联 
  7.   },
  8.   getVessel:function(target){
  9.     //获取满足target映射关系的容器 
  10.   },
  11.   bindEvents:function(target,vessel){
  12.     //这里绑定target的触发动作
  13.   },
  14.   action:function(){
  15.     //target绑定的事件触发的执行函数，包含你要执行的逻辑 
  16.   },
  17.   show:function(){
  18.     //显示容器 
  19.   },
  20.   hide:function(){
  21.     //隐藏容器 
  22.   },
  23.   setInterface:function(){
  24.     //设置各组件共用接口 
  25.   }
  26. })

查看全文 »

Tags：, , | 评论[9] | 共有1,041次浏览

随感协作开发的JS设计模式

星期五, 1月 1st, 2010

从最原始需求出发，我们必须有一个最简单的实现类，这个类必须是可继承的。方便之后不同的业务需要做不同的扩展。我们必须确保这个类的稳定性。

简单实现类的定义：鼠标点击触发某容器，不带任何辅助效果。我们来想想，这么简单的一个类，需要包含哪些方法，搭个骨架出来：

  1. AP.widget.basic = new AP.Class({
  2.   setOptions:function(options){
  3.     //接口设置
  4.   },
  5.   initialize:function(targets,options){
  6.     //初始化方法，目的是建立targets子集元素和某方法的关联 
  7.   },
  8.   getVessel:function(target){
  9.     //获取满足target映射关系的容器 
  10.   },
  11.   bindEvents:function(target,vessel){
  12.     //这里绑定target的触发动作
  13.   },
  14.   action:function(){
  15.     //target绑定的事件触发的执行函数，包含你要执行的逻辑 
  16.   },
  17.   show:function(){
  18.     //显示容器 
  19.   },
  20.   hide:function(){
  21.     //隐藏容器 
  22.   },
  23. })

这是所有满足本文定义的简单实现类所需的基本方法，我们可以将它作为一个基础方法，方便满足简单类定义的交互形式在此基础上扩展，然后我们开始归纳常用的满足简单类定义的交互形式，如：tab切换，气泡提醒，下拉列表，xbox……

查看全文 »

Tags：, , | 评论[10] | 共有1,663次浏览

小议javascript设计模式

星期四, 10月 8th, 2009

最近重新温习了一次《javascript设计模式》，确实是一本好书，每次看都有不同的领悟，每次领悟到的都受益匪浅，无怪古圣人都说学无止镜了，仅以“加油，好吗？”共勉！

记得早前就说过要和大家分享“javascript设计模式”,迟迟没写不是因为我懒，最近确实太忙，忙工作，忙旅游（啊哦？），好不容易这几天空闲了，接下来是兑现之前空口白话的时间了。

在讨论设计模式之前，请确认您已经有一定的脚本编程基础，如果不甚了解，建议可以先查阅本人很久之前写的这篇《浅谈javascript面向对象编程》。

讲到设计模式，不得不先重点着墨于“接口设计”，因为接口设计在设计模式中的意义太大了，大于模式本身。直观起见，先介绍一下接口定义的形式：

  1. var interface = new Interface("interface",[["getName",1],["getAge",1]]);

可以看出接口函数必须包含两个参数，接口方法定义在一个二维数组中。上例中定义了两个接口方法：getName,getAge,这两个方法都带一个参数，下面我们详细看一下Interface函数的实现代码，从而加深大家对接口的理解。

  1. function Interface(name,methods){
  2.     if(arguments.length !=2){
  3.       console.log("参数必须为二个");
  4.     }
  5.     this.name = name;
  6.     this.methods = [];
  7.     if(methods.length<1){
  8.      console.log("第二个参数不能为空数组");
  9.     }
  10.     for(var i=0;len=methods.length,i<len;i++){
  11.       if(typeof methods[i][0] !== 'string'){
  12.           console.log("第一个参数数据类型必须为字符串");
  13.       }
  14.       if(methods[i][1] && typeof methods[i][1] !== 'number'){
  15.          console.log("第二个参数数据类型必须为整数型");
  16.       }
  17.       if(methods[i].length == 1){
  18.           methods[i][1] = 0;
  19.       }
  20.       this.methods.push(methods[i]);
  21.     }
  22.   }

查看全文 »

Tags：, , , , | 评论[11] | 共有2,057次浏览

前后端分离开发模式初体验

星期一, 6月 15th, 2009

前后端分离的开发模式，原本觉得没什么稀奇的玩艺，在最近参与的一个大型项目中，让我有了更深的理解。

前后端分离的开发模式：系统分析阶段，系分和前端开发人员约定好页面上所需的逻辑变量，进入功能开发阶段，前端开发人员进行前台页面结构，样式，行为层的代码编写，并根据约定好的变量，逻辑规则，完成不同情况展示不同的表现。而后端开发人员，只需要按照约定，赋予这些变量含义，并提供前后端交互所需要的数据即可。

前后端分离开发模式

以前自己在php上玩过mvc开发框架，但是没有在这么大型的项目中实践过，所以过程中暴露出一些问题，也说明现实和理想还是存在一定差距的。

查看全文 »

Tags：, | 评论[7] | 共有793次浏览

小议YSLOW提升网站性能13黄金法则

星期五, 4月 10th, 2009

其实这些黄金法则已经用烂了并且就快被我遗忘了，只是最近要整理前端开发质量的规范，所以就想起了它，正好又想起好久没博了，那就写写吧，希望对还不了解的兄弟们有所帮助！

法则1. Make fewer HTTP requests

这点对于提升前端开发性能的意义是非常大的，早有实践证明，浏览器加载一个页面的DOM结构仅仅只占总加载时间的10%-20%,剩下的时间都在处理页面上组件的下载，组件越多，HTTP的请求数越多，耗时自然就越长。所以我们要做的是尽量少的引用外部静态资源，js、css以及图片。

我们可以通过：图片地图、CSS sprites、合并脚本和样式表等方式来减少HTTP请求以达到提升页面的性能。这里简单提一下图片地图，四年前，他是为我所不耻的，那时候觉得这么做太不专业了，一直到YAHOO推出Yslow告诉我我错了，不相信的朋友，看看下面这个简单的分析：

yslow分析

查看全文 »

Tags：, , , | 评论[4] | 共有1,054次浏览

« Older Entries