Ousterhout还吐槽了另一种做法，叫“宽接口的浅模块”。这种模块看着挺简单，但其实没啥用，复杂的东西没藏好，全甩给用它的人了。这就像给你个超级复杂的遥控器，按钮多得跟满天星似的，你得研究半天才能开个电视，烦不烦？用这种模块，程序员的脑子得累成狗，认知负荷直接爆表！
但另一方面，有个叫Robert Martin的大神，写了本《Clean Code》（代码整洁之道），里头提倡把函数拆得特别小，每个函数就干一件事，专注得跟激光似的。这听起来好像跟Ousterhout的观点有点儿打架。因为你把函数拆得太碎，接口就容易变多，变成“宽接口”，用起来可能得记一大堆东西。
我自己呢，之前一直是《Clean Code》的铁粉，因为这套方法用着顺手，还跟函数式编程的路子挺搭。但最近，我在一个项目里栽了个跟头，感觉有点儿被打脸了。
事情是这样的，我用了个UI库叫Radix UI，想弄个下拉菜单（DropdownMenu）。结果发现，这玩意儿用起来真心累！它的接口超级“宽”，选项多得像超市货架，灵活是灵活，但想用个简单的下拉菜单，我得先学一堆东西，简直像要考个“Radix UI认证”似的！
给你看个例子，Radix UI的下拉菜单代码长这样：
jsx
import { DropdownMenu } from "radix-ui"; |
你看这代码，密密麻麻一大堆，像不像在组装一艘宇宙飞船？想弄个简单的下拉菜单，咋就这么费劲呢？
再想象一下，如果这个库用“深模块，浅接口”的方式，代码可能会变成这样：
jsx
<Dropdown |
是不是简单得像点外卖？一目了然，啥都不用多想，直接用就完事儿了！当然，Radix的版本确实更灵活，想咋定制都行，但问题是，我得花多少时间去学啊？接口这么“宽”，学起来累得跟跑马拉松似的。
这次经历让我有点儿动摇了，开始觉得Ousterhout说得有点道理。他有一段话特别到位，我再给你翻译成大白话：
你觉得读几个短小的函数，再搞清楚它们咋一起工作，比读一个稍微长点的函数容易吗？函数拆太多，接口就多，文档得写一堆，用的人还得学一堆。函数太小，反而没啥独立性，你得把好几个函数凑一块儿才能看懂。深度比长度重要：先把函数写得“深”，把复杂的东西藏好，再尽量让它短到好读。别为了短而短，把深度给丢了！
好吧，我知道这问题没啥标准答案，经典回答永远是“看情况”。但我想问问，有没有啥靠谱的招儿，能让我判断啥时候该搞“深模块，浅接口”，啥时候该把代码拆成小块儿追求清晰和复用？有没有啥套路能让我在这两套哲学之间找到平衡？
网友热评：
1、
你说的那个经历，我完全get！一开始我也跟《Clean Code》后面跑，觉得main方法一超过10-15行就得拆，拆成一堆小函数，觉得自己代码写得倍儿干净，像刚洗完澡似的。但时间一长，问题就来了——代码是“干净”了，但想搞清楚一个函数到底干了啥，简直像在玩拼图游戏！得在这儿跳到那儿，隔几行就得翻到另一个方法去瞅一眼。更烦的是，这些小方法大多压根没在别的地方用过，拆了半天，纯属给自己找麻烦！
你现在的经验法则挺有意思：一个方法尽量控制在30行左右，差不多能装下一个屏幕。这招儿好，够直观！逻辑一目了然，又不会长到让人犯迷糊。不过你也说了，这“屏幕大小”还得看分辨率、字体大小，哈哈，这不就是“看情况”嘛！但说真的，30行左右确实是个不错的平衡点，既能让代码清晰，又不至于拆得太碎让人抓狂。
再说到Ousterhout的“深模块，浅接口”，你明显是get到精髓了！他那套理论的核心就是：把复杂的东西藏在模块里，外面只露个简单到爆的接口，别让用的人费脑子。这不就是你说的“隐藏复杂性，减少认知负荷”吗？用大白话讲，就是别把乱七八糟的细节甩给用户，让他们用起来跟点外卖一样简单！
你还提到这跟SOLID原则里的单一职责和接口隔离挺搭，确实！单一职责是说一个模块只干一件事，接口隔离是说别逼着用户去学一堆他们用不上的接口。这俩原则跟Ousterhout的“深模块”简直是异曲同工——都想让代码用起来省心，少给程序员添堵。
你说的“优先隐藏复杂性，而不是追求重用性”，这观点我给满分！重用性虽然听起来高大上，但有时候硬拆代码去追求重用，反而把逻辑拆得七零八落，读起来像在破案。你那个“清晰度和上下文切换的平衡”说得太对了！代码要清晰，但不能为了清晰把人搞晕，跳来跳去跟玩超级马里奥似的。
你的战略方针我总结一下，简直是“程序员生存指南”：
- 只露必要的接口：模块对外就给最精简的“使用说明”，别把用户当百科全书。
- 别瞎拆方法：除非方法要被重用、要单独抽成组件，或者长得超过30行，不然就老老实实待着，别拆来拆去自找麻烦。
- 随时调整策略：学到新东西就回头看看之前的选择对不对，灵活点，别死磕。
这套路子听着就很实用，感觉既照顾了Ousterhout的“深模块”哲学，也没完全抛弃《Clean Code》的清晰原则，算是找到了一条中间路。
不过我多嘴问一句：你这30行经验法则，有没有遇到过啥特殊情况？比如有些方法虽然不到30行，但逻辑复杂得像迷宫，硬留着会不会也影响可读性？或者反过来，有些方法超了30行，但逻辑简单得像1+1=2，拆了反而多余？你咋处理这种“灰色地带”？还有，你觉得Ousterhout的“深模块”和《Clean Code》的“拆小函数”有没有啥场景是完全能混搭的？比如啥时候可以既拆小函数又保持接口简单？
2、Ousterhout的哲学：有点“纸上谈兵”
先说John Ousterhout这哥们儿，他的《软件设计哲学》里讲了一堆“深模块、浅接口”的道理，听着是挺牛，但我觉得他有点儿“坐井观天”。为啥？他的例子全是些“小打小闹”的项目，像是写个计算器、弄个小工具啥的，顶多几十个文件，规模小得跟个玩具似的。可我干的项目呢？那是大到吓人！好多子系统、模块、依赖关系，复杂得像个“星际迷航”里的宇宙飞船！Ousterhout的理论用在小项目上可能还行，但放大到这种超级大项目，他的招儿就有点儿不够看了，复杂性藏不住，依赖关系越攒越多，迟早把你绕晕。
Uncle Bob的问题：别当“脑残粉”！
再说Robert Martin（江湖人称“Bob大叔”），他的《Clean Code》简直是程序员的“武林秘籍”，讲了一堆怎么把代码写得干净、拆得细小的招儿。但问题来了，很多人把Bob大叔的话当“圣经”，不带脑子照抄，搞成了“Cargo Cult编程”——啥意思？就是像原始部落看到飞机，以为拜一拜就能飞上天，结果啥也没学会！Bob大叔的建议如果用对了，确实牛，但很多人没搞懂为啥要这么干，光顾着拆小函数，代码拆得跟散沙似的，读起来得跳来跳去，像在玩“魂斗罗”！更别提Bob大叔有点儿像“推销大师”，老爱把自己的方法吹得天花乱坠，细节和取舍讲得少，搞得大家以为照着他的套路就能天下无敌，其实没那么简单！
大项目的实战经验：拆得好，代码会“自己长大”
不过，兄弟，我得说，Bob大叔的招儿也不是一无是处。我见过一些超级大的项目，团队里全是牛人，用对了Bob大叔的理念，代码写得那叫一个漂亮！他们不是死板地照抄“干净代码”，而是真懂咋回事儿。结果呢？代码库里那些公共的部分，慢慢地就“抱团”了！
咋回事儿呢？
想象你有一堆服务，每个服务干不同的事儿，但都得用一些共同的“零件”（依赖）。如果你把这些服务按Bob大叔的路子，拆成小块儿，拆得有章法，慢慢地你会发现，有些小块儿用的“零件”是一样的。这些小块儿就像“磁铁”似的，啪啪啪地吸到一块儿去！一开始是几个私有的小函数，慢慢合并成一个类，再变成一个包，再变成一个工具库，最后“哗”一下，成了一个新子系统，所有服务都能用！这过程就像种树，拆得好，树苗自己会长成大树！
但这有个前提：你得明白为啥拆，咋拆。要是瞎拆，拆出一堆没用的小函数，那不就是给自个儿挖坑？Ousterhout说得对，瞎拆小函数只会让脑子更乱，啥好处都没有！
依赖关系：拆代码的“终极奥义”
我再给你讲个更牛的招儿：看依赖关系拆代码！假设你有个类，干点业务逻辑，依赖了20个外部包（就是一堆“零件”）。你按Bob大叔的路子，把它拆成10个小函数。仔细一看，发现这10个函数里：
- 3个函数用的是同一堆“零件”（比如5个包）。
- 5个函数用的是另一堆“零件”（比如另5个包）。
- 剩下2个函数呢？啥零件都用，乱七八糟。
咋办？
把那3个函数打包，扔到一个小的“工具箱”类里，只依赖那5个包。把那5个函数也打包，扔到另一个“工具箱”类，依赖另5个包。剩下那2个乱七八糟的函数，要么再拆细，塞进这两个工具箱，要么干脆合并回原来的类，省得添乱。
现在回头看你原来的类，20个依赖还剩几个？可能就剩6个！其他14个依赖全被那两个“工具箱”接管了。你再把这两个工具箱抽象成接口，注入到你的类里，依赖直接从20个砍到6个+2个工具箱接口！这啥好处？整个系统就像被“瘦身”了，依赖链短了，编译快了，测试简单了，打包省心了，维护起来也轻松了！这招儿在Ousterhout的小项目里看不出来，因为他那些项目本来就简单，依赖链不长，优化了也没啥大感觉。
Ousterhout的优点：API设计界的“武林高手”
不过，Ousterhout也不是一无是处！他的“深模块、浅接口”在设计API的时候，简直是神器！比如你写个服务给别人用，或者搞个像Java Collections那样的公共库，Ousterhout的招儿就是“点睛之笔”。他老说，API得简单，像个“好用的小工具”，别给用户塞一堆乱七八糟的选项。
他举了个Java Stream的例子，吐槽得太到位了！Java Stream有25个类，啥都能干，灵活得像变形金刚，但问题是你得学一堆东西才能用！这就像给你个超级复杂的遥控器，按钮多到眼花，你就想开个电视，咋就这么费劲呢？再比如Google Maps API，我不想研究一堆花里胡哨的功能，我只想调个接口，画个地图，完事儿！Ousterhout的哲学就是要让API简单到“傻瓜式”，用户拿来就用，不用费脑子。
两家混搭：API用Ousterhout，实现用Bob大叔
总结下来，Ousterhout和Bob大叔其实不冲突，简直是“绝配”！API设计听Ousterhout的，搞“深模块、浅接口”，让用户用起来跟喝水一样简单。内部实现听Bob大叔的，把逻辑拆细，但得拆得有意义，盯着依赖关系拆，拆出“自带说明书”的模块。两家合起来，就是“外表简单、内心强大”的代码！
但你得悠着点，别把这两套理论当“万能药”，不带脑子乱用，啥好处都捞不着！就像练武功，光模仿招式没用，得明白为啥这么练。
有没有战略方法平衡“深模块”和“拆小函数”？再提炼一下：
- API设计用Ousterhout：对外接口要简单，藏好复杂性，像Google Maps API那样，用户拿来就用，别逼人学一堆没用的功能。
- 内部实现用Bob大叔：代码拆小块，但得盯着依赖关系拆，拆出有意义的“工具箱”，让依赖链变短，系统更紧实。
- 别瞎拆：拆之前问自己：这块儿拆了能不能复用？能不能让依赖更少？能不能让代码更清楚？如果答案是“不能”，那就别拆，省得自找麻烦。
- 用圈复杂度辅助：圈复杂度比行数更靠谱。拆代码的时候，盯着圈复杂度和依赖关系，别光追求短。
- 大项目要灵活：小项目用Ousterhout的“深模块”可能够了，但大项目得结合Bob大叔的“拆分+合并”策略，动态调整，让代码自己“长”出新子系统。