Skip to content
lifesinger edited this page May 1, 2012 · 6 revisions

我们倡导:设计与文档先行,编码与反馈并进。


要开发一个组件时,我们推荐采用下面的流程:

(假设我们要开发的组件是 xxx)

一、做竞争对手分析

先按照 文件命名与目录结构 中的组件目录规范,在 arale/lib 目录下,创建 xxx 目录,并按需创建好 src, tests 等目录,以及 README.md 等文件。

然后创建 xxx/docs/competitors.md 文件,在这里开始记录 xxx 组件的竞争对手分析吧。

参考范例:Base 模块之竞争对手分析

当然,没必要像 Base 模块一样写这么多。只要能把同类产品的优缺点分析清楚就好。

如果在竞争对手分析时,发现了一个质量优秀、社区反馈良好的同类产品,并且非常符合我们的需求,那么太好了,恭喜你,直接拿过来用就好(不知道怎么拿没关系,告诉下那个叫 @玉伯也叫射雕 的人就行)。

二、想清楚使用场景,开始设计 API

通过竞争对手分析后,你会对 xxx 组件的使用场景有更深刻的认识了。这时你必须得想清楚:

  1. 我们要实现的 xxx 组件,究竟在什么场景下使用?
  2. 想做通吃的?大而全的?一旦有这个念头时,请先去小卖铺买冰棒吃(没带零钱时,可以继续找那个名叫 @玉伯也叫射雕 的人)。

可以在纸上画画。若想清楚了,也别犹豫,开始编写 xxx/README.md 吧,想想要给最终用户提供怎样的 API. 这里有纠结、也有喜悦,经常要花费很长时间,但很值得。

在这过程中,有困惑犹豫、难以抉择时,记得多找人交流,利用团队和社区的力量来协同完成。

参考范例:Base 使用文档

三、设计与文档评审

完成第二步后,请务必迫不及待地将你的工作成果通过邮件分享出来:

若没加入的话,强烈建议先加入该群组:https://groups.google.com/forum/#!forum/aralejs

如无特殊原因(比如发生海啸、地震了),通过上面的方式告知社区后,大家会去阅读你的 xxx/README.md, 并开始直接拍砖或送鲜花。

等 @玉伯也叫射雕 等人也赞同了你的 API 设计后,这一步就算通过了。

四、编码、单元测试、以及 examples

第四阶段有可能会是最快乐的运键如飞,也有可能是最痛苦的上下求索。

编码时,记得遵循我们统一的规范:请阅读 Wiki 首页 Home 里列举的开发规范部分。变量命名有纠结时,也拿出来讨论,统一后记录到 常用词命名统一表

单元测试请参考 lib/base/tests, 记得在 xxx/package.json 文件里,写上 tests 字段,这样 tests/runner.html 就能自动加载你的 spec 文件了。

examples 请阅读:examples 规范

编码、单元测试 和 examples, 顺序无所谓,按照你自己最享受的方式开发就好。但是要进入下一步之前,一定要把这三个都完成。

注意:在编写代码时,很可能会发现之前的 API 设计有问题,需要调整。这没有任何问题,调整就好。如果调整比较大,记得邮件告知大家。

五、代码评审

第四步完成后,请务必继续迫不及待的邮件告知大家。这样,我们就可以对你的代码进行评审了。

评审的方式,会通过 Issue 来管理。怎么方便怎么来。

如果评审不通过,则回到前面的步骤,继续轮回。

六、精益求精

如果能到这一步,我相信你对 xxx 组件如果不是充满热,就是充满爱了。

百尺竿头更进一步吧,自己再仔细阅读下 README.md 等文档,以及源码,精益求精,受益无穷。

七、发布

通过邮件、博客、微博等方式,向全世界告知你的工作成果。我相信,只要是用心了的,就一定会有人感谢,会有人欣赏。