内部平台效应 (2006)
The Inner-Platform Effect (2006)

原始链接: https://thedailywtf.com/articles/The_Inner-Platform_Effect

“内部平台效应”是一种新发现的反模式,即一个原本设计用于极致定制的系统,却反讽地变成了一个仅程序员才能使用的复杂平台,位于原始平台*内部*。它不是赋能最终用户,而是创建了一个需要编码知识才能修改的复杂层。 这种情况发生于当试图使系统超动态——例如,一个“数据结构建模器”(DSM)允许用户更改数据库结构——导致复杂的代码管理数据表、字段和值时。一个最近的例子是贷款发放系统,一个简单的添加表单字段请求,由于DSM的底层复杂性,需要程序员来完成。 本质上,该系统在自身*内部*复制了数据库平台的功能,但以一种可访问性和可维护性都更差的方式,从而破坏了用户驱动定制的原始目标。

这次黑客新闻的讨论围绕着TheDailyWTF.com上2006年发表的文章《内部平台效应》,该文章详细描述了为了避免直接编写解决方案而构建过度灵活系统的陷阱。 评论者分享了与类似“元解决方案”的经验,这些方案最终由于时间限制或意想不到的复杂性而未能解决原始问题。一个常见的模式是创建允许非技术用户自定义数据结构(如自定义字段)的系统,这常常导致数据库噩梦——特别是复杂的、缓慢的实现,类似于COBOL。 JSON索引和每个客户一个数据库实例等解决方案被提及,但也强调了它们可能在规模化时存在问题。一位评论员讲述了花费四年时间来撤销这样一个系统的经历,并指出一旦用户体验到灵活性,就很难放弃控制。对话还涉及现代开发实践,并提出了关于使用基于字符串的SQL查询的问题,但很快被指出文章年代久远而纠正。
相关文章

原文

I'm sure that a lot of you have may heard about "antipatterns." They're more or less the converse of "software design patterns" in that they describe a frequently repeated problem in designing a commonly-occurring solution. I've observed quite of a few of these antipatterns in the real world, but noticed that one particularly egregious (though, thankfully, rare) antipattern wasn't documented: I call it the Inner-Platform Effect.

The Inner-Platform Effect is a result of designing a system to be so customizable that it ends becoming a poor replica of the platform it was designed with. This "customization" of this dynamic inner-platform becomes so complicated that only a programmer (and not the end user) is able to modify it.

This Inner-Platform Effect has been seen here before (most recently in the Enterprise Rules Engine), but it wasn't until I read Mario's submission that I thought it was time to name and identify the antipattern.

The loan-origination system that Mario was dragged into was designed to be revolutionary: instead of relying on a programmer to make changes to the database, a user would simply need to make a few changes via the "Data Structure Modeler." I'll try to give you an idea of exactly how this ultra-dynamic storage system worked by showing a few snippets of code from the DSM:

cmd.CommandText = "SELECT * FROM tblTable WHERE Name = '" + tableName + "'";

...

cmd.CommandText = "UPDATE tblFields SET DataType = '" + newDataType + "' "
                 + " WHERE fieldId = " + fieldId.ToString();

...

cmd.CommandText = "SELECT fieldValueId, dataValue FROM tblFieldValues "
                + " WHERE fieldId = " + fieldId.ToString()
                + " ORDER BY defaultOrder";

As you may have gathered, the DSM organized data using a structure it called a "Table". These tables had one or more Fields, with each Field having a specific "DataType". A single datum was then stored as a FieldValue. All of these were stored inside of a relational database.

Ironically, Mario was brought into the system because the client wanted to add a new Field to a form.

联系我们 contact @ memedata.com