项目一开局就乱成一锅粥，真别总怪大家技术拉胯。说白了，就是手太快。需求文档刚拍桌上，纸都没热透，开发们已经一窝蜂扑向编辑器，键盘敲得劈里啪啦响。还自我催眠呢：“看，进度看得见，反馈多快。” 呵。看着忙，其实是瞎忙。刘振安在《面向对象技术与UML》里早就把话撂那儿了：好架构，真不是靠代码一行行硬垒出来的。你得先把手头的事儿捋顺了，把抽象关系理清楚了，系统的骨架才能立住。这书的主张听着挺反直觉。它天天把UML和面向对象分析设计挂在嘴边，压根没想逼你背那些死板的图表规范。而是死磕一种“先盯关系，再抠实体”的脑回路。写代码琢磨的是“怎么干”。搞建模问的却是“到底是个啥”，以及“它们怎么搭把手”。
非得先捋关系？我觉得吧，人脑这玩意儿容量有限。需求一砸过来，你不画个草图就闷头干，跟闭眼钻迷宫有什么区别？多试一个函数，系统里的耦合度就悄悄涨一截。到最后，改个需求得牵动全身。光跨组扯皮就能耗掉大半天。书里讲UML流程的时候，把“分析”和“设计”的分界线划得那叫一个清楚。分析那会儿，先把技术皮毛扒干净，只死磕核心概念和交互逻辑。等进了设计阶段，再把架构模式和持久化机制搬进来。这步拆法看着多绕了个弯，其实是用最少的本钱试错。系统里的类啊、模块啊，压根不是各玩各的孤岛。依赖、继承、关联、组合。它们之间的线早就缠在一起了。不把这些关系先摊在桌面上，代码写到后半截，准变成一团解不开的毛线。建模这活儿，说白了就是把脑子里那套藏着的逻辑拽出来晒晒太阳。让以后可能冒出来的变动，提前现原形。
工程圈里大伙儿最爱踩的坑，就是拿战术上的瞎忙活，去糊弄战略上的懒得想。会上为需求细节吵破头。开发时熬夜赶进度。测试时疯狂填Bug。上线后接着疯狂重构。这循环听着就心累。全是因为把前期该啃的架构硬骨头，一股脑往后拖。一开始画图看着磨叽，甚至让人觉得不务正业。但这笔账算的是风险成本。关系一通，敲代码就是顺着河道放水。关系没通呢？写代码就是往烂泥坑里塞补丁。书里拎出软件体系结构模式和持久对象，说白了就是敲打咱们：对象的状态是活的，会跟着时间变；模块的边界也会跟着业务长个儿。把这些动态变化提前画成图，等于在代码真刀真枪落地前，先拉出来跑了一圈压力测试。我常跟同行吐槽，很多项目上线后那叫一个“重构循环”。其实都是前期没把关系摊开，后期拿命在填坑。
不过这话也不是包治百病的万能油。我觉得吧，这事儿未必能套用在所有项目上。把它当紧箍咒念，很容易把自己绕进过度设计的死胡同。需求还没个准信儿，团队就两三个人，或者产品得抢着去市场里碰运气的时候，硬逼着画全套UML、搞严丝合缝的面向对象分析，纯粹是给自己上枷锁。书里的底子，是奔着系统复杂度够高、得拉帮结伙或者长期伺候的场景去的。它管不了从零到一的草莽闯荡，专治从一到百的秩序混乱。复杂度还没爬坡的时候，靠直觉瞎蒙加快速迭代，确实比死磕建模痛快。可一旦越过那道坎，不画图省下的时间，早晚得连本带利用返工还回来。成本涨得让人头皮发麻。初创期拼的是速度，不是图纸的漂亮程度，这点可能得认。
说到底，UML和面向对象设计最值钱的地方，根本不是图表画得标不标准。而是它能给你泼盆冷水，让你学会收着点。收着点瞎动手的冲动。收着点死抠局部优化的执念。把眼睛盯在整体结构上。咱们折腾这套东西，图的就是在敲下第一行代码前，脑子里能铺开一张明白的图纸。路就是这么走的。目光放得越开，脚下踩得越实。先把筋脉疏通了，再下手术刀。这不是死脑筋。是面对复杂系统时那点本分的敬畏心。毕竟代码是写给机器跑的，但架构是给人看的。图纸画得再糙，也比脑子里一团浆糊强。