叶落为重生每片落下的叶子都是为了下一次的涅槃...^_^

我有迷途,有谁了解

最近由于种种原因,有点心烦,也有点浮躁。

作为互联网开发大军中茫茫小的一员。经常被各种洪流冲击的七零八落。知识永远像个黑洞,任凭你在里面翻山越岭,苦痛挣扎,却也根本只是在他的外围徘徊。学的越多,反而觉得知道的越少。

这是尤为悲剧的地方。以至于到最后,会沦落到一个月总有那么几天,会是那么的心力交瘁。

写代码好玩吗?你会问自己...

【迷途一】 

在我看来,任何一个产品,都是有生命的。有人说产品经理是它的爸妈,可是这么一说把奋战在一线,日以继夜为了产出一个优秀的宝宝的开发人员放什么地方?保姆吗?抑或借腹生子的女人...
当然这么说或许有点夸张,可是我必须得说的是,无可置否,产品经理的确很重要,没有一个优秀的PD,也必将不会有一个好的产品。但PD只能算做一个产品的爸爸,就像一个男人在心血来潮时肆意挥洒的一个idea,就得要孩子的妈怀胎十月,历经千辛万苦才能产出一个好的产品。 我把所有开发的同学(包括UED)都比做孩子的妈,可能很多同学会觉得很不舒服,不过要记住的一点是。母爱永远是最伟大的。
怀胎十月把孩子产出的是谁,是孩子他妈,一把屎一把尿把孩子养大,培养成熟的人是谁,还是孩子他妈。自古以来,这种爱就是值得敬仰的。

【迷途二】

有多少人愿意把每个产品都当做自己孩子一样来悉心照料,从孕育的阶段就投入百分百的精力?
我还记得我大学毕业的时候,那时候带我毕设的老师问了我一个问题:你觉得苹果能赢得这么多用户拥护的最大的原因是什么?
那时候我肆意天真,直觉的答道:因为他们把用户体验放在第一位,用户用起来觉得爽!当下看来如此粗糙的答案显得有些单薄,可是我依旧坚持用户体验的重要性。互联网的团队里为什么会发展出一个叫做User Experience Design的相对独立的团队。我想这是需要我们去深思的一个问题。
我们做产品的,都是产品的爹,产品的妈。不管你的小孩是不是在出世前就备受关注,抑或只是一个普通家庭的微小的一员。孕育出这个产品的辛苦,永远只有它的爸妈才知道。世上哪一个孩子的爹妈不爱自己的孩子。如果 连这一点爱都舍不得给予,那根本不算合格的父母!!

【迷途三】

“磨刀不误砍柴工”,这个道理谁都懂。可是 真正遇到实际情况的时候,能想到这个道理的人不多。我想做开发的同学,很少有人能保证一次性洋洋洒洒就能写出通用性,复用性,易用性都完美的代码。就算是一等一的大牛,我想也有点强人所难。而且随着业务的变更,代码是必定需要定期重构的。可是很少有人愿意花精力去做这个重构的事情。比如要修改什么功能,可能就直接与业务写个高耦合的函数,直接把之前的要修改的地方覆盖掉了。最后的结果是,项目组里每个人都这么做,每个人都不断地向最初的净地里添自己的代码。最初的代码块就像一个公共厕所一样,每个人都自顾自的在里面拉屎,而没有人去维护清理打扫。不臭才怪了。
做过代码重构的同学应该清除的知道,要重构出一套高内聚,低耦合的优雅代码。所花的时间绝对不比开发实际功能所用的时间少。这是一个大工程,而且是值得歌功颂德的大工程。可是往往做开发的人花了一个小时写好了一个高耦合的功能,人人都会说他效率高,很风光。你花了三个小时把它重构成一个高内聚,具有较强可复用性的模块,面对的却是处处暗淡,效率低下的不屑眼光。当然,我所说的情况可能有点极端,不管这种类似的情况是一定存在的。
代码的前期设计和后期重构都像是磨刀,刀磨得越快,后面的砍柴功夫将会越小。虽然前期磨刀的过程很辛苦,甚至有点难堪。但是只要你的刀够锋利,并且能经常的磨它,让它一直保持在一个锋利的状态,一段时间之后,你会发现,你的产品会是那么的轻量级,砍柴会是那么的轻松。
我一直都强调,能写出代码从来不值得骄傲和称赞,这是一个以此为职业的人最基本的职能,就像一个学生能写出500字的作文一样。但是能写出好的,优雅的代码,才是真正值得追求的的地方。就好比一个满誉的作家一样,写出来的文章永远那么优美,总会有市场。
想重构好代码,通常要做几件事:
1.抓出功能的核心和边界。
从功能流程走,抓出每一个功能步子的边界,把边界尽可能的隔离开,以功能的颗粒化为代价换来获得高复用性的模块。

