只听本周的播客,并认为将你的一些经验归为一类是很好的,你看到设计的"架构"方面比它应该更多地支配事物.
Java在这方面经常受到不好的压力,而且随着Java EE的复杂性增加,新闻越来越糟糕.2004年之后,我的Java体验时间图显着下降,所以我觉得没有资格发表评论.
我最近的经验是建筑师拼命想要在一组(关系)数据库表(恰好是Oracle)中准确地表示对象模型.结果是一个数据库模式,如果没有首先预加入一堆表(在物化视图中),就无法有效地进行查询.
哦,是的!
在我上一份工作中,在一个非常大的项目上工作,我们有一个架构团队,它将我们使用的整个框架落实到位.他们设计了一个自定义ORM(大约2000,Hibernate不像今天这样普遍存在)和基于Swing的自定义RCP框架.
ORM不是那么糟糕.他们只是过分关注循环依赖,所以在某些情况下我们有一个非常糟糕的时间来表达我们的域模型,因为业务确实需要循环依赖(业务对象可以在不同的管理单元之间双向流动).
Swing框架很糟糕.他们试图实现一个组件模型,看起来有点像分层控制器.它在纸面上看起来非常好:你可以拥有可以重复使用的组件.模型,视图和控制器分开.但实际上,框架没有提供足够的灵活性,因此我们必须保持对JComboBox的引用以通过抽象层获取数据.我们必须为每一小部分UI编写4-5个类.在某些情况下,在表单上添加复选框需要数天时间.调试非常糟糕,因为每个简单的操作流程都要经过15-20个类.令人惊讶的是,表演还可以.
最糟糕的是,每个Swing组件都包含在一个抽象层中"以防我们想要更改UI工具包"!
几年前乔尔的讨论小组就这个话题出现了一个非常好的寓言.故事叫做为什么我讨厌框架.
我一直认为这个Hello World实现也很好.
在我过去五年工作的每个地方!
我的官方职称在过去的六年中都包含了"建筑师",但是,在一个脾气暴躁的日子里,我更像是一个反建筑师,在不那么脾气暴躁的日子里,我是一个"极简主义建筑师".
如果组件,框架或功能没有一个很好的明确和明显的理由,那么我放弃它!
在我被推翻的情况下,额外的无懈可击的建筑特征总是成为最大的问题领域.
我工作的公司生产一个具有SQL Server后端数据库的应用程序.其中一个主要表格需要加入自己六次才能获得任何有意义的数据!
这是最近的reddit,有一个很好的"yo dawg"笑话.
介绍:RequestProcessorFactoryFactory
Reddit讨论在这里
京公网安备 11010802040832号 | 京ICP备19059560号-6 