软件开发到底像什么？

程序员应该没人不知道《Code Complete》，这本30年前的著作是Code心中的“Bible”，不可超越的经典（国内初版译为《代码大全》这么lowi的名字，也没有影响它的流行，就像和合本圣经中那些半文半白的字句一样，反而增加了一点神秘的光辉）。

说来惭愧，自己竟然没有认真读过（所以我是个假程序员？）这样一本名著读起来需要费些力气，不可能像小说一样诱人，偏偏又离生产力太远，既不能告诉我如何优化性能，也不能指点我算法和技巧，优先级就总是排不上。

所以当新公司要求所有开发小伙伴必读的时候，我还是有些惊讶的：老板对”坏味道“的厌恶，对代码优美简洁的执念自是深合我意，但一瞬间头脑中闪过的书单是《代码重构》，是《测试驱动开发》，是五花八门的检查工具和IDE插件，甚至还有流程的更新与改进，但怎么会是它？一本提纲挈领的原则性图书，当然有助于全面把握概念，可这要起作用也太漫长了吧？

只能说，公司实在是太不急功近利了，甚至有点nerd，好吧，我喜欢。

”圣经“居然花了整整一章来讨论“该用什么来类比软件开发”（也就是所谓隐喻Metaphor）？真是佛系啊。

不过这还真是我从刚工作就想过多次的问题。当时流行的是概念是比作盖房子：概要设计就是做建筑蓝图，详细设计就是各种图纸和资料，写代码相当于实际动工，之后都有对应的测试验收等流程，直到项目交付。

程序员当然一眼就能看出“盖房子”类比的缺陷：建筑实在是太刚性了，一旦开始实施，几乎没有设计变更的可能，甲方也一定会认真确认需求；这跟软件系统的不断调整与生长，差距有点大。

所以《CodeComplete》的作者推崇”贝壳里长珍珠“的比喻：珍珠是一层一层逐渐形成的，最终的成品当然受最初的沙粒影响，但整个包裹的过程似乎更加关键，决定了成品是不是又大又圆有光泽；这就和软件开发过程很像了：随着代码的不断累积，一个软件系统渐渐成型，它来源于最初的设想，但“累积”的过程，决定了最终它长成什么样子：是不是足够好用、高效、灵活和安全。

不过这个类比也还是有很多缺陷：首先，生成珍珠过程中没有协作，由每只贝壳独立完成；其次，它也不需要任何计划，放一粒沙养着就是了，最终效果大差不差，不太可能直接长成Tiffany饰品，也不会残成碎瓦片；更糟糕的是，长珍珠虽然是个增量过程，但后期无法修正前面的错误，不可能重构，这跟软件开发的差异可就大了：持续、快速、小步快跑地重构，正是保持软件系统“新鲜度”的最佳实践。

在我刚上班的头几年，有幸听过一位北航老师的培训，他把软件开发类比为拍电影，私以为相当精妙：

• 电影有剧本和分镜脚本，这就相当于软件设计
• 拍电影是团队行为, 有导演、有剧务、有摄影、有演员等等一大堆角色；这跟软件系统中的产品、设计、架构师、开发、测试和运维的团队组合也非常类似
• 电影的内容有明确的界限（王家卫除外），但演员也有自由发挥的空间，这种个人发挥甚至对电影的成败影响还挺大；就像程序员在需求和设计的框架下，也需要充分发挥主观能动性一样；优秀程序员与普通程序员的代码品质，也不可同日而语。
• 虽然拍电影已经是成熟的工业行为了，可每部电影的拍摄还需需要大量创意的，不可能仅凭SOP（操作手册或流程指导手册）就能完成，软件开发也是如此
• 电影是可以在拍的过程中调整和修正的，后期剪辑也起到很重要的作用，但无论如何，它们会受到总预算和deadline（最后截止时间）的限制；同样，软件系统可以通过变更和重构来调整，也要遵守交付时间，随时承受资源不足的困扰。
  

就像电影导演和演员需要不断磨练自己技艺一样，在某种程度上，软件架构师和程序员，也可以被看做是“手艺人”。他们凭自己的技艺和创意吃饭，从不做单调重复的工作。实际上，程序员会把代码中的重复当做一种最恶劣的行为——因为一切重复都可以抽象和封装，如果不这么做，那就就是欠了一笔“技术债”，将来需要不停地偿还。

顺便提一句：正是因为拒绝重复这个特点，我们似乎永远也不用担心程序员岗位被机器取代，除非人工智能有质的突破，到那时候可能连人类都被取代了。

当然, 拍电影的类比，显然还是有破绽的，比如：

电影在完成以后，通常不会改了, 可软件很可能一直用下去, 经常还迭代出好多个版本
电影里穿个帮往往不是致命的，而软件bug有可能导致巨大的损失
电影没有太多"使用价值"，主要给人们提供"情绪价值"；相比之下，软件系统是要实实在在使用的，它理性的成分要多于感性

事实上我们永远也找不到完美的Metaphor，要想彻底理解一件事儿，最好的办法还是“躬身入局”。实际做过软件项目，才能了解它的细节，知道它为什么是这样，它和那些隐喻的差异在哪里。

同时，类比和隐喻也有它不可替代的价值：除了让入门者更容易理解，好的类比也时时在提醒我们这些局内人：什么地方可能有坑？还有哪些方法、策略和指标是我们以前没思考过的？也许可以借鉴过来。