我有迷途，有谁了解

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

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

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

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

【迷途一】 

在我看来，任何一个产品，都是有生命的。有人说产品经理是它的爸妈，可是这么一说把奋战在一线，日以继夜为了产出一个优秀的宝宝的开发人员放什么地方？保姆吗？抑或借腹生子的女人...
当然这么说或许有点 夸张，可是我必须得说的是，无可置否，产品经理的确很重要，没有一个优秀的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以及类似的函数包装和组合器，或许尝试一下，会爱上它。