我们已经尝试将单元测试引入到我们当前的项目中,但它似乎没有起作用.额外的代码似乎已经成为一个维护问题,因为当我们的内部框架发生变化时,我们必须绕过并修复任何挂起它的单元测试.
我们有一个抽象基类,用于单元测试我们的控制器,它作为模板调用子类的抽象方法实现,即Framework调用Initialize,所以我们的控制器类都有自己的Initialize方法.
我曾经是单元测试的倡导者,但它似乎并不适用于我们当前的项目.
任何人都可以帮助确定问题以及我们如何使单元测试对我们而不是对我们有效?
使用动态代理的用例是什么?
它们如何与字节码生成和反射相关?
有推荐的阅读吗?
我正在尝试提出一个清单或一组问题/标准来评估和评估建议或紧急架构(执行架构评审).在尝试规划,评估或审查架构时,您提出了哪些最重要的问题?
我知道这是一个很大的主题,所以我想将它限制在一个端到端的系统而不是整个组织的架构.
Code Complete提供了一个不错的起点:
建筑
- 该计划的整体组织是否清晰,包括良好的架构概述和理由?
- 模块是否定义良好,包括其功能和与其他模块的接口?
- 是否合理地列出了要求中列出的所有功能,既没有太多也没有太少的模块?
- 该架构是否旨在适应可能的变化?
- 是否包含必要的购买与构建决策?
- 该体系结构是否描述了如何使用重用代码以符合其他体系结构目标?
- 是否所有主要数据结构都隐藏在访问例程之后?
- 数据库组织和内容是否合理?
- 所有关键算法都是描述和证明的吗?
- 所有主要对象都是描述和证明的吗?
- 是否描述了处理用户输入的策略?
- 描述和证明处理I/O的策略是什么?
- 是否定义了用户界面的关键方面?
- 用户界面是否模块化,以便其中的更改不会影响程序的其余部分?
- 内存使用估计和内存管理策略是否被描述和证明是合理的?
- 架构是否为每个模块设置了空间和速度预算?
- 是否描述了处理字符串的策略,是否提供了字符串存储估计?
- 是否提供了一致的错误处理策略?
- 是否将错误消息作为一组来管理以呈现干净的用户界面?
- 是否指定了稳健程度?
- 是否有任何部分过度或不足?该领域的期望是否明确规定?
- 是否明确说明了主要的系统目标?
- 整个架构是否在概念上挂在一起?
- 顶级设计是否独立于将用于实现它的机器和语言?
- 是否提供了所有重大决策的动机?
- 作为实施系统的程序员,您是否对架构感到满意?
我正在寻找具有实例的实践知识,例如,您创建的建筑中最痛苦的点是什么?
有没有办法确定在运行时从哪些jar加载哪些类?
我相信我们以前一直都在JAR地狱.我在项目上遇到了很多故障排除ClassNotFoundException
和问题NoClassDefFoundError
.我想避免在罐子里找到一个类的所有实例,并在代码上使用消除过程导致CNFE找到罪魁祸首.
是否有任何分析或管理工具可以为您提供此类信息?
这个问题非常烦人,因为我们应该在类加载时获得这些信息.必须有一种方法来达到它,或记录并找到它,但我知道什么都不会做到这一点,对吗?
我知道OSGi和版本化的软件包/模块旨在使这个问题成为一个问题......但它似乎不会很快消失.:)
注意:我发现这个问题是我的问题的一个子集,与从版本化的jar加载的类有关.
更新:有点相关,这篇文章解释了在jar中(在当前目录下)或在M2_REPO中搜索类的策略. JarScan,扫描所有子文件夹中的特定类的所有JAR文件
更新2:JBoss Tattletale也有些相关
我有兴趣为我的组织维护一个Maven 2存储库.有哪些指针和陷阱会有所帮助.
在发布代码时,在设置从库中下载或将自己的工件发布到存储库的标准时,用户应遵循哪些准则?您为此类事物制定了哪些治理/规则?您在开发人员指南/文档中包含了哪些内容?
更新:我们已经站起来并且非常满意它 - 遵循Sal的大部分指导方针并且没有遇到任何麻烦.此外,我们通过Hudson CI服务器限制了部署访问和快照构件的自动构建/部署.Hudson可以分析所有上游/下游项目依赖项,因此如果编译问题,测试失败或其他一些违规导致构建中断,则不会发生部署.厌倦了在Maven2/Maven3中进行快照部署,因为元数据在两个版本之间发生了变化."仅限Hudson"快照部署策略将缓解这种情况.我们不使用Release Plugin,但是在将快照移动到发布时,已经在Versions插件中编写了一些代码.我们也使用m2eclipse,它似乎与Nexus很好地配合,因为从设置文件中它可以看到Nexus并且知道从那里索引工件信息以进行查找.(虽然我不得不调整其中的一些设置以使其完全索引我们的内部快照.)如果您对此感兴趣,我还建议您使用您的工件部署源jar作为标准做法.我们在超级POM中配置它.
更新2:我遇到过这篇Sonatype白皮书,其中详细介绍了采用/成熟的不同阶段,每个阶段都有一个Maven资源库管理器的不同使用目标.
EJB事务属性(和注释)有一些很好的解释,例如,OpenEJB.
但有时当我试图用一些没有使用过很多交易资源的人来掩盖这一点时,我看到他们的眼睛开始茫然.
所以我的问题 - 你如何向祖母解释EJB交易属性?
我在想一个人为的例子,类比或简洁的现实用例会有所帮助.
这似乎引发了另一个问题的一些对话,我认为值得转入自己的问题.
DRY原则似乎是我们解决维护问题的首选武器,但是测试代码的维护又如何呢?是否适用相同的经验法则?
开发人员测试社区中的一些强烈声音认为设置和拆卸是有害的,应该避免......仅举几例:
实际上,由于这个原因,xUnit.net已经完全从框架中删除了它们(虽然有办法解决这种自我限制).
你有什么经验吗?设置/拆卸是否会受损或有助于测试可维护性?
更新:像JUnit4或TestNG(@ BeforeClass,@ BeforeGroups等)中提供的更细粒度的构造会有所作为吗?
截屏可以非常有教育意义和信息量.如果生产良好,恕我直言,他们可以是开发人员非常有效的学习工具,只是与经验丰富的开发人员配对.他们也可能浪费时间.
与此问题一样,你见过的与编程相关的最佳截屏视频是什么?
你喜欢或不喜欢他们的是什么?
我希望这些回复将有助于我们就哪些有效,哪些无效达成共识.
如果我正在呈现代码,我会在语法高亮的文本编辑器中显示它.但是我最近在一些演示文稿中做了更多的"实时编码",其中展示一些IDE工具非常重要.
在准备演示或演示时,我应该如何设置Eclipse?
一个在第三方库的bug导致在我的JBoss的实例的工作线程无限循环.你知道如何在不重新启动服务器的情况下杀死这个"卡住"的线程吗?我们希望能够从此恢复直到部署修复程序,最好不必重新启动.
我见过一些人提到使用Thread.interrupt() - 如果我要编写自己的MBean代码,为了打断它,我怎样才能获得有问题的线程的句柄?
更新:无法使用任何这些方法解决.我确实遇到了另一个关于同一问题的线程,该问题有一个链接到为什么不推荐使用Thread.stop().其他人也提出了类似的问题并得到了类似的结果.似乎更复杂的容器应该提供这种健康机制,但我猜他们的手与JVM绑在一起.
如果使用Subversion同步团队中的工作和Harvest作为企业记录系统,您将如何集成Subversion和CA Harvest SCM?
我正在研究的一种方法是创建一个将SVN标签加载到Harvest中的脚本,但是如果其他人之前做过这样的事情或者有更好的方法来解决问题,我很好奇.
我没有在这个领域看到任何我推荐给客户的东西.如果你使用过Spring PortletMVC,你是如何测试它的?
在portlet代码级别下测试很容易,并且通过HtmlUnit,Selenium等在客户端测试相对容易,但我没有看到任何与JSFUnit精神相关的"灰盒子"测试(其中期待我前进的方向).
我对CQRS范式有一般性的疑问.
据我所知,CommandBus和EventBus将域模型与我们的查询端数据存储区分离,最终一致性的优点,以及能够在查询端对存储进行非规范化以优化读取等等.这听起来都很棒.
但我想知道,当我开始扩展查询端负责更新Query数据存储区的组件数量时,如果他们不会开始相互竞争以执行更新?
换句话说,如果我们尝试将一个发布/订阅模型用于EventBus,并且特定事件类型有很多不同的订阅者,那么他们是否会因更新各种非规范化数据而开始相互竞争?难道这不会像我们在CQRS之前那样把我们放在同一条船上吗?
正如我听到它解释的那样,听起来CQRS应该一起消除这种争论,但这只是一种理想,实际上我们只是真正地将它最小化了吗?我觉得我可能会在这里丢失一些东西,但不能把手指放在上面.
java ×6
unit-testing ×3
agile ×1
architecture ×1
axon ×1
classloader ×1
cqrs ×1
dry ×1
eclipse ×1
ejb-3.0 ×1
fixtures ×1
harvest-scm ×1
integration ×1
jar ×1
java-ee ×1
jboss ×1
maintenance ×1
maven-2 ×1
monitoring ×1
portal ×1
profiling ×1
recovery ×1
repository ×1
review ×1
scripting ×1
spring ×1
svn ×1
tdd ×1
transactions ×1