下载掌阅APP，畅读海量书库
立即打开
我刚做软件开发工作时，特别关注“编程”这件事，以为最重要的工作就是写代码，对于写代码之外的事情，比如文档、测试、修复缺陷等，都比较排斥，觉得它们都是额外开销，浪费时间。但随着参与的项目越来越复杂，尤其是做了软件研发经理之后，认知发生了很大变化，我意识到，编程只是软件开发众多环节中的一环，仅仅完成它，距离顺利交付完整的软件系统，还有十万八千里的距离。
此时，我也发现，团队里的多数程序员和当初的我一样，过于关注“编码”环节，对编码之外的事情，诸如设计、文档、测试、软件开发方法论等，不是一知半解，就是主动忽略，这严重影响了个人生产力和团队生产力。我曾试着寻找一些接地气的软件工程类图书来改善这个问题，但一直没找到合适的。后来我因个人兴趣，转去做了生涯咨询工作，这件事就搁置了。
一个偶然的机会，我看到了《编程卓越之道（卷3）：软件工程化》这本书，大受震撼，这就是我当年要找的图书啊！
之所以这么说，有三个方面的原因。
第一，这本书的作者Randall Hyde一直从事嵌入式软件及硬件工程师的工作，有丰富的工程实践，同时Randall Hyde又有丰富的计算机科学教学经验，能把复杂的事情深入浅出地讲出来。
第二，这本书选择的主题，诸如生产力、软件开发模型、系统需求文档、软件需求规范、软件设计描述文档等，都是软件开发当中极重要、极难讲清楚，因而极易被忽略的内容。
第三，更重要的是，这本书让我重新理解了原来做软件开发和研发管理时遇到的4个相关问题。
业界有很多度量生产力的指标，比如可执行文件大小、机器指令、代码行数、语句数量、功能点分析、圈复杂度、操作符数量、令牌数量等。为什么最终LOC（代码行数）度量指标成功了呢？
原因有两点：一是采用LOC度量指标，统计极其方便，使用现成的工具（比如UNIX下的wc）就可以完成，而采用其他度量指标，通常需要编写一个依赖于某种编程语言的应用程序；二是现行的各种度量指标都不能完全有效地反映出程序员的生产力，选择一个“更好的”度量指标也不会有更好的结果，这就使得大家更愿意采用既易用又不那么糟糕的指标，即LOC。
不过，我们在用LOC时，一定要意识到几个缺陷：一是用代码行数无法很好地说明程序员完成了多少工作；二是用代码行数无法测量出编写代码所耗费的脑力劳动有多少；三是优秀程序员的代码行数可能偏少（他们常常重构以精简代码）；四是不同环境的代码行数无法直接比较（10行汇编代码与10行Go语言代码完成的工作可能相差巨大）。
但凡有过商业项目开发经验的程序员都在开发时间估算方面遇到过各种状况，其中最常见的是——实际的开发时间总比估算的多很多。
很多人说不清楚为什么会这样，而《编程卓越之道（卷3）：软件工程化》用了很短的篇幅就把这件事说明白了。
首先，作者指出软件开发项目的工作分为两类：一类是与项目直接相关的工作，比如编写代码、测试、发现与修复缺陷、编写文档等；另一类是与项目间接相关的工作，比如会议、阅读和回复电子邮件、更新日程安排等。程序员在估算开发时间时，一般都会把第一类工作所需的时间计算出来，但往往忘记第二类工作可能耗费的时间。
然后，在第一类工作中，又有一些需要先做大量探索才能确认的工作，在估算开发时间时还没有办法清晰定义，这就使得一个软件项目在一开始时并不能被彻底拆解成多个可以估算的子任务，最终就导致类WBS估算法难以顺畅实施。
接下来，第一类工作中关于缺陷的发现和修复这部分，也难以估算，因为你既不知道会出现多少缺陷，也不知道是否会出现一些迟迟无法修复的缺陷。
最后，大中型项目会有许多意外情况，比如掌握关键知识的程序员休假或生病，耽误了依赖他的工程师开展工作；比如一些有经验的程序员离开了，另一些人不得不接手他们的任务；比如必须等待一些硬件设备到位……很少有人能准确预测出这些情况会消耗多少时间。
如果你看了这本书，理解了开发时间估算的问题，就能更为现实和灵活地看待开发计划和进度估算。
我接触过的多数程序员都讨厌撰写软件需求规范、软件设计描述等文档，因为大家认为这些文档对确保当前项目顺利进行、提升软件项目质量等并没有什么帮助，属于纯开销。其实这只是我们没有意识到而已。《编程卓越之道（卷3）：软件工程化》指出，文档至少有如下这些作用：
● 文档是软件项目开发各个团队和各阶段协同工作的基础，比如系统需求文档可以在客户、管理层、利益相关方之间同步及确认需求；比如软件需求规范（SRS）可以产生软件设计描述文档和软件测试用例文档。
● 文档可以降低开发成本。在需求阶段，通过确认系统需求文档和软件需求规范，能够确保不做客户不需要的需求，并确保解决的是客户所面临的问题。软件需求规范和软件设计描述文档的验证过程，会确保你按项目规范开发了产品。确认和验证，能够让团队开发正确的产品并用正确的方式开发产品，可以大幅降低开发成本。
● 文档可以帮助新加入项目的程序员快速获取项目信息，有效提升他们的生产力。同时，文档还可以减少项目中的老程序员向他人普及项目相关信息带来的生产力下降。
● 文档能够帮助软件研发团队在未来的项目中预测和提高生产力。
许多程序员（包括我）对软件开发模型都会有明显的偏好，比如总用增量模型，总是嫌弃瀑布模型。但实际上，没有哪个模型好到可以适用任何类型的软件项目，也没有哪个模型不好到一无是处，我们应当理性评估，选择更适合项目的模型。
《编程卓越之道（卷3）：软件工程化》给出了非正式模型、瀑布模型、V模型、迭代模型、螺旋模型、快速应用程序开发模型、增量模型等常见软件开发模型的优点、缺点及适用边界，你只要比对一下项目情况，就可以做出自己的选择。比如很多人嫌弃的瀑布模型，其实很适合需求稳定的小项目或者超大型项目（如开发一款操作系统）；比如很多受过规范化训练的程序员讨厌非正式模型，但实际上，非正式模型对于开发小型项目的原型或向潜在客户演示正在开发的程序效果就很有用。
以上，我提到了4个问题，但这只是软件开发过程中众多问题的一小部分，还有大量的问题，在这时或那时，在这里或那里，令程序员和软件研发管理人员深陷“焦油坑”。Randall Hyde的《编程卓越之道（卷3）：软件工程化》，凝聚了作者多年的软件工程实践经验和深刻认知，可以给你系统的指导，帮助你找到属于自己的最佳实践，应对此起彼伏的问题。
最后，我想说，无论是作为程序员想要寻找更好的软件开发实践，走向卓越，还是作为管理者想要带领团队践行更好的方法，更有效地交付高质量软件，这本书都可以带给你启发。
安晓辉
资深软件开发工程师，职业规划师
《这本书能帮你成功转行》《大话程序员》《Qt Quick核心编程》作者