第一步:创建mock对象(createMock)例: MyService myServiceMock = createMock(MyService.class);第二步:记录预期行为(expect)例:SomeObject someobj = new SomeObject();someobj.setBar(”bar”);expect(myServiceMock.foo(isA(Some.class),anyInt())).andReturn(someobj );第三步:回放(replay)replay(myServiceMock);
API设计黄金法则
原文: http://programmer.97things.oreilly.com/wiki/index.php/The_Golden_Rule_of_API_Design
API的设计通常是一项艰巨的任务,尤其当设计的API非常庞大时. 如果你设计的API将会有成百上千的用户时,你要考虑今后应该如何扩展来避免不小心把客户端的代码搞挂. 除此之外,你还要考虑用户在使用API的过程中对你的影响.如果你的API类使用它内部的一个方法时,你要记得 – 用户可以通过子类复写(override)他,而这,可能会是灾难性的. 你将不能修改那些方法,因为用户已经这样使用它们了. 你今后的内部实现将无可避免的由你的用户来决定,而不再是你.
API程序员有各种各样的方法来解决这个问题,但最简单的还是禁止用户修改API.如果你用的是Java你可能会把所有的类都声明为final,如果用C#,则声明所有的方法为sealed.无论用什么语言,你都可以通过单例(singleton)或者静态工厂方法来避免用户复写代码,或者不当的扩展和使用你的代码.这些听起来很有道理,但,真是这样吗?
在过去的10年,我们渐渐意识到单元测试是一种非常非常重要的实践,但这一实践却并没有完全被整个行业所认可. 显而易见的是,大多数情况下,为一个未经测试的类编写测试用例时总是很难.你会发现使用了API的代码和API耦合的就像是上了强力胶一样.没有办法去模拟API类的行为,进而容易的测试API和你的代码之间的交互.
经过一段时间后也许会有改善,但只有我们在开始设计API时就考虑到测试问题.不幸的是,这可能需要你(API的设计者)多花一点时间 – 不仅测试自己的代码,还要考虑用户如何测试他们的代码. 这里就引出了伟大的”API设计黄金法则”: 仅仅给API写测试用例是不够的;你还要为使用API的代码写单元测试.只有这样做了,你才会在第一时间体会用户在使用你的API时进行测试时的种种问题.
让API易于测试的方法有很多.static,final和sealed并不见得是不合理的,他们有相应的使用场景.但意识到测试问题是很重要的,最好的办法就是自己去感受.一旦你这样做了,你将更加胜任各种设计挑战.
By Michael Feathers
-摘自”软件架构师应该知道的97件事”
“…但在现实世界中,最好的架构师不是要去解决难题,而是要围绕难题开展工作.架构师要能够将四处弥漫的软件问题圈起来,并画出其中的各种边界(接口),确保对问题有稳定的,完整的认识.”–Stable problems get high-quality solutions”架构师要从整体上看待杂乱无章的数据/概念/数据处理逻辑,架构师要能够将他们作为整体看待,并将它们分解为更小的片段或”块”.重点在于,这些问题必须是稳定的,它们在范围上有限且稳定,可以作为系统模块解决.”–Stable problems get high-quality solutions–上面两点说的无外两点: 正确的确定scope, 合理的架构拆解
“从架构师角度看,困难的所在,是要找到设置边界的自然之处,并定义出构建可工作系统所需要的合适接口.大型的企业系统,其自然边界稀少及多个领域之间互有纠缠,做到这点尤为困难.”–Architects’ focus is on the boundary and interfaces
“称职的架构师应该勇于接受新观念,敢于尝试新的设计思路和工具,促进项目/团队,甚至整个行业的发展;他不会浪费大把的时间参与管理层会议,或者妄想独自编写所有代码;他应该采纳好点子,营造活跃的思考氛围.只有思想开放的架构师才能平衡各种矛盾因素,顺利完成项目.”–Janus the architect
“将程序设计–或者更准确的说,软件开发, 看作发现和学习的过程,而不是生产和建造的过程.”"如果把编写代码看成设计行为,而不是生产行为,我们就能采用一些已经被证明有效的管理方式,这些方法过去用于管理具有不可预测性的创新工作,比如研发新车/新药/新的电脑游戏.我所指的是敏捷的产品管理方法和精益生产方法,比如scrum,它们关注如何为客户实现最大的投资收益”–Programming is an act of design
“沉下心来改善系统的生产效率,缩短流程,避免各行其是,才能缩短开发时间.采取一切可行的措施,例如运用模拟方法,降低依赖性,细致划分系统模块,等等.总之要杜绝一起草率提价任务的念头”–Commit-and-run is a crime
现在项目中用到大量hessian, 虽然做到了系统间的解耦和方便的调用.但并不确定当出现系统异常时如何在最快的时间发现并能自动重置.今天想了一些办法,记录下来可以在后续的工作中尝试. 这些方法并不一定只适用于hessian.
1. 拦截hessian调用异常,然后将异常请求放到重试mq中.由专门的mdb对这些调用异常进行重试.对于非实时的调用可以用这种方式, 调用方需要同样适用mdb对这些”异步的异常重试处理”进行处理. 这样做是不是反而增加了系统复杂性? 遇到异常通常是哪些原因: 无非是服务端挂掉(包括重启中),网路连接异常. 只要是暂时性的大不了重试呗. 保证数据正确性和完整性就可以了. 如果能在第一时间做到报警就很不错了.
2. 对所有的远程接口进行定期心跳测试,当满足某些规则时报警.这样可能是增加服务器的负载. 会不会因为这些反而影响到吞吐量?
3.有点类似第一条,将所有hessian调用都变为异步,充分利用mdb和mq.同步请求的处理是否能够满足要求? 还是在系统设计时就考虑一些这方面的东西 – 尽量不要使用客户端直接发起的同步业务操作; 业务操作接口设计为无状态的,避免操作之间的过度依赖 …
先就想到这么多. 休息一下,准备晚上看西班牙和荷兰的决赛!
1．引言
1.1编写目的
[说明编写这份概要设计说明书的目的，指出预期的读者。]
1.2背景
a.[待开发软件系统的名称；]
b.[列出本项目的任务提出者、开发者、用户。]
1.3定义
[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]
1.4参考资料
[列出有关的参考资料。]
2．总体设计
2.1需求规定
[说明对本系统的主要的输入输出项目、处理的功能性能要求。包括]
2.1.1系统功能
2.1.2系统性能
2.1.2.1精度
2.1.2.2时间特性要求
2.1.2.4可靠性
2.1.2.5灵活性
2.1.3输入输出要求
2.1.4数据管理能力要求
2.1.5故障处理要求
2.1.6其他专门要求
2.2运行环境
[简要地说明对本系统的运行环境的规定。]
2.2.1设备
[列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能。]
2.2.2支持软件
[列出支持软件，包括要用到的操作系统、编译（或汇编）程序、测试支持软件
等。]
1 2.2.3接口
[说明该系统同其他系统之间的接口、数据通信协议等]
2.2.4控制
[说明控制该系统的运行的方法和控制信号，并说明这些控制信号的来源。]
2.3基本设计概念和处理流程
[说明本系统的基本设计概念和处理流程，尽量使用图表的形式。]
2.4结构
[给出系统结构总体框图（包括软件、硬件结构框图），说明本系统的各模块的
划分，扼要说明每个系统模块的标识符和功能，分层次地给出各模块之间的控制与被
控制关系。]
2.5功能需求与系统模块的关系
[本条用一张矩阵图说明各项功能需求的实现同各模块的分配关系。]
[系统模块1] [系统模块2] [……] [系统模块m]
[功能需求1] √
[功能需求2] √
[┇]
[功能需求n] √ √
2.6人工处理过程
[说明在本系统的工作过程中不得不包含的人工处理过程。]
2.7尚未解决的问题
[说明在概要设计过程中尚未解决而设计者认为在系统完成之前必须解决的各个
问题。]
3．接口设计
3.1用户接口
[说明将向用户提供的命令和它们的语法结构，以及相应的回答信息。]
[说明提供给用户操作的硬件控制面板的定义。]
3.2外部接口
[说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各
支持系统之间的接口关系。]
3.3内部接口
[说明本系统之内的各个系统元素之间的接口的安排。]
4．运行设计
4.1运行模块组合
[说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说
明每种运行所历经的内部模块的支持软件。]
4.2运行控制
[说明每一种外界的运行控制的方式方法和操作步骤。]
4.3运行时间
[说明每种运行模块组合将占用各种资源的时间。]
5．系统数据结构设计
[不涉及软件设计可不包含]
5.1逻辑结构设计要点
[给出本系统内软件所使用的每个数据结构的名称、标识符以及它们之中每个数
据项、记录、文卷和系的标识、定义、长度及它们之间的层次的或表格的相互关系。
]
5.2物理结构设计要点
[给出本系统内软件所使用的每个数据结构中的每个数据项的存储要求，访问方
法、存取单位、存取的物理关系、设计考虑和保密条件。]
5.3数据结构与程序的关系
[说明各个数据结构与访问这些数据结构的各个程序之间的对应关系。]
[程序1] [程序2] [……] [程序m]
[数据结构1] √
[数据结构2] √
[┇]
[数据结构n] √ √
6．系统出错处理设计
6.1出错信息
[用一览表的方式说明每种可能的出错或故障情况出现时，系统输出信息的形式
、含意及处理方法。]
6.2补救措施
[说明故障出现后可能采取的变通措施。包括：]
a.后备技术 [说明准备采用的后备技术，当原始系统数据万一丢失时启用的副本
的建立和启动的技术，例如周期性地把磁盘信息记录到磁带上去就是对于磁盘媒体的
一种后备技术。]
b.降效技术 [说明准备采用的后备技术，使用另一个效率稍低的系统或方法来求
得所需结果的某些部分，例如一个自动系统的降效技术可以是手工操作和数据的人工
记录。]
c.恢复及再启动技术 [说明将使用的恢复再启动技术，使软件从故障点恢复执行
或使软件从头开始重新运行的方法。]
6.3系统维护设计
[说明为了系统维护的方便而在程序内部设计中作出的安排，包括在程序中专门
安排用于系统的检查与维护的检测点和专用模块。]
Scrum的运作基础是个人和团队的承诺,而非严密的规划和控制.相对于强行控制和规划,其忠诚度.自组织和员工责任感是更为有效的机制.
阅读和谈论scrum,与具体实施它是两码事.scrum必须先就位,才有机会被充分理解.-scrum敏捷项目管理 c4
用来Java_ME_platform_SDK_3.0中自带的几个模拟器居然发现无法模拟相机,而这个是在wtk2.5里一个很寻常的功能.为什么同样的一个东西升级之后变得更差呢???
最郁闷的是wtk2.5的模拟器在win7中无法打开.win7提示无法兼容配色方案.郁闷!!
jdepend使用起来还是比较容易的,但是report分析,以及背后的一些事情还是要弄明白的.否则report就真的成了只是report而没有任何实际价值.
使用jdepend的目的
分析包的依赖情况是否满足面向对象的依赖原则.其实面向对象,设计模式变出那么多花样最后无非就是要解决依赖的问题.但很多情况下,我们用了技巧却忘了为什么用,最后便的为了技巧而技巧,为了设计而设计,而忽略了最终目的.
也许这种感觉只有在深刻的体会过”混乱”之后才能理解吧.
如何分析jdepend的report
Abstractness – 抽象度,该包中抽象类所占的比例
Afferent coupling(Ca) – 被依赖度,有的翻译成传入耦合.我觉得传入耦合不是很清楚,很容易让人理解反了.指依赖该包的其他包的总数. 这个值越高说明他应该要么是公用包,要么是抽象(接口)包
Efferent coupling(Ce) – 依从度,有的翻译是传出耦合.指该包依赖于其他包的个数.通常越高表明依赖其他包越严重,如果这个包不是实现包,并不意味着ce就越大越好.依从度应该在一个合理的范围.同时依从的包应该是stable的.
Instability(I) – 不稳定性.公式 ce/(ce+ca).即依从度在所有依赖中的比例.还比较好理解,如果是完全抽象包(ca=N,ce=0),I=0,如果是完全具体实现包(ca=0,ce=N),I=1.
Distance – 指该包和理想情况的最大差距.这个有点绕.举个例子,如果一个包的A=1,也就是完全抽象的.那么他的I应该是=0的,但如果不是(也即是他还要依赖其他更抽象的包).那么distance=Instability-0(理想值).而如果一个包的A=0,即该包完全是实现,那么他的I应该是1,那么distance = 1(理想值)-Instability
而如果0<A<1,那么就不知道他的I的理想值是什么了.这个时候理想值应该是A,distance=|A+I-1|.
参考资料1
MTJ(eclipseme)中使用s60的模拟器时,启动会报错:Jar file could not be initialized.(invalid entry compressed size)
解决方法:1.在[Run]->[Run Configuration]中MIDlet页的Executable选择JAD URL,填入相应jad文件的路径,如:D:\workspaces\MoFire.jad
2.Emulation页中的,Extra Emulator Parameters中填入:-Xdescriptor:D:/workspaces/MoFire.jad
出处:http://discussion.forum.nokia.com/forum/showthread.php?t=117158
转自：http://bbs.bianews.com/thread-69395-1-1.html
MRD-“市场需求文档”，是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品，是被工 程师团队开发产品时使用。 在硅谷的一些软件公司，MRD仅仅覆盖high-level的功能。在这种情况下，产品经理通过创建了另一个文档-通常指的是PRD（产品需求文档）来 定义更加详细的产品需求。 在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。 写好MRD的10种技巧1、从用户角度的编写 从用户角度编写需求内容。使用“用例(Use Case)”和“用户角色（User Personas）”来达到这个。考虑用以下两种方法来详细说明你们公司正在开发的SFA（sales force automation）软件的“Login”的功能性。 方法A： 用户通过一个要求用户提供证书的登陆界面，然后软件允许用户带着特定的权限进入系统。软件鉴别这些证书，在鉴定通过的基础上允许用户访问那些他们有权限访问软件的功能部件。 方法B： Mike是一个销售经理，Cathy是一个销售代表。当他们打开软件，他们看到登陆界面。他们通过用户名和密码进入系统。如果用户名和密码是正确 的，他们能登进系统。一旦登陆进系统，Mike能访问软件所有的功能部件。Cathy只能访问那些对销售代表有有效的功能部件。 哪个方法更加容易阅读和理解?就我的看法,毫无疑问，”方法B”。还有，它同时减少了令人烦恼的阅读！2、使用Screen Shots
使用Screen Shots或者mockup来你的想法。我们中很多人都听说过“一张图片好比一千个文字”。当提到写MRD的时候，一个screen shot好比一千个文字！ 举个例子,看看下面这个screen shot，你需要多少字来描述？我想可能不只一千个字。3、用简单的语言编写 在我超过11年的行业中，我通常注意到的（更多是令我懊恼）一件事是用很做作的语言来写的MRD。我想这个主要是因为MRD听起来是正式的和专业的原因吧。 相反，想象你写的MRD是写给你的在工程师团队工作的朋友。你的目标是帮助他理解你需要什么，以便于他能开发产品实现这些需要。这个将有助于你避开陷入那些令读者人厌烦（有时他们会把MRD撕碎然后再碎片喂给碎纸机）的用做作的语言的陷阱。 还有： a)保持简短的语句，把长的语句分解成多个小的语句。 b)避免大篇幅的连续文本，把他们分解成多个小的章节。 c)把大块文本内容分解成，screen shots，表格、重点列表等等。4、小心的使用模板
[...]
0 | Unique Visitors |
