看过w3ctech 2011 - javascript专题会议-hax演讲后感

突然觉得名字很长啊，呵呵，下午花了点时间看了一下hax的关于api设计的演讲。

有点感触，有点收获，简单记录。

 

当然作为自己研究这个系列的开篇，还是记录一下一些基本的知识。

 

下面部分内容来源于http://www.iteye.com/news/21786 （如何做到api兼容） ---只是选择性地引用

 

 

1. 什么是javascript的api

• 函数、类接口包括参数，返回值，函数对dom的具体操作
• 网络接口协议，如json、xml数据格式
• 样式
• 浏览器的特性依赖
• 内部实现的泄露
• api长期的兼容和稳定性

 

     2. 关于hax提出的无绪

  先表达一下 自己的观点：类似于针对使用者的 透明，对于一般的使用者，他们不需要了解太多 细节（类似于具体使用原生的某一个内置的对象，某一个内置对象的api，或者你基于什么框架封装），他们关注的更多的是我调用这个api 返回什么，能不能达到我的 需求。

   下面是原版的 选择性无绪的定义：

• 编程不是火箭科技，程序员不是科学家
• 软件工程中的无绪是指：程序员无需深入了解很多内容，也可以写出好的代码
• 找到一种编程实践方法，让开发人员不用深入了解所有事情，即选择他们所需的知识
• API是对所需知识的抽象，它将系统的复杂性隐藏起来

 

    3. 那么同样大家很关心的也就是API什么样子才是好的?

   还是简单地说下结合自己以前设计api的经验说下：

      

（1） 功能上能满足使用者的需求

    

    a.能默认实现的多绑定操作，比如表格的增删改按钮；

    b.如果有复杂的逻辑业务的就提供对应api( 工具类或者 数据抓取)支持小操作，

    

 例如：

      多选情况下使用者想实现批量删除的操作，那么我们就给它getSelections类似的api进行获取多行的数据，并且设置成多种数据格式（如果有需要的话，一般还是建议json这样的数据格式传给后台处理，但是以前确实接触过 flex打印平台在打印功能上用户确实需要多种数据格式的情况）

   贴出hax的API好坏的标准：

• 可理解性
• 一致性
• 可见性
• 简单性
• 兼容性

   这个我觉得排序下来应该是兼容性第一，一致性第二，可理解性第三。当然简单性我一直觉得这个度很难把握。如果可以的话，还可以加上“ 可预见性”（其实就是前瞻性，俗话就是 永远站在用户的前面）

 

  正好hax也把Jquery的好坏说明了

• 可理解性：Selector
• 一致性：链式调用
• 可见性： $
• 简单性： write less,do more
• 兼容性： 跨浏览器，跨平台

   4. 关于hax说的Object.prototype

其实如果你看过prototype.js或者tangram等，多会有类似于prototype上面的扩展，当然我个人觉得可能hax的意见也是主要在与es5或者将来的es6加入了部分类似replace,这些未定的扩展后你设计的api有没有冲突，这也是 未雨绸缪吧。

---------俗话就是当我们没有标准的时候我们可以自己创建，当有了标准的时候，我们要遵循标准。

  贴出ppt的部分内容：

• prototype的修改是全局性的，和global变量一样，甚至更糟糕
• es5加入了一些方法：用Object.xxx而不是Object.prototype.xxx
• 修改其他Array啊或者String在这些内置对象的prototype如何
• 与未来API的冲突
• 解决之道

  正如hax说的，研究jQ到现在，我也一直认为JQ在这个处理上很明智，很NX。

   5. 关于短命名的思考

• 正如hax所说的，prototype虽然有一些问题，但是作为首个提出短命名的开源框架来讲，是值得肯定的，但是我们最后选择记住的可能也就是$,$$这两个，不过个人觉得，不管怎样，记住了一部分也是成功的。
• 命名不光时js-api一直存在的话题，还有css命名的话题，当然作为自己前段设计自己的库的命名空间来讲，我个人选择了凤凰（phoenix），因为可能只是简单地学习和积累地去写这个库，就选了个人喜欢的。关于api操作的话还是觉得用英文单词比较好，让人明白是什么意思。（可理解性也就是这样体现的，如果用户找一个api找了半天，发现名字原来是自己从来没想到的，那一定骂街）

  6. 关于占位符

    

      其实我也很坚定地赞成不用“_”或者“undefied”这样的东西去替代，原因很简单---有问题。（问题的原因hax多说了就不多说了）

  7. 关于惰性函数模式

      我看了整个3节视频，觉得这个话题 更有价值。

      个人就不写评论了，自己看视频吧，很赞

      

 8. 具体实现对API的影响

     其实做过库设计的人（无论大小）， 个人以前的经历是：

•   很多中级领导的要求是没什么问题如果实在是有需求或者功能问题就不要升级（保守主义）
•   但是作为开发人员的我们可能在某个api的实现我们一定会改进，因为人是进步的嘛，代码是越写越好的
•   还是就自己会不断地重构以前写的代码和算法，至少我是这样的一个人。
•   新增和学习别人的功能，不仅仅是模仿。

哇，写了那么多，打字多打累了。呵呵 ，估计读的人更累，至少简单交流记录学习。

最后先送上hax的 总结：

•    API的目的是让开发者可以选择性无绪
•    评价API的好坏就是从“选择性无绪”出发，以此衍生出可理解性、一致性、可见性、简单性、兼容性
•    即使是看似主观的风格问题，也是可能按照标准结合情景进行分析的
•    注意JavaScript的一些特点导致的特殊问题。

最后自己说说自己小小的观点：

•  API设计如同前端这个大环境一样是一种沉淀，即使是一个公司级的库也是一样，详细的代码注释和模块的拆分事先得设计好，就像以前光荣大哥给我们组分享的小型讲座里面说的，设计在整个api编写过程中的时间占比是最多的。预先良好的设计会给你后期的编码理清了思路，而且可以说在设计的过程中其实你已经开始编码了。因为你不断地尝试才值得哪种算法最好。
• 站在用户的前面---这个话题一直很沉重，因为不一样的业务，不一样的逻辑。所以要预留多个接口，方便后期的扩展。
• 路很长，这篇只是开始，坚持去研究，去实践。

 

最后贴上视频地址http://v.youku.com/v_playlist/f15769239o1p11.html  （最后感谢hax）