Browsed by
月度归档: 2011年10月

API设计:用流畅接口构造内部DSL

API设计:用流畅接口构造内部DSL

感谢@weidagang (Todd)向酷壳投递本文。

程序设计语言的抽象机制包含了两个最基本的方面:一是语言关注的基本元素/语义;另一个是从基本元素/语义到复合元素/语义的构造规则。在C、C++、Java、C#、Python等通用语言中,语言的基本元素/语义往往离问题域较远,通过API库的形式进行层层抽象是降低问题难度最常用的方法。比如,在C语言中最常见的方式是提供函数库来封装复杂逻辑,方便外部调用。

不过普通的API设计方法存在一种天然的陷阱,那就是不管怎样封装,大过程虽然比小过程抽象层次更高,但本质上还是过程,受到过程语义的制约。也就是说,通过基本元素/语义构造更高级抽象元素/语义的时候,语言的构造规则很大程度上限制了抽象的维度,我们很难跳出这个维度去,甚至可能根本意识不到这个限制。而SQL、HTML、CSS、make等DSL(领域特定语言)的抽象维度是为特定领域量身定做的,从这些抽象角度看问题往往最为简单,所以DSL在解决其特定领域的问题时比通用程序设计语言更加方便。通常,SQL等非通用语言被称为外部DSL(External DSL);在通用语言中,我们其实也可以在一定程度上突破语言构造规则的抽象维度限制,定义内部DSL(Internal DSL)。

本文将介绍一种被称为流畅接口(Fluent Interface)的内部DSL设计方法。Wikipedia上Fluent Interface的定义是:

A fluent interface (as first coined by Eric Evans and Martin Fowler) is an implementation of an object oriented API that aims to provide for more readable code. A fluent interface is normally implemented by using method chaining to relay the instruction context of a subsequent call (but a fluent interface entails more than just method chaining).

下面将分4个部分来逐步说明流畅接口在构造内部DSL中的典型应用。

1. 基本语义抽象

如果要输出0..4这5个数,我们一般会首先想到类似这样的代码:

//Java
for (int i = 0; i < 5; ++i) {
    system.out.println(i);
}

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (19 人打了分,平均分: 2.74 )
Loading...
多些时间能少写些代码

多些时间能少写些代码

我在我的微博上说过这样一段话,我想在这里把我的这个观点阐述地更完整一些。

@左耳朵耗子:聪明的程序员使用50%-70%的时间用来思考,尝试和权衡各种设计和实现,而用30% – 50%的时间是在忙碌着编码,调试和测试。聪明的老板也会让团队这样做。而傻逼的老板,苦逼的程序员会拿出来100%-150%的时间来忙着赶进度,返工,重构,fix 大量的bug… 所以, 越差的团队一般会越忙,而且还忙不完。

在现在这个浮躁的时期,再加上敏捷咨询师们念的歪经,他们让人感觉上就像是软件产品是可以在很短的时间内高质量的完成的,这令那些管理者们很兴奋,就像巴甫洛夫的条件反射实验中的狗看到了肉就会流口水那样兴奋。他们使用TDD,快速迭代,不断重构,持续集成直至持续部署的方法在进行软件开发。

软件开发真是这样的吗?难道不需要花时间去思考吗?对此,有些观点在Todd的《“品质在于构建过程”吗?》以及《Bob大叔和Jim Coplien对TDD的论战》中谈到过了。我只想想表达下面的观点:

  • 软件的精髓在于设计,设计是一件很费大脑的事件。对于软件来说,设计没有完美的,它总是一件需要取舍需要权衡的事,比如:时间换空间,空间换时间,TCP或UDP,同步还是异步,数据冗余还不冗余等等。那怕是一个小小的observers模式是pull方式还是push方式 都需要仔细讨论。这些的东西需要时间和做前期尝试。
  • TDD快速原型和迭代可能会对软件和团队产生负面影响。在一开始,你需要花很大的精力来让你的软件从无到有(做过软件的人都知道,从零开始写代码是很痛苦的事),但是因为你没有想好,先做再说,所以,后期你会面临更多的质量问题而让你需要花更多的时间精力。当然,那些咨询师会让你用持续集成和持续部署这样的方法。但我想告诉你,这并不解决你软件设计的缺陷。举个例子——TDD、迭代、原型只关注功能性需求,其不会关注非功能性需求,比如性能问题,高可用性问题,系统维护问题(模块的耦合问题),等等。而这些问题往往都可以让你的软件设计重新来过。
  • 重构是恶梦,重构应该越少越好。当你维护一个复杂的系统时你会知道重构是一件多么恐怖的事情(参看《重构代码的7个阶段》)。如果一开始没有想好,你要面临的不单单是re-design, re-architect,还要面对时间和人力成本的增加,最难的是你还要面对的是团队士气因为不断的rework而逐渐低落并产生厌倦和懈怠情绪。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (29 人打了分,平均分: 3.86 )
