给定五六个维度约束下对比两个软件的表现，要用数据说话。这五六个维度，不限于丢包率，固有延时，抖动等。
若两个维度，一张表格即可展现，若四个维度，一个四维立方体可以展示，二维单元格里存放另一张二维表可等价，但已很难看了。六个维度怎么办？任何人都想象不到六维立方体的样子，也无法再容忍套娃二维表格。
裸数据有了，纠结于展示，这典型地犯了唯心主义的错误，坠入了形而上学的深渊。纠结于如何展现前，其实心里已经有了希望它展现成的样子，只是不知道如何做，这个样子可能是经理的要求，也可能只是大家都这么展现，只是跟风。
如果没有展现需求，裸数据怎么摆？总不能随意散落吧。
MVC 专门解决这个问题。
我十几年前接触过这概念，但从没刻意使用某些背诵下来的原则设计过什么，十多年职业生涯竟然让我的做法一下子就符合了 MVC 范式，这可能就是职业训练的力量，或者叫 1 万小时定律，肌肉记忆，无论什么词。
我是这么想的。在考虑如何展示之前，我要先把裸数据用一种方便检索的方式保存在某个结构化容器，这个容器永远摆在某个地方，展现数据时，根据需要展示的字段检测该容器。如此一来，存储，检索，展示完全解耦，互不依赖。
展现最终成了一个自然的结果，不局限在表格，也可是各种图。展现与数据彻底分离。
为了不依赖数据库设计(主要还是我自己不会，依赖他人合作可能会造成沟通延迟)，我需要自己编程来实现数据结构的设计及数据存储，检索。编程高手可能会立刻行动，但我不会编程，又想快速出一个原型。
我是这么做的。利用文件系统的 tree 结构，为了快速检索，可以采用 ramfs。
- 在 ramfs 里构建一棵按照维度组织的目录树，每个维度一个层。
- 多层目录树的叶子即一个文本文件，保存落在该维度坐标的裸数据。
- 通过 ls, cat, echo, grep/sed/awk, find, basename 等命令对该目录树增删改查。
- 将 shell 命令检索的结果喂给前端展示程序，实现展示。
如下图：
ramfs 里摆置一棵目录树的效果跟写个程序实现 tree 结构的增删改查效果完全一致。不过，若不理解快速实现原型意味着什么，这做法肯定会因性能不佳而被猛怼，我想诘问，整天性能不离口的，到底要错过多少好东西才肯承认性能是最后不得已才要考虑的。
ramfs 里摆置一棵目录树的效果跟 SQL 检索设计好的数据库的效果完全一致。anyway，ramfs 里摆置一棵树，SQL 检索数据库，编程实现 tree 结构增删改查，都是实现同一个目标的手段，若要出原型，当然哪个快用哪个。目标不是写一个高性能的，健壮的程序，而是存储，检索以及展示一堆多维度的裸数据。
编程的本质是组合逻辑，而不是采用什么语言，采用什么技法。快速做一个原型，需要摒弃这些细枝末节，同时必须解除目标和手段之间的强关联，这并不容易。
从十几年前开始，甚至大学时就读过很多关于设计模式，MVC 的书，但工作后几乎从没有涉及过相关的。虽不相关，但潜移默化中却一直都在做分层，解耦合，模块化的工作，最终形成了 “肌肉记忆”。分得清层次，拎得清主题，而不是说什么论什么，才能高效解决问题。比如，早上发了一则朋友圈“追求大而全的背后是缺乏安全感，刚刚好，不多也不少才是最高尚的。只可惜能理解这一点的人非常少。包括很多物质上很富有的人，几百平的大房子里也是堆得满满的。超过十几天用一次的东西根本不必要拥有。总想什么物件都囤着，以备不时之需，堆一堆东西反而丢失了空间，这就是没有安全感。企业也是，什么都做，一律追求做大做强，也就尾大不掉了。buffbloat，aimd不也是囤字节导致的么，即使是bbr这种思想，人们还是想能多发一个字节就多发一个字节。没办法，小而美，刚刚好，是不被理解的，很遗憾，没有安全感是因为有种观念在驱使，必须争抢，不然就落后了，这是狼多肉少环境的必然，简单说，不安全感的结果，就是一个字，卷。” 我的初衷是 “在比较160平大户型，330平大平层，410平别墅后的感慨，根据自己的需求，够用就行，还是越大越好？” 结果因为文中有个 bbr，大家就集中在 bbr 讨论，却忽略了本体。不得不说，这是程序员的通病，甚至可以说是毛病，程序员只盯着自己能直接看明白的那几个词，有点像卓别林用扳手拧姑娘裙子上的纽扣。所以难免会丢失大量真正有用的信息，从而错过原型的本质，更别提快速做出来了。够用就行？还是越大越好？我相信没有理由不选择后者。写点想法。
浙江温州皮鞋湿，下雨进水不会胖。
