Beetl开源那些事2

原创
2015/11/16 16:03
阅读数 1.1W

 

  Beetl开源已经有快5年了,对于一个国内的开源软件,能做5年,从默默无名到逐渐国内外认可,非常不容易。跟去年的博文“beetl开源那些事”一样,我在这里还是想分享一下开源心得,为那些有志从事开源工作的人提供一些借鉴。

  说beetl 在持续维护中,可能很多人都看不出来,拿一个语言里最常用的debug函数来解释,就可以看到beetl一直在维护中。
  第一版:debug(a), 跟其他语言一样,没什么特别的,输出a到控制台而已。                 
//debug(a),如果a=123,输出
123

  第二版 : debug 允许接受多个参数,如debug(a,b),这个跟其他语言一样,稍微有点变化               

123,456

  第三版: debug还需要额外打印出所在文件以及debug所在行数,这样查看后台日子就方便了             

//如果a=123,则debug(a) 输出是:
123 @ xxx.btl 里 ,第5行。

  第四版: debug(a,b.name),输出的时候,还输出了变量名,如:          

a=123,b.name=xiandafu @xxx.btl ,第5行

  第5版: 对于字符串,会额外输出引号,比如a=123,b="123"; 则debug(a,b) 输出             

a=123,b="123" @xxx.btl ,第5行

  到目前为止,一个简单debug函数已经变得非常实用,但是改进并非很容易,第三版,对引擎做了特别的修改,将额外的上下文信息(代码所在行数,所在模板文件,传入到debug函数),第四版的时候,也对引擎和表达式astnode做了修改,将变量表达式字符串也传入了debug函数。因此,如果你打开DebugFunction.java,你会看到代码并不是你想象的一行代码        

System.out.println(paras[0]);

而是多达50行内容,包括了debug模式判断,参数CharSequence类型判断,行数,文件名,变量名输出等等。

   正如debug函数实现演进,Beetl其他方面也在不断的演进中,最近一年每隔一个半月都会发布一个小版本。它持续维护的动力来源有很多,我对此有一些总结,可以提供给其他开源着参考:

 第一是要有空闲时间:无法想象早9晚9工作,还有周六加班的的程序员,能把开源做好,开源是个需要创新和交流的工作,得留出精力和时间给开源工作 。而且,开源倘若运转的很好,那也需要花费很大精力去做技术支持。所以,对于开源程序员来说,务必规划出空闲时间专注于开源开发,是成功的条件。以Beetl为例,以前在不忙的企业上班,有充足时间编写,后来换到创业公司,则会在漫长的上班路上(90分钟)构思自己要做的事情,上班过程中,完成公司任务后,可以切换到beetl开发当做休息了。更多的时间来源于下班后和周末,挤挤时间总是有的。我为了能更快的写代码,尝试过冥想编写代码,但总归是年纪不小了,只能冥想编写几行伪代码了。不像年轻的时候,能冥想多行伪代码,且能穿越各种类。 现在穿越到其他类,就穿越不回来了:) 希望冥想编码以后能有人探索一下,方便我们这样上下班路上太长的开发人员。

 第二要保持初心:对于开源者来说,大部分都是技术顶尖的人,能力很强,因此会被公司用在各个技术领域,自己也可能会把精力放在不同地方。如果开源不能保持专注,则自己的开源很可能就是搞个一年半载,就自己放弃了。或者是因为没有兴趣了,或者是因为更喜爱别的流行技术了。当想放弃的时候,可以想想自己当初为什么要做这样的开源,beetl当初想做,其实就是想学一下如何编写一门语言 能替代难用的freemarker,照这样的初心来看,beetl只完成了50%,还需要进一步完善语法解析及其后处理,完善ide集成等。这也是我一直对担心beetl停滞不前的人说,beetl还有至少2年的持续完善。初心的建立,我觉得必须纯真一点,我也知道有些开源仅为了出名的,开源只是他的一个工具,倘若出名,开源产品就会被抛弃,同样,也有人写开源是为了找好工作方便,这样人的开源产品,一点都不好用·而且,也注定不会长久


 第三:我认为的一些有用的开源技巧,这些都比较主观,但可以供后来者参考

  开源差异归根到底不是技术差异,而是审美差异: 大部分开源,都不是技术领先的,都是关乎作者的审美。而审美又是一个跟时代相关的话题,因此开源永远都有新的机会。以模板引擎为例,当xml流行的时候,freemarker流行。当js流行的时候,beetl开始流行。同样规则看到soap,和json, maven 和 gradle。beetl在开发一个新的语言特性的时候,会将从审美的观点看待这个特性,比如beetl推出的ajax局部渲染,当时就有好几个语法的样子,刚开始从本质上来将,是个局部渲染,因此,定义的语法如下:
 
block:xxxx {

}

但是,我觉得这样并不好看,对于使用者,也不明显,为何不直接叫ajax呢,既然就是为了ajax渲染用的,后来定义为  

ajax:xxxx{

}

尽管这样已经很好了,但这样写法无法与开发者已有的的经验联系起来,我就想起来html的 anchor,于是,我再次改写了我的草稿,写成如下  

#ajax:xxx{

}

这就是我想要的,也是beetl使用者一看就能明白的语法。

  选择不做比做更难。开源者技术能力强大,有很多炫酷特性都可以轻而易举加入,但我以为在选择的时候,要问自己,我为什么要加入这个功能,这个功能对使用者有什么好处,80%的使用者会用到这个特性吗?以beetl为例子,作为一个语言类技术,可供借鉴和参考的语法特性很多,而且,都很容易做到,但我大部分都选择了不做,以,python 的范围操作符号为例,    for(var i in [1..9] )  如果这个用在beetl里,确实很酷,但我觉得,采用range函数,实现一个iterabale更加能被使用者接受,而且,不需要改动引擎核心。只是一个普通函数而已,因此,最后演变成

