2006年08月
在做需求分析时单靠范例规格这一种技术是不够的，但这并非说“以例为规”不能用作捕获需求的首要手段。
既然已明确单以范例做规格还不够，显然就需要做更多工作，通过彻底的沟通交互，确保敲定需求中的每一件事。而以传统的需求分析技术，人们总是想当然地以为把东西写出来了，交互过程也就完成了 ——这真是一个致命缺点。阅读全文>
发表于 @ 2006年08月30日 14:23:00|评论(loading...)|编辑
连贯接口是操着一种内部DSL连贯地说事。这就是为什么我们拿“连贯”这个词来形容它。这样的API第一设计目标就是连贯性强、可读性强。
打造一套连贯API会培养出一些不同寻常的API设计习惯，最明显的一条就是setter有返回值。
Eric曾提到，目前他接触到的连贯接口都是用来装配Value Object的，Value Object没有具有业务领域意义的实体与之对应，它们可以被随心创建随心抛掉。因此，实际上连贯性依靠的是能够用老Value Object创建出新Value Object。阅读全文>
发表于 @ 2006年08月28日 00:25:00|评论(loading...)|编辑
Command与Query分离原则的实际价值在于，把修改状态的方法和不修改的明确地区分开将会带来巨大的便利：在许多情况下你可以非常有把握地使用Query，不必在意是什么地方，还可以调整多个Query的调用顺序，只需在用modifier时再小心谨慎。
我对分离原则的态度是可以遵守时就遵守，但类似pop那样的方法我不惮以违规来实现。阅读全文>
发表于 @ 2006年08月26日 00:30:00|评论(loading...)|编辑
若得到某个字段值的计算过程很耗时，你想推迟至真正用到它时再计算，这时适宜采用懒初始化。
人们说一个方法不修改一个object的可见状态，这是什么意思呢？这里的关键点并不是它们什么状态都不修改，而是不修改可见状态。一个object的可见状态是那些通过query方法可以得到的状态阅读全文>
发表于 @ 2006年08月24日 12:12:00|评论(loading...)|编辑
Eric Evans在他的杰作《领域驱动设计（Domain Driven Design）》中开创的一套针对Domain Objects的分类法，Entity通常是Customer、Ship、Rental Agreement（租赁协议）这类大物件；Value通常是Date、Money、Database Query这种小东西；而需要访问Database Connection、Messaging Gateway、Repository或Product Factory这类外部资源的一般属于Service。阅读全文>
发表于 @ 2006年08月23日 12:41:00|评论(loading...)|编辑
界定一种语言是不是DSL关键是看它在范围和能力这两方面是不是受限，DSL都有自己专门适用的领域，并且缺乏通用目的语言的某些基本特性。
先说内部DSL，和API之间的界线很模糊，两者没有本质区别，一种内部DSL其实就是一套有个漂亮名字的API（正如老贝尔实验室流传的一句名言："库设计就是语言设计"）。再说外部DSL，问题就成了它与GPL有哪些不同。一般而言，DSL无图灵完备性，且缺乏抽象机制，这是它区别于GPL的最明显的特征。
一门语言如果图灵完备还可以划为DSL吗？界定的关键在于目的——既包括语言设计者的目的，也包括语言使用者的目的。阅读全文>
发表于 @ 2006年08月21日 11:47:00|评论(loading...)|编辑
所谓领域专用语言（domain specific language / DSL），其基本思想是“求专不求全”，不像通用目的语言那样目标范围涵盖一切软件问题，而是专门针对某一特定问题的计算机语言。
先定义语法，然后通过代码生成技术把DSL代码转成一种通用语言代码，或者写一个这种DSL的解释器。我为这类DSL定了一个术语：“外部DSL”。利用编程语言自带的语法结构定义出来的DSL，我称之为“内部DSL”，也叫做“内嵌DSL”。
我喜欢用Smalltalk和Ruby的程度比喜欢用Java或C#的程度高那么多，更接近两者区别本质的是它们对构建内部DSL友好程度的差异。 阅读全文>
发表于 @ 2006年08月16日 12:50:00|评论(loading...)|编辑
“企业级Rails”这种说法大可视作自相矛盾，但说成“企业级Ruby”就是两回事了。核心Rails窄小集中，而Ruby世界（包括 Rails）宽广发散——持这种观点可以做到不偏废，其精髓就是小巧工具结合起来威力无穷。Rails已明确自己的取向，留下的缺口将会由别的框架填充，而Ruby正是一片适宜这些框架发芽、成长的绝佳土壤。Ruby这种不会僵住的胶水语言似乎正是用以迎合企业应用发展趋势的理想工具。 阅读全文>
发表于 @ 2006年08月14日 11:57:00|评论(loading...)|编辑
一种由James Noble和Robert Biddle两人提出的编程思想。其精髓（仅代表个人理解）如下：长久以来，软件开发的现代派观点认为，优秀的软件系统以统一而简单的方式由统一的组件构成（Smalltalk和Lisp就是这种思想的好例子）；而后现代主义观认为，软件是由各种各样风格迥异的东西用五花八门的方法粘合而成的（联想一下 Perl和Unix），这是种不错的软件风格（像个由各种胶着物粘成的大桶）。阅读全文>
发表于 @ 2006年08月11日 17:30:00|评论(loading...)|编辑
我用“应用式数据库”这个术语来描述一个由单一应用系统控制和访问的数据库，与之对应的概念是“集成式数据库”。因为只有一个应用访问这个数据库，所以可以量体裁衣，数据库设计越能方便地满足应用的需求也就越“合身”，这使得表结构非常具体化，通常比集成式数据库的设计更简单，更容易理解。
为多个应用存储数据的数据库叫做“集成式数据库”，它把多个应用的数据集成整合在一个库中（与应用式数据库形成对比）。
设计一个集成式数据库的表结构，要通盘考虑所有客户应用系统的需求，因此导致表结构很通用（欠缺针对性），或非常复杂，抑或即通用又复杂。数据库设计团队与应用开发团队通常是分开的，这使数据库设计修改起来非常麻烦，因为提出修改的一方不得不与数据库设计团队还有其他应用开发团队协商。阅读全文>
发表于 @ 2006年08月09日 03:45:00|评论(loading...)|编辑
有一些厉害的用户偏偏喜欢直接用基于SQL的报表工具。这种情况的一个好对策就是生成一个“报表数据库”。所谓报表数据库，是存储实际操作数据的数据库外的另一个数据库，基于领域模型编写代码给它填充数据，因此从领域模型衍生出的数据也能填进去。
虽然我是通过一个领域模型的例子引出报表数据库的，但这种方法适用于任何需要封装数据库的情况，许多人认为这类情况是面向服务构架（SOA）的目的之一。阅读全文>
发表于 @ 2006年08月07日 22:15:00|评论(loading...)|编辑
我经常听到人们说做企业软件枯燥乏味，无非是把数据传来传去，真正有本事的人得做真正地道的软件——需要很炫的算法，还得死磕硬件，没准还有满篇的数学。我觉得发生这种情况通常就是由于缺失了客户亲和力。企业软件开发对智力水平的真正挑战来自：对某一业务领域，如何弄清软件在哪些地方能产生什么样的实际贡献。要做好这件事，扎实的技术功底不能少，齐备的业务知识也不可或缺——与业务人员密切合作以积累业务知识，在此过程中取悦你的客户，企业软件开发的乐趣就在于此——另外，激励机制是使工作做得漂亮、团队富有生产力的关键所在。阅读全文>
发表于 @ 2006年08月04日 12:23:00|评论(loading...)|编辑
一个能觉得工作中满是乐趣的团队是一个能把活干得漂漂亮亮的团队。换成纯粹的生意措辞就是：它能提高生产率，能让你的开发预算更经济。开发经理们应该把他们一大块儿精力放在想办法激励和调动团队的热情和积极性上——这是我的一贯主张。
但如果大家都只把客户定位成系统最终的仲裁者，还嫌不够糟的话就坚持只用文档来交流需求，那这条激励红线就断了。阅读全文>
发表于 @ 2006年08月03日 22:22:00|评论(loading...)|编辑
临场客户是白皮书（译注1）里十二条XP实践里的一条，具体意思是：客户需要亲临开发者开放的工作空间现场，这样他们能随时回答问题，还可以随时与开发团队沟通。实际上临场客户是开发团队的一分子，军功章有开发者的一半，也有临场客户的一半。
XP里的这种客户来自组织机构的业务方，而非开发方，他们是这个系统的最终受益者，是系统的常规用户，他们供职的机构通常就是这个软件的支付方。进一步说，他们的职责就是为系统潜在的特性具有怎样的业务价值做出决策，并向开发团队描述需求。临场客户可能不只一个人，通常也是一个团队。阅读全文>
发表于 @ 2006年08月02日 23:46:00|评论(loading...)|编辑