2.提供良好的扩展接口,尽可能的保证模块核心core的无污染,让新增的需求功能有拉屎的地儿。
3.重构不能一劳永逸,刀始终都是要经常磨才会快。低耦合,高内聚是提高可重用性的一种方式。但是聚合也是各有优缺点。高内聚的模块之间的结合会是一个需要慎重考虑的地方。 

 【迷途四】

 作为一名平凡的前端编码者,使用着javascript这种被很多程序员挤在边缘的语言。我通常不敢称自己为程序员,这样的称谓往往会给自己压力。我们做的只能是模仿,模仿传统经典面向对象的设计模式。人人都在说OO好,的确,OO作为模块化的的基本的思想,有着它不可替代的优势,这也是为什么这种代码设计模式会流行起来并经久不衰的原因。作为一个弱类型的语言,面对着以对象作为第一型的面向对象的设计模式。很多人为研究怎么让js良好的表现继承,多态,良好的类结构而努力。
正因为js的这种特殊性,让它的编码显得更为自由,如果非要用一套桎梏去限制它,可能反而抹杀了它其他方面的优秀特性。

var bind = function (func, obj) {
    
var args = Array.prototype.slice.call(arguments, 2);
    
return function() {
      
return func.apply(obj || {}, args.concat(Array.prototype.slice.call(arguments)));
    };
  }

 

我们可以尝试着以下的test:

var f = function (i) { return i + ' am ' + this.name }, person = {name: '岑安'};
(f 
= bind(f, person, 'I'))()

// output: I am 岑安 

这是一种很常见的事件绑定的思路,相信很多同学都已经见怪不怪了,函数可以作为一个方法绑定到指定Object上,使其表达更有语义。那么接下来:
  var slice = Array.prototype.slice, 
  compose 
= function() {
    
var funcs = slice.call(arguments);
    
return function() {
      
var args = slice.call(arguments);
      
for (var i=funcs.length-1; i >= 0; i--) {
        args 
= [funcs[i].apply(this, args)];
      }
      
return args[0];
    };
  };
var sayHi    = function(name){ return 'hi, ' + name; };
var sayLove  = function(name){ return 'I love '+ name; };
var sayTo = compose(sayHi, sayLove);
sayTo(
'岑安'); //hi, I love 岑安

这个简单的测试变得好玩起来,函数被有机的组合起来,成了一个新的函数,有了新的功能。
这就意味着,如果遵从这个思路一直下去的话,那么,我们可以通过一定形式的基元,组合出不同功能的方法。这有点类似于css中的分离。当分离到极致的时候,任何页面的css文件都可以共用,因为你的css样式表中,一个类就一个属性,在html代码里通过样式类的组合达到想要的样式。(但是事情一般做到极化了,也就离愚蠢不远了)

所以,上面是js以函数式的设计模式编写代码的最简单的例子,通过函数来组合函数,以函数为第一型来编写代码,更加的抽象,也能使代码更加的向内聚合。但是,请记住,当你把模块拆的七零八落的时候,你会发现,任何的拼凑都已经无济于事了....物极必反。牢记

 很多人喜欢用jquery,看看它的设计思路,你会发现,适当的进行函数式的设计,真的很有用!

至于curry和methodize以及类似的函数包装和组合器,或许尝试一下,会爱上它。

本文写得有点乱,有点小牢骚,请各位见谅!! 

posted on 2011-03-09 20:42  岑安  阅读(3964)  评论(32编辑  收藏  举报

导航