for( var i in range(1,9)){

}

  在比如,beetl 并没有提供在模板里定义一个function功能,只提供了以模板文件放在functions目录下,自动注册为function的功能。尽管在模板里定义function,显得beetl更有程序语言气质,但我认为模板中使用function很少见,而且不易于架构师控制(架构师控制模板一直是beetl的设计出发点),所以也最终没有提供。


 从简单开始:假如你无心情,或则自认为无时间做开源的时候,建议你从简单的工作做起,比如,给你的代码增加注释,完善文档,或者写一些简单的重构。写一写的时候,你就上自己的套了,精神倍增,思路开始活跃,身不由己,开始做一些更有挑战的技术。我常常就是这么开头的。对于开源架构设计,也要尽可能简单,这就是kiss原则。简单的设计,简单的实现,然后依据反馈来改进。我觉得没有几个程序员一开始就能把程序设计和实现的很完美,就如同刚出生的婴儿一样,开始很丑的,当长着长着,就漂亮起来,相反,那些一出生就很漂亮的孩子,往往长大都不好看。一出生,就长大像成人的,医生都会说,孩子可能有问题了....

尽早获得“三敢”用户: beetl成长一直有金牌用户支持,就是我总结的“三敢用户”,
    敢用你的开源,哪怕开源还未成形。
    敢提出反对建议,对于开源功能和实现,能提出自己的意见,甚至是反对建议。
    敢于等待,出了问题,你说得周末改一下,他会一直等你到周末。有些事个人产品无所谓,有些事公司的产品,也敢这么做,让人佩服
    
    “三敢用户”是完美的开源用户,万岁 :)

 不要让开源成为公司项目.让公司支持开源项目,好处当然多,给时间也给人,说不定还有其他奖励。但好处不是白给的,公司开源,必然得为公司服务,我以为这样容易导致开源功能不足。 开源作者在提供功能的时候,也会以公司需求为基础。我曾在beetl基础上做了bingoui,一个跨终端的webui,适用于需要提供复杂内容的企业应用。这是以前公司做的,给了美工,给了前端,还给了2清华美女程序员,但最后还是失败了。并非是技术很参与者能力问题,而是做起来各种不顺手。越做越远离自己想法。进度要求导致质量降低。最后,我离开公司也导致此项目没有完成。


   前面大部分都是给其他开源这提供一些开源思路,这里也想给开源使用者里小白提供一些个人建议,毕竟beetl提供了很好的开源服务,也曾经以捐助名义提供一些一对一的服务(捐助已经停了,因为1对1太费劲,而且,有个小白捐助了10元因为得不到servlet相关技术帮助,说我长的丑,我愤而停止了捐助)。

   对于小白(指技术不懂的程序员),我想给的最大建议就是不要认为自己不懂,就唯唯诺诺。问问题总是一句一句试探,深怕被人说不懂
正确的问法,应该是包含下面内容
   1 介绍自己背景,比如,是否是新手,是否用过这个开源。这样,有助于解答者思考答案。此处应该有2行
   2 详细说出你的输入,和期望输出,以及实际输出,该有代码的贴代码,该有图的贴图。此处应该至少20行和若干图片
   3 说出自己的理解,描述你对当前问题的判断,尽管这些判断肯定不对,但有助于解答者了解你思路,从而根据你的思路来回答.此处应该有2行

    这些内容,应该尽可能一次贴出来到qq群或者论坛里,以我的经验,这样能很快得到解答,而且,解答内容跟你提问内容详细程度成正比。 你若有字,有图,我也会有代码,有详解

  对于小白的还有一个建议,还有就是要看一手资料,这来源于官网的文档,和demo。而文档需要仔细看第一章和目录。这花不了半天时间。尽管可能内容并不是小白直接想要的,但遵循第一章内容引导,大部分问题能被解决。如果你仅仅依靠baidu,对于开源技术来说,为时过早了点,而且,不是一手资料,不是过时了,就可能描述的有歧义。建议小白掌握看官网的技能,这样很快就能高大上起来。 小白如果是能成功解决问题,最好能在官网分享一下,这样有助于后来人。而且分享过程也是整理自己思路的过程。我也遇到过奇葩小白,让他在社区提问,如论如何他都不去,等问题解决了,我希望他能整理一下发表到社区,他也不干。真不知道他为什么那么忙?

  Beetl已经有快5年历史了,有网友佩服我,说我搞了一门这么好的模板语言,说我聪明。其实,我的聪明基本上停留在2013年1.0版本那个时刻,然后我的聪明劲就停滞不前了。在那之后,有数不清的开发者向beetl提供了自己建议,甚至捐助了代码。有建议将编译方式改为解释方式执行的(我不屑过这个方案),有建议提供html 标签功能的(我记得当时我大义凛然的反驳过他这个观点,甚至为这个刺头离开群而暗自高兴),有建议我参考别的语言特性的,如省略的三元表达式(我当时认为没必要),还有很多提供了自己的扩展代码,还有那些希望我提供完善的demo,指出我文档不足之处的小白。我越来越觉得,自己是开源作者,但越来越缺少主动权了,他们一直有各种想法,建议我,督促我完善beetl。我希望在他们帮助下,beetl还能再维护几年。
展开阅读全文
加载中
点击加入讨论🔥(51) 发布并加入讨论🔥
51 评论
42 收藏
23
分享
返回顶部
顶部