Beetl开源那些事2

为什么80%的码农都做不了架构师？>>>   

 

  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还能再维护几年。

转载于:https://my.oschina.net/xiandafu/blog/530959