代码大全恶搞

《代码大全》这本书，代码大全我承认它是恶搞一块砖头。一千页的代码大全砖头，砸到脚上能让人疼半天。恶搞但真正砸疼我的代码大全，是恶搞它教我的那些“正确”方法，在我自己写的代码大全烂代码面前，像是恶搞一张印满格言的废纸。

翻开第二章，代码大全它说“软件构建的恶搞核心是管理复杂度”。我当时信了。代码大全后来我负责维护一个老系统，恶搞那个系统里有个函数叫HandleAllTheThings()，代码大全八百行，恶搞里面嵌套了七层if，代码大全还有两个goto——对，你没看错，C#里居然有人用goto。我试图用书里的“重构”原则去拆它，拆到第三天，我放弃了。因为每次拆出一个子函数，就会冒出三个新的全局变量来跟我打招呼。书里说“全局变量是万恶之源”，可那个代码库里，全局变量是基础设施，是水电煤。我拔了电，整个楼都黑了。

书里还强调“命名要自文档化”。我见过最诚实的命名是temp1、temp2、temp3，它们在一个事务处理里按顺序传递，谁先谁后全靠注释——而注释早就过期了。后来我学乖了，把temp1改成customerId，结果发现它其实存的是订单号。那一刻我明白，命名问题从来不是词汇量问题，是需求理解问题。书里没告诉我，需求文档本身就是一团浆糊。

最讽刺的是“代码评审”那一章。它列了一堆检查清单，像体检表一样详细。我照着做了，把同事的代码批得体无完肤——变量名太短、函数太长、缺少注释。同事没说话，默默把代码改了一版，然后整个模块跑得飞快，但可读性变得更差了。他说：“我按你的要求，把每个循环都拆成了函数，但性能降了40%。”书里没提过性能跟可读性打架的时候怎么办。它默认你写的是学术代码，跑在理想机器上。

后来我翻到附录，看到那句“代码是给人看的，顺便让机器执行”。这话说得漂亮，但现实是，代码首先是给老板看的——他只看交付日期。其次是给审计看的——他们只看有没有违规调用。最后才是给人看的，那个人可能是三个月后的我，而那时的我已经忘了当时为什么写那个if (flag && !oldFlag || retryCount > 3)。书里教我写清楚，但没教我如何对抗“下周一上线”的魔咒。

我承认，那本书里的很多原则，在干净的项目里是金科玉律。可现实项目都是泥潭，泥潭里游泳，姿势再标准也会呛水。书里没写“如何优雅地处理脏数据”，也没写“如何说服产品经理砍掉一个逻辑漏洞百出的需求”。它只写了“如何把代码写对”，但没写“如何识别什么才是‘对’”。

有一次我实在没辙，把那本砖头从书架上拿下来，想找个“如何处理遗留系统”的章节。翻遍了目录，只有“重构”和“测试”。我笑了。重构的前提是你有测试，可这个系统连测试框架都没装。书里说“没有测试的重构是危险的”，那我能怎么办？我只好继续在泥潭里打滚，一边滚一边骂这本书太理想化。

但骂完我又把它放回书架了。因为我发现，骂它归骂它，但每次写新模块时，我脑子里还是会闪过那些原则——哪怕只遵守了一条“单一职责”，至少让我的HandleAllTheThings()少了两百行。它没法拯救烂代码，但它至少让我没成为写出那种烂代码的人。这大概就是它的用处：一本不会告诉你所有真相，但能让你在黑暗中摸到一根火柴的书。虽然火柴经常点不着，可你手里有它，总比没有强。

很赞哦!（317）