• Can not write anything

    日期:2009-03-10 | 分类:Uncategorized | Tags:

    Shit! It seemed that they blocked google document:-( I cannot write anything without google doc. It's like I cannot write any code without testing first. An idea in my head is writing "Change:Burning Platform". And many other stuff. Of course, until the google doc is back to normal.

  • 洽当的耦合

    日期:2009-02-16 | 分类:Software Design | Tags:

    “May all your objects be suitably coupled.”
    -- Craig Larman

    这是Craig Larman帮我在他的书上签名时的留言,并说当我读完他这本《Applying UML and Patterns》以后会有更多的体会。看来我要先放下手上的《Head First Design Patterns》了。不过《Head First》图文并茂,放下这么一本书而去读另一本满是小字的大厚书真是件痛苦的事。
    不知道Craig怎么知道我最近在研究coupling和cohesion?但我想这只是个巧合吧。“suitably coupled”的确是一个很好的祝愿,不论是对software object还是生活中的方方面面。没有耦合,软件只是一盘散沙,实现不了任何完整的功能。没有耦合,人只是孤零零的个体,失去了生活的意义。而过度的耦合让软件难于维护。过度的耦合让生活陷入一片混乱。
    没有耦合就像光棍没老婆,又没工作,没爱好,没亲戚,没朋友,然而。。。。。。
    如果有一个老婆,又偷偷的去和N个女人有关系统。。。。。。
    如果有一份工作,又在上班的时间炒炒股票、读读小说。。。。。。
    如果有几个同事,他们同时又是你的亲戚。。。。。。
    如果你的朋友要贷款,又要找你来担保。。。。。。
    如朋友找你担保贷款买你们公司的股票,而你老婆的表弟是你的下属一直在掏公司的墙角,还和你的小秘勾勾搭搭,而小秘就是找你担保的那个朋友。。。。。。

    也许我对耦合的理解还很有限。所以我要暂停前面一直在写的“解耦合手段”系列,先读读这本书,然后再来继续。
  • 色即是空,空即是色,TDD,Software Design

    日期:2009-02-12 | 分类:Software Design | Tags:

    有幸成为Craig Larman大师的host,在大师来访的这三个星期安排大师的行程,聆听大师的教诲。Craig Larman是全球敏捷方法与软件分析设计领域颇有名气的大师。大师言行非常严谨,讲究研究与调查,从不空谈所谓“opinion”。这里几天打算随笔罗列些大师的名言,作为记录。其中自然会隐去一些和公司产品相关的内容,以免不必要的麻烦。

    这天和一些在用TDD(Test-Driven Development)方法进行开发的工程师做讨论,说到了软件设计的问题。我们是否应该在开始实现,或者说开始写代码之前做Design?
    Craig Larman引用禅宗至理(Zen Buddhism)来比喻软件设计:
    “Before enlightenment, mountains are mountains and rivers are rivers. During enlightenment, mountains are no longer mountains and rivers are on longer rivers. After enlightenment, mountains are still mountains and rivers are still rivers.” (高深吧-_-!)

    回去查了一下,“enlightenment”即佛家所讲的“悟”,孙悟空的悟。汗一个先。我想那意思就是说:我们刚接触Software Design时,感觉它也就是那么点事情,很自然。可当我们悟出一些软件的道理后,忽然发现Design已经不是Design了,变得非常复杂让我们无能为力,所谓“色即是空”。这时我们不是过份Design就是没了Design。等我们大彻大悟之时,发现,Design其实还是那么点事情,即所谓“空即是色”。这似乎与前几天在电视上见到的刚刚去逝的禅宗大师圣严法师的“本来面目”有异曲同工之妙:

    过份的设计,或者叫BDUF(Big Design Up-Front),往往是有害而无宜的。BDUF一方面否定了软件设计是演化而来的,容易产生僵死的框架;另一方面为现在用不到的功能花精力,违反了lean的原则。例如冗长的软件设计文档、长达三个月的软件设计而不写一行代码,等等。都是我们在领悟软件工程的过程中附会到Design上去的东西。
    而完全依靠测试驱动的开发方式,或者用户需求驱动的开发方式也不会自然而然的产生好的软件设计。如大师所言:“TDD can also generate really bad design”。因此,依据设计原则进行合理的Design Up Front也是必须的。

    所以我想大师是要我们在纷乱的敏捷方法、软件理念之余还原软件设计的本来面目。例如在开始实现一段功能前开个简短的Design workshop,画画图,写一个快速原型或者伪代码等等。

    另外,也有人讲“Before enlightenment chop wood and carry water. After enlightenment, chop wood and carry water.”:-)

  • 上海赴美旅游团车祸的一点驾驶启示

    日期:2009-02-08 | 分类:无聊 | Tags:

    新闻中读到:
    “负责车祸调查的美全国运输安全委员会调查员彼得·科特沃斯基在当天的记者招待会上说,旅游车司机对调查人员承认,在车祸发生前他发现自己一侧的车门突然无故打开并试图伸手关上车门,这一动作分散了他的注意力,导致车辆失去控制驶出车道,随后车辆在他试图矫正方向的过程中冲向相反方向,越过道路中央的隔离带后翻覆在另一侧公路的路面上。”

    我爸爸是很有经验的老司机。他分析,这辆车很可能是压在了路肩上导致车辆向路肩方向倾斜,然后司机过度向反方向校正从而冲向相反方向的。他说,路肩,尤其是新路的路肩,有时会相对松软,阻力比普通路面要大。当一侧的轮子压在路肩上时,车辆会迅速的向路肩方向倾斜。这种情况经常在会车让路时出现。而司机经常会猛的向反方向调整,一但车子返回到普通路面时就会出现上面所说的情形。
    不管我爸推测得是否正确,起码我都学会了一课。没事可不能老往路肩上跑啊。

  • 解耦合手段之三:Open/Closed Principle

    日期:2009-01-30 | 分类:Software Design | Tags:

    这又是一个面向对向的方法。Open/Closed Principle,可以译成“开/关原则”,“开-闭原则”或者“开放封闭原则”,是说“一个软件实体应当对扩展开放,对修改关闭( Software entities should be open for extension,but closed for modification.)。”这里所说的“实体”可以是函数、类、模块等等。

    举个我所见过的比较差的例子吧。我们做的产品是由很多单板组成的分布式系统,为了适应不断提高的数据传输要求,其接口板经常要更新换代,不断升级。每次有新的接口板硬件以后,这块板上的几个程序模块都需要进行修改,甚至其它单板上的程序也要改动很多处。这种改动往往是在函数级别上的。系统的这种高耦合性给我们带来了很多麻烦,即费时又容易出问题。显然,我们的系统设计一定程度上违反了OCP,因为这个系统的模块都对修改开放,对扩展封闭。如果遵守了OCP,如果一段程序自身的功能没有BUG的话是不会被打开修改的,并且如果接口没有发生变化也不会对接口两端都进行改动的。

    还是在Uncle Bob的著作《Agile Software Development Principles, Patterns, and Practice》(PPP)中有对于这个原则的详细描述。实现OCP原则,往往要用到继承和抽象接口。这篇文章 是和《PPP》中的内容一样的。

    通常如果我们只是为了满足眼前的功能所写出的代码是不会自然而然的满足OCP和前面提到的SRP的,这就需要我们不断的对代码进行重构(Refactoring)。Martin Fowler在他的著作《重构-改善即有代码的设计》(Refactoring Improving the Design of Existing Code)一书中讲到了许多“Bad smells of code”——代码中的坏味道。如果你“闻”到你的代码中有他提到的“发散式变化(divergent change)”或者“散弹式修改(shotgun surgery)”那么你的代码可能违反了SRP或者OCP,需要重构。