Loading...
Stay Hungry, Stay Foolish !!

Stay Hungry, Stay Foolish !!

在整个社会都在关注乔帮主的时候,我想在这里和大家分享一个真实的就在我们程序员身边的故事。和我在《如果你看不见你还能编吗?》一文里介绍的那些盲人程序员一样,同样是Stay Hungry, Stay Foolish。但我个人更认为我今天想要给大家讲述的这个故事对于我们这些普通人更有意义一些。我真心的希望大家认真看完这个“从刷厕所到程序员”故事后,我们能从中感悟到点什么

因为朋友的原因,我和一个创业团队经常有些往来,通过这个团队,我认识了这个故事的主人翁——王平(@wpingsuper)。其实,很早前他在Google Reader和Buzz里follow了我,但我从没和他交流过。而他的经历我却是在上周末去看望这个创业团队的时候才听说。我问他们要了王平的电话,联系了王平,详细地了解了王平的经历,并征得他的同意,在这里给大家分享他的故事。

王平是一个贵州人,03年大学毕业,体育专业,没有任何家庭背景,只能在贵州的山区里的一个中学里当体育老师,月薪150元。可能和大多数心怀梦想的年轻人一样,他并不甘心,从03年到05年间,他有好多次到北京,他觉得在大城市里有他的梦想。于是,他在04年底,05年初,他正式来到了北京,因为大学专业的问题,他无法找像大学生一样找到不错的工作,那时的他只能在北京一家很小的餐馆当清洁工,他在餐馆里洗盘子,扫地,刷厕所,一个月400元钱。

因为他的学历是这个小餐馆里学历最高的,所以,餐馆里出了什么事都会让他对去搞,所以,财务使用的电脑有了故障也让他去修,当时的他根本对电脑完全不知道是怎么一回事,但是自从接触了电脑以后他就迷上了电脑。他和我说,他这个人就是好奇心强,好动,什么都想弄一弄,所以,时间长了,弄得多了,也能为餐饮解决一些没有懂的问题,维护财务电脑就是其中之一。日子一长,虽然还是刷厕所,但是薪水也涨到了800元一个月,就连餐馆的大厨也对他说,他不属于这里,他将来一定会有前途的。当时的他还觉得不可能,笑了笑就过了。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (80 人打了分,平均分: 4.73 )
Loading...
Test-Driven Development?别逗了

Test-Driven Development?别逗了

这篇文章来源于Peter Sergeant在Write More Test 博客上的《Test-Driven Development? Give me a break…》,在原文和Reddit 上有很大反响。这篇文章里的很多观点在《TDD并不是看上去的那么美》和《再谈敏捷和TW咨询师》里都出现过(我个人觉得我的观点比其更全面一些)。就像我转的《Scrum为什么不行》 和《Bob大叔和Jim Coplien对TDD的论战》一样,从这些贴子我们可以看到——这是一个全世界的问题,并不是只有在中国才有的问题

很多敏粉都在说我在是喷敏捷,黑敏捷,向敏捷泼脏水,我只想对这些人说——你们这样的见解很肤浅也很敏感,你们根本就没有认识到——争论,反思和不同观点的意义,你也就无法了解你们所信仰的敏捷!你们只是在肤浅和盲目地信仰和教条敏捷中的许多名词、方法和标准答案罢了

——————————————正文开始——————————————

