Making Best Use Of Anything,Creating Most Value!

1)使用名词/动词分析和寻找类名词/动词分析方法的第一步是尽可能多的收集相关信息.合适的信息来源是:补充需求规格说明(如果有)用例项目词汇表任何其他信息资源(架构,远景文档等)2)在收集文档之后,使用非常简单的方法分析他,突出(或者用某种其他方法记录)以下内容: 名词--例如:航班名词短语--例如,航班号动词--例如,分配动词短语---例如,验证信用

前面简要讲了关于FIT的用法,在接下来的文章中,我将详细介绍FIT的用法.由于FIT的不断更新,其文档也是不断进步,所以为了得到最近的信息,请访问http://fit22.c2.com .首先介绍ColumnFixture:Coulmn映射测试数据的列到子类的方法或变量.一个新的Column fixture为每个使用它的表创建,同样的Column fixture会从上到下处理每行,从左到右处理每列

   Fixture内幕  你的fixture对表可以做任何他们想做的,包括增加行和单元格(参看TechnicalReference ,查找如何进行),但是大多数fixture仅仅标志单元格为对和错.这里由一些标记的规则:绿色 Fixture比较单元格和软件,他们匹配 红色 (包括 "expected" 和 "actual" 部分): Fixture比较单元格和软件,他们不匹配 黄色: fixtu

接上文. 运行FIT 剩下的文档讨论使用FIT的技术方面.为了得到你的FIT版本的更多信息,参看TechnicalReference.我们快速覆盖了许多方面,因此你也可以在FitDocumentation,看其例子,像SimpleExample. FIT是命令行工具(参看“TechnicalReference.的FIT Command Line“),这允许你在你的脚本里很容易的包含他.

 本文来源http://fit.c2.com/wiki.cgi?ProgrammersQuickStartGuide,基本上是翻译了原来的文档. Programmers Quick Start Guide(work in progress)      客户的参与对软件成功是关键的.最为一个程序员,你需要一种方法来理解你的客户的需求,因此你才能写出很好的软件.FIT为你和你的客户提供了一

FIT FOR Dot NET 介绍了我是如何发现这个工具的.下面我将介绍这个工具.在写本文时,参考了FIT的站点http://fit.c2.com/.其中有些是直接翻译的.1)如何得到FIT工具   FIT工具分为.NET 版本和Java版本,你可以到http://www.sourceforge.net/projects/fit去下载.2)FIT的介绍  2.1  介绍         首先,F

作为软件开发,客户的参与是软件成功的基础.作为程序员,我们需要一种方法来理解客户的需求,只有理解了客户的需求才能写出最好的软家.那么这种理解客户需求的方法是什么呢?这种方法有可能是利用文档,有可能是利用工具,或者是其他.对于我目前工作的公司而言,主要是通过EMail的形式来了解需求.酒窝个人而言,这种需求的方法不是令人满意.因为需求都是以叙述文本的形式发给我们,很少有出现类似表格,图等形式的文档,

自去年开始,我就翻译Test-Driven Development in Microsoft .NET>>( by James W. Newkirk and Alexei A. Vorontsov  Microsoft Press © 2004)当时,翻译这本书:主要有一下几个目的:1)出于兴趣2)学习TDD3)也就是别把英语给忘了4)学习学习大师们如何实现软件系统的5)学习大师们如何写书的6)理

这次写的是Pet Shop各层之间是调用的.其主要体现就是在各个namespace里面.既然这样,所以我稍加整理了一下,就有了如下图:看了这个图,我想我得心里就有底了.

正在学习PetShop3.x,现将一些自己的一些总结写出来.PetShop3.x分层分得很清楚,分别为UI,Business Layer,Data  Access Layer,典型的N层体系结构.表现的非常棒.但是仔细一看源代码,发现并不是那么简单分清楚,原因就是在表现Data Access layer时,做了一些易于扩展的架构,那就时工厂模式.所以为了把它搞清出,我专门选了一个功能来研究,其他的

最近一段时间，不停的阅读代码。有些代码易于阅读，有些代码写的晦涩难懂。有些代码看起来相当舒服，但是有些代码非常龌龊。相比之下，我得代码写的如何呢，恐怕不敢恭维。最近一段时间对之体会甚是深刻。其实在一个软件中，我认为最好的文档就是代码，如果把代码写好了，将是一笔很大的财富，无论对谁。代码不要注重形式化，也不要为了实现某一功能而东一凑西一凑，最后面目全非，满目疮痍，这是一种悲哀。每个程序员都希望自己的

1） 单一职责原则 （The Single Responsiblity Principle，简称ＳＲＰ）2)    开放－封闭原则 （The Open－Close Principle，简称OCP）3） Liskov 替换原则（The Liskov Substitution Principle,简称LSP）4） 依赖倒置原则（The Dependency Inversion Pricinple，简称

对于需求，如果你不是太明白，在写代码之前，最好将之弄清出或者大致弄清出，不然的话你自己有的时候都不知道你自己在写些什么。以上和需求的可变性是两回事，他是明确了需求。所以在此需要强调的就是如何根据可变的需求作出很完美的设计。XP是一个选择。到现在，我认为自己以前的东西都是有些是“垃圾”。希望以后自己好好的去实践，避免设计和写出龌龊的软件来。原来软件是多么美好的事情。

人，在各个方面都是很重要的。在软件开发也不例外。组织好的团队比好的环境重要的多。应该先组织团队然后根据团队来组织环境，而不是先组织环境再来组织团队。但是，很多时候都不是这个样子的。以上是我的理解。

1)每个类大约有3-5个职责.?? 一般来说,类应该尽可能保持简单.这通常限制类能够支持的3-5个职责的数目.2)不存在独立的类.好的OO分析和设计的精华是,类相互协作使用户受益.同样,每个类应该同少量的类协作以提供所有的期望的功能.类可以把他们的一些职责托付给专注于特定功能的其他辅助类.3)当心一些非常小的类.有时候很难取得正确的平衡.如果模型看起来有大量的非常小的类,每个类

UP具有三个公理：用例和风险驱动 架构中心的 迭代和增量的用例是捕获需求的方法没因此我们可以准确地说，UP是需求驱动的。风险是另外一个驱动，因此如果你不主动攻击风险，风险就会主动攻击你。UP通过风险分析预测软件构造。然而这是项目经理和架构师的工作。 开发软件系统的UP发送方法是开发和演进一个健壮的系统的系统架构。架构描述了策略：系统是如何被分成组件，这些组件是如何交互和

聚合(Aggregation):   这是一种松散的对象间的关系.举个例子:计算机和他的外围设备就是一例.  用来表示拥有关系或者整体与部分的关系。组合(Composition):这是一种非常强的对象间的关系,举个例子,树和它的树叶之间的关系.在一个合成里，部分与整体的生命周期都是一样的。一个合成的新对象完全拥有对其组成部分的支配权。包括他们的创建和毁灭。最后总结一下：

对于ColumnFixture,我认为比较复杂,所以我用的不太多,在这里我把它的理解说一下,其中很多观点来源于其网站.Row FixtureRowFixture将测试数据的行和测试下系统的对象作比较,方法在对象以及与表数据比较的返回值上调用,一个算法符合带有基于一个或者多个键对象的行.对象可以遗漏,也可多余,这些都是需要注意的.下面的Q&A来自其网站:Q: RowFixture.match is