什么是3e-3e 是什么

3E 到底是个啥？别整那些虚头巴脑的 大家手边是不是总藏着那本《软考》要么《计算机等级考试》的厚厚课本？肯定有，但那些厚厚的书里的定义，听着就挺唬人，像是啥“软件工程的三大支柱”之类的。
实际上啊，听到"3E"这几个字，大量人第一反应就是那些挂在嘴边的“可测试性”、“可维护性”之类的，结局一问一答，连个准星都打不准。 那 3E，到底是个啥？咱们不整那些教科书式的“起初、其次、最终”，也不搞啥宏大叙事。
这就好比你去买鱼，卖鱼的大妈不会让你列个清单，说啥“起初看鱼头，其次看鱼尾”，她只会把你扔进笼子里，说：“瞧见没？这玩意儿叫 3E，就是‘由此可见、易用、可测试’。”说白了，就是让你一眼看到，伸手就能拿，能随时拿出来验证一下。 为啥非得如此叫？出于软件这个东西，跟进食不一样。你吃一顿饭，讲究的是“色香味”，但进食之前你得先有“饭”这东西。软件也一样，你得有“代码”这饭。
要是代码看不见，如何知道它在干嘛？你要是看不见，伸手去拿如何办？你要是看不见，如何证明它没坏？ 那具体咋个体现呢？ 起初得“由此可见”。
这词儿听着老套，但摆在那儿就是“看得见”。
比如你写代码，别光在管住台敲点字符，得让那些变量、函数、类，能在界面上显出来。别搞那种“黑盒”系统，你不知道函数传进去啥数据，出来啥结局。你得像搭积木一样，把东西摆在桌面上，你伸手就能摸，就能看。
要是一段代码写得乱七八糟，变量名都写反了，你不仅看不见，连如何改都找不到。
这时候 3E 就体现得挺薄了，像是一块蒙着灰的石头，你摸不到纹理，更别说是挖坑了。 其次得“易用”。
这个概念，实际上是“看清楚”的延伸。大量程序员犯的最大错，就是把系统当成一个黑箱子，当作反正有文档，反正有 API 文档，那就能随意调用。结局呢？你明明调了一个方式，它却报错，你翻文档半天找不到缘由，最终发现是文档写的不对，不是你的代码写得烂。
这就是“由此可见”不到位害得的“易用”失效。
要是东西看得见，可是不好拿，那不仅难用，还好办让人形成抵触情绪。
比如一个复杂的表单提交，明明按钮在那儿，鼠标一放上去，如何都点不中，要么点下去没反应，这时候 3E 就全毁了，用户体验直接崩盘。 最终得“可测试”。
这个才是硬道理。软件这东西，核心就是“测试”。你要没法测试，那叫啥？叫玄学。可测试，意味着你有办法通过输入数据，跑出一个结局；有办法验证它是否符合要求；有办法发现它是不是漏了漏洞。
要是一段代码写完了，你连单元测试都没有，随意跑个单位测试，结局就是“全体通过”，那这份报告可信吗？还真不敢信。可测试，就是能让你拿着测试报告去跟客户说“没难题”，要么拿着代码去跟同事说“这功能确实能用”。
要是连可测性都没有，那这软件就是个魔咒，哪位也摸不着门道。 那 3E 和“可测试性”有啥区别？ 这就好比你要买一台挖掘机。 “可测试性”是你让质检员去拿尺子量一下，看看尺寸对不对，看看混凝土强度够不够。 "3E"则是让你直接把挖掘机抬到面前，骂一句“真好用”，补充一句“这轮土方量算得对”，顺便拿个卷尺量一下实际长度。 前者是事后验证，后者是事前展示和现场调整。3E 强调的是那种“所见即所得”的感觉，而不是单纯的数据达标。 再举个具体的例子。 你要开发一个电商后台管理系统。 老办法是：把代码写出来，放个 Jira 要么 GitHub 上，配个 README 文档，告诉用户“这个功能能够查询商品列表”。
这时候别看文档写得挺漂亮，但实际打开，登录进去全是默认的界面，字段全是空的，还得去后台字段库里手动填，填完还得去改，改完还得去验证。
这就是典型的"3E"缺失。代码是由此可见的（在文档和界面里），但易用性差（用户操作繁琐），可测试性弱（没人能直接跑通数据流）。 改成 3E 的做法： 把代码里的核心逻辑，直接做成一个共享的、可交互的“视图”模块。
1.由此可见：在登录页直接展示商品列表的预览，不用去后台先配置好再显示。
2.易用：把商品列表做成一个下拉框要么网格，用户直接点击“搜索”，输入，结局自动刷新。系统内部处理逻辑彻底封装，用户根本管不到那些复杂的数据库查询语句，只负责“搜一搜”。
3.可测试：在测试阶段，你能够直接往那个下拉框里输入“肯德基”，系统立马还原出肯德基菜单。
不用去爬 API，不用去跑复杂的 E2E 测试，直接给数据，看系统能不能跑出来结局。 这样改下来，用户体验提升了，代码维护性也强了。出于别人一看这个界面，“这玩意儿好操作”、“这玩意儿能跑”、“这玩意儿好办查”，心里就踏实了。 还有啊，咱们还得区分"3E"和"4E"。 "3E"更多是开发过程中，为了让产品“好卖”、“好懂”、“好测”而采用的手段。它强调的是接口、展示、逻辑的由此可见度。 而"4E"里还有一个"Engineering"（工程实践），那是把 3E 落地成标准作业流程。 比如，一个产品 ful 了 3E，但上线前没人做代码审查，没人做单元测试，就连没人做回归测试，那这个 3E 就只停留在口头了。
这时候还得加一个"4E"——工程化，也就是把你刚刚说的“可测性”变成制度，变成流程，变成标准。 故此说，3E 是地基，4E 是框架，地基不牢，框架再漂亮也是飘的。 最终再啰嗦一句，关于数据的难题。 大量人问，3E 是不是跟数据测试相关？ 有点关系，但别想复杂了。 "3E"里的“可测试”，本质上就是“数据驱动”的测试。你没法测试，往往是出于数据没预备好，要么数据没定义好（比如边界条件、异常数据）。 “由此可见”里的数据，要能被用户看到，得有清楚的字段定义和标签。 “易用”里的数据，要能被用户操作，得有清楚的输入规则和反馈。 故此 3E 和测试，不是两个对立的领域，而是同一个领域里不同维度的表现。3E 是手段，测试是目标之一。 要是数据是黑的，看不见、摸不着、测不进去，那 3E 就无从谈起。 总结一下，3E 实际上就是给软件加了个“眼”和个“嘴”。 “眼”让你看到，看到才能理解； “嘴”让你说拿到，说拿到才能验证。 别整那些晦涩难懂的术语，只要能让你的系统“看得见、用得上、测得准”，那就是 3E。 记得，3E 不是自嗨，它是为了把软件从“程序员造的玩具”，变成“用户用的工具”，而铺平的一条路。
这条路，就是从黑盒到白盒，从难用到易用，从玄学到科学。 好了，今天的 3E 就讲到这里。你要是认定这玩意儿跟你的项目相关，那赶紧找个靠谱的哥们儿要么文档，把里面的“由此可见、易用、可测试”这三个词，再扔进你的代码里，看看能不能立竿见影。别光看着繁华，赶紧动手改改，这才是真本事。