对于程序员来说有些事有非常危险的信号(red flag)。当我听到有人开始信仰Test-Driven Development 是 One True Programming Methodology(唯一正确的编程方法论),这就是危险信号(red flag),我开始假设你是一个劣等、没有经验的程序员,或是某些敏捷咨询师。

测试只是一个工具来帮助你,而不是用来证明谁比谁更虔诚,或是我的屌比你的要大,等这种愚蠢的行为。测试是用来让程序员得到有帮助的、更快的反馈,从而找到正确的路径,如果你搞坏一些事,其还可以用来给后人一些警告。这根本就不是一个神秘的有魔力的方法其可以让你的代码变得更好……

整个Test-Driven Development的概念是麻痹和信奉,从而让其成为你的人生观。相反的:Developer-Driven Testing,它给你和你的同事一些有用的工具来解决问题,来支持你自己,而不是那种以工具或方法为中心的让你假设其应该是那样的测试。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (17 人打了分,平均分: 3.12 )
Loading...
“品质在于构建过程”吗?

“品质在于构建过程”吗?

感谢@weidagang (Todd)向酷壳投递的这篇精彩的文章。原文

今天在微博上看到几位敏捷爱好者探讨敏捷测试和质量保证问题,我忍不住也加入了讨论:

Z先生原帖:我刚才看到一个大会演讲稿,谈到敏捷测试六大指导原则:1.仅靠测试人员不可能获得高质量的软件,质量是整个研发团队的责任;2. 场景是不可穷举的,测试活动必须是风险驱动的,关注于高风险的场景;3.分层自动化测试是唯一出路;4.在正确的位置进行恰当的测试是自动化的关键;【待续】

S先生回复:品质在于构建过程。检验贯穿构建过程,提供及时反馈。

我回复:什么样的构建过程才能出Unix这样的品质呢?迭代?快速反馈?TDD?

S先生回复:据说stroustrup听到重构时的反应是,我们从七十年代就这样做了。推荐《UNIX编程环境》,了解大师的编程方式。

我回复:您偷换了概念。不能说大师用了重构,C++和UNIX的品质就是靠重构或某种构建过程得来的。厨师做菜用到了勺子,不等于菜好吃是因为勺子。

S先生回复:我没有概念。我们看到一个果,就问因是什么。其实是泛因果,无因果,一切是机缘凑巧。

我回复:“品质在于构建过程”难道不是一个明白的因果描述吗?

S先生回复:品质在于构建的人。我说话时没因果,你看到了因果。

我回复:欢迎敏捷爱好者围观!

很高兴几个回合讨论下来S先生修正了先前“品质在于构建过程”的观点。什么重构、TDD、迭代、快速反馈等等构建过程都不是Unix品质的核心要素。我不但不认同“品质在于构建过程”、“测试是最好的设计方法”这类机械式的观点,而且也不满意把软件优劣归结于“人是根本”的简单回答。我们需要探索一个既非机械式,也非简单地归结为某种理念的答案。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (30 人打了分,平均分: 3.90 )
Loading...
那些曾伴我走过编程之路的软件

那些曾伴我走过编程之路的软件

收家的时候发现了一张VC++6.0的光盘,实然引发了我的怀旧情结。于是在微博上感叹了一下,看到一些朋友的回应,还有朋友提到了Turbo C 2.0,于是更回放大了我的怀旧情绪,让我回想了很多N年前伴我走过编程之路的软件。现在看下来,有些感叹,又有些可笑。感叹的是技术发展的变迁,可笑的是当时的一些想法。(Unix/Linux是在大四和毕业的时候接触的,虽然这是我的强项,但是这下面的编程这么多年来没什么变化,所以就不提了)注:图片较多,请稍等。

还记得第一次接触编程是在高中的时候,用中华学习机学Basic程序,后来到了大学,虽然学校的课程没有教Basic语言,但是DOS下有一个叫Quick Baisc的东西让我把高中时的知识又捡了回了。

大学里学的第一门语言是Pascal,所以,用的编程软件也就是Turbo Pascal,还记编译起来巨快无比,尤其是那个只有软盘和640K的基本内存的时代。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (36 人打了分,平均分: 4.44 )
Loading...