水面下的冰山——读《构建之法》

足球课上，学员们发现教练没有带球，于是向教练询问原因。教练反问道：「足球比赛，场上有 22 名球员，同一时刻一般会有几个人触球？」，学员答「1 个」，教练说，「那么，今天我们就来学习剩下那 21 个人要做的事情」

《构建之法》可能是我读过最有用的软件工程书。我已经不再写代码了，但依然翻来覆去把书读了三四遍。

读大学时，我常去旁听计算机学院的课程。最喜欢听的是算法和设计，编译原理之类的「硬课」，最让人打不起精神的就是软件工程。

后来跟几个朋友合作嵌入式项目，我负责驱动和应用程序，开始接触「工程」，发现正儿八经给客户交付一个什么东西，似乎比写一段代码复杂得多。

于是我开始饥不择食地大量阅读跟软件工程沾边的书。晚上熬夜看书，白天起床实践，整个人很亢奋。朋友们不知道我在干啥，只是觉得我满嘴概念装神弄鬼的。

我说我这次打算来个 TDD（Test Driven Design 测试驱动设计），他们同情地看看我，说行吧你爱踢哪儿就踢哪儿。我说我们至少要有三轮测试，第一轮叫做冒烟测试。朋友一听脸都绿了，噗通一声跪下，说要是你写这程序有可能把板子给弄冒烟了求你别往片子里灌。

一来二去，我开始怀疑书上那些概念和方法论究竟有没有用，如果解决问题最终还是要靠一段段代码，那么流程、工具和规范会不会只是一厢情愿的纸上谈兵？

再后来工作了，开始参与更大更复杂的项目，在不断摔跟头和反思的过程中，软件工程的概念才逐渐在意识里建立起来。有时候会突然想起过去读的某本书上的某个神神叨叨的说法，捶胸顿足，啊，原来是特么这个意思。

多年后的今天，读到《构建之法》，相见恨晚。

《构》是用心之作，作者邹欣老师有扎实的工程实践经验和理论基础。他花心思琢磨传统软件工程教学的缺陷，把软件工程这门课程做了「重构」。他并不只是写了一本书这么简单，而是通过自己和众多愿意突破传统的老师，把这套教学方法带进了真的课堂。

我也在《构》这本书的教学实践微信群里，看到邹欣老师和众多一线工程师对学生作业的讨论和点评，非常认真和投入。我想邹欣老师并没有把《构》当成一本摆在书店的书，而是把它作为改进软件工程教学方式的引子。有更多的院校实践这些方法，更多的学生因此而收益，才是他真正的期望。

软件工程大概分为「个人技能」「团队协作」「流程和规范」几部分。《构》梳理得干净利落，心态、技巧、工具等等，不一而足。大到沟通原则，细至单元测试方法，都有所涉及。

更难能可贵的是，跟我过去读到的软工书籍差别很大，这本书写得非常通俗易懂，甚至有些俏皮，完全不像板着脸的软件工程「教材」，而是不断用打比方和讲故事的方法阐述软件工程中的概念。

除了软件工程本身，我还想跟大家分享的是，在一个细节上我的「脑洞大开」。

在第二章里，有一份对比表格，对比的是菜鸟程序员和资深程序员在整个软件活动中，不同环节的时间投入。

在这份表格中可以看到，资深程序员在分析和设计以及测试中投入的时间超过菜鸟，反而在编码环节的投入低于后者。

编码一直以来是我们对「生产软件」最直观的理解 —— 生产软件不就是程序员坐在电脑前 啪 啪 啪 敲键盘写代码吗？我们会把所有其他诸如计划、设计、代码复审和测试工作统称为写代码外的「其他工作」。

我们会认为在软件活动中，用 80% 的时间写好代码，其他 20% 把其他杂七杂八做一下就好了。

其实，软件工程这个学科就建立在对「写代码之外的其他工作」的重视和优化之上。编码如果是我们看到浮在水面上的冰山一角，那么计划、估算、设计和测试等等才是水面下的完整冰山。

就像开篇时提到的足球，全场比赛大部分时间，其实是在无球跑动，拉扯空挡，干扰传球，拽衣服扯裤子中度过的。

这些「大部分时间」，最终都被有限的几个进球光环所笼罩，成为并不引人注目的「其他时间」。

一个真正熟谙某领域的高手，应该即能冷静地对待热血沸腾的精彩，又能有意识、反直觉地重视默默无闻的「大部分时间」。

他们看到临门一脚之外的兢兢业业，看到功成名就背后的隐忍琐碎，看到绽放之前的生长，爆发之前的积累。

他们愿意花时间计划和测试，他们愿意在中场控球和等待，他们对待看似不重要的「小事」同样毕恭毕敬。

他们看见平凡才是唯一的答案。

# 本文来自微信公号二爷鉴书