程序员应该没人不晓得《Code Complete》，这本 30 年前的著述是 Code 心中的“Bible”，不可超过的经典（国内初版译为《代码大全》这么 lowi 的名字，也没有影响它的风行，就像和合本圣经中那些半文半白的字句一样，反而减少了一点神秘的光芒）。
说来惭愧，本人居然没有认真读过（所以我是个假程序员？）这样一本名著读起来须要费些力量，不可能像小说一样迷人，偏偏又离生产力太远，既不能通知我如何优化性能，也不能指导我算法和技巧，优先级就总是排不上。
所以当新公司要求所有开发小伙伴必读的时候，我还是有些诧异的：老板对”坏滋味“的讨厌，对代码柔美简洁的执念自是深合我意，但一瞬间头脑中闪过的书单是《代码重构》，是《测试驱动开发》，是形形色色的查看工具和 IDE 插件，甚至还有流程的更新与改良，但怎么会是它？一本提纲挈领的原则性图书，当然有助于全面把握概念，可这要起作用也太漫长了吧？
只能说，公司切实是太不急功近利了，甚至有点 nerd，好吧，我喜爱。
”圣经“竟然花了整整一章来探讨“该用什么来类比软件开发”（也就是所谓隐喻 Metaphor）？真是佛系啊。
不过这还真是我从刚工作就想过屡次的问题。过后风行的是概念是比作盖房子：概要设计就是做修建蓝图，具体设计就是各种图纸和材料，写代码相当于理论动工，之后都有对应的测试验收等流程，直到我的项目交付。
程序员当然一眼就能看出“盖房子”类比的缺点：修建切实是太刚性了，一旦开始施行，简直没有设计变更的可能，甲方也肯定会认真确认需要；这跟软件系统的一直调整与成长，差距有点大。
所以《CodeComplete》的作者推崇”贝壳里长珍珠“的比喻：珍珠是一层一层逐步造成的，最终的成品当然受最后的沙粒影响，但整个包裹的过程仿佛更加要害，决定了成品是不是又大又圆有光泽；这就和软件开发过程很像了：随着代码的一直累积，一个软件系统慢慢成型，它来源于最后的构想，但“累积”的过程，决定了最终它长成什么样子：是不是足够好用、高效、灵便和平安。
不过这个类比也还是有很多缺点：首先，生成珍珠过程中没有合作，由每只贝壳独立实现；其次，它也不须要任何打算，放一粒沙养着就是了，最终成果大差不差，不太可能间接长成 Tiffany 饰品，也不会残成碎瓦片；更蹩脚的是，长珍珠尽管是个增量过程，但前期无奈修改后面的谬误，不可能重构，这跟软件开发的差别可就大了：继续、疾速、小步快跑地重构，正是放弃软件系统“新鲜度”的最佳实际。
在我刚下班的头几年，有幸听过一位北航老师的培训，他把软件开发类比为拍电影，私认为相当精妙：
- 电影有剧本和分镜脚本，这就相当于软件设计
- 拍电影是团队行为, 有导演、有剧务、有摄影、有演员等等一大堆角色；这跟软件系统中的产品、设计、架构师、开发、测试和运维的团队组合也十分相似
- 电影的内容有明确的界线（王家卫除外），但演员也有自由发挥的空间，这种集体施展甚至对电影的成败影响还挺大；就像程序员在需要和设计的框架下，也须要充分发挥主观能动性一样；优良程序员与一般程序员的代码品质，也不可同日而语。
- 尽管拍电影曾经是成熟的工业行为了，可每部电影的拍摄还需须要大量创意的，不可能仅凭 SOP（操作手册或流程领导手册）就能实现，软件开发也是如此
- 电影是能够在拍的过程中调整和修改的，前期剪辑也起到很重要的作用，但无论如何，它们会受到总预算和 deadline（最初截止工夫）的限度；同样，软件系统能够通过变更和重构来调整，也要恪守交付工夫，随时接受资源有余的困扰。
就像电影导演和演员须要一直磨难本人技能一样，在某种程度上，软件架构师和程序员，也能够被看做是“手艺人”。他们凭本人的技能和创意吃饭，从不做枯燥反复的工作。实际上，程序员会把代码中的反复当做一种最顽劣的行为——因为所有反复都能够形象和封装，如果不这么做，那就就是欠了一笔“技术债”，未来须要不停地偿还。
顺便提一句：正是因为回绝反复这个特点，咱们仿佛永远也不必放心程序员岗位被机器取代，除非人工智能有质的冲破，到那时候可能连人类都被取代了。
当然, 拍电影的类比，显然还是有漏洞的，比方：
电影在实现当前，通常不会改了, 可软件很可能始终用上来, 常常还迭代出好多个版本
电影里穿个帮往往不是致命的，而软件 bug 有可能导致微小的损失
电影没有太多 ” 应用价值 ”，次要给人们提供 ” 情绪价值 ”；相比之下，软件系统是要实实在在应用的，它感性的成分要多于理性
事实上咱们永远也找不到完满的 Metaphor，要想彻底了解一件事儿，最好的方法还是“躬身入局”。理论做过软件我的项目，能力理解它的细节，晓得它为什么是这样，它和那些隐喻的差别在哪里。
同时，类比和隐喻也有它不可代替的价值：除了让入门者更容易了解，好的类比也时时在揭示咱们这些局内人：什么中央可能有坑？还有哪些办法、策略和指标是咱们以前没思考过的？兴许能够借鉴过去。