一本软件开发人员都该读的好书

我是做车载软件的，有一次因为软件交付问题客户投诉到了销售老大，销售老大发了个全员邮件意思是说他对外标榜的工程能力已经被狠狠的打脸。那是我第一次听到工程能力这个词儿，但未深入探究。后来项目上陆续又出了几次质量问题，我才开始想去了解到底什么是工程能力。于是在豆瓣找了一本相关的书《代码的艺术》，那本书里提到了《软件开发的201个原则》，于是又买来读，后来发现竟是同一个作者章淼（后者是译者）。章淼察觉到了一个事情，根本上保证质量的是人，只有开发者有了工程意识，有了质量意识，才能交付高质量的软件。我粗鄙理解，一个人如果不用心做事，不管拥有什么学历，掌握什么技术，熟悉什么方法，他在工作中的表现都可能都不会很好。所以在提升工业软件的综合能力上，培养一种工程意识，培养对工程能力的理解和尊重，似乎才是我们缺少的东西。 下面对我印象深刻的原则做了摘录和注解。 ◆一般原则 原则1：质量第一。 想办法提升质量是没有错的，质量第一。 原则3：开发效率和质量密不可分。 同样的条件下，高质量的产品必然需要更多的投入，效率也必然有所下降。 原则15：看到越多，需求越多。 给客户提供的式样书，写的越细节，客户提出的要求就会更多更细节，这会让自己很被动。所以在提供式样书的时候需要把握好平衡。 原则18：让软件只需要简短的用户手册。 不要指望通过用户手册让软件变得好用，好的软件不需要繁杂的用户手册来指导使用。 原则20：记录你的假设。 所有的事情都是建立在假设的基础上的，需要记录自己的假设。 ◆需求工程原则 原则43：记录需求为什么被引入 需要记录需求被引入的原因和背景，项目时间跨度较长的话，项目后期可能会忘记需求对应的原因。如果因为某些原因需要进行变更时，引入原因将是考虑因素之一。 原则46：避免在需求分析时进行系统设计 需求分析是分析需求的合理性和必要性等。如果这个需求是好的，才考虑如何实现。而不是难就不做，容易才做。 原则59：自毁的待定项 为了防止一些TBD的事项后续无人跟进，每个TBD都要有负责人以及问题解决的时间。 ◆设计原则 原则64：没有文档的设计不是设计 设计描述的是思考过程，思考过程是在人的大脑中完成的，如果设计没有落入文档，那无法证明思考过，也无法证明设计的合理性。 原则65：封装 封装不但可以使使用更加便捷，只要调用一下外部接口就可以，无需理会内部逻辑。它还能降低发生错误的概率，因为内部的处理已经被封装不可见，所以很难影响其内部动作。 原则66：不要重复造轮子 某些功能如果之前已经设计过，那最好直接复用，不需要重新开发，任何的变动都有可能引入问题。 原则67：保持简单 要不简单到没有明显的问题，要不复杂到没有明显的问题。这句话说得可太好了。 原则68：避免大量的特殊案例 如果一个设计有很多的特殊按理，那说明设计的并不好。 原则69：缩小智力差距 软件的设计要尽量与现实世界一致，让所有人都好理解。其实万事万物的道理和逻辑都是共通的。 原则73：使用耦合和内聚 设计需要尽量做到低耦合、高内聚。 ◆编码原则 原则88：避免使用全局变量 全局变量意味着所有模块都可能影响该变量，减少了全局变量的使用，也就减少了不确定性。 原则97：代码审查 代码检查发现的错误大概占所有被发现错误的85%，对于发现错误，代码审查比测试要好得多，如果这都不能激励你进行代码审查，我不知道还能做什么。 ◆测试原则 原则111：测试只能揭示缺陷的存在 测试只能揭示缺陷的存在，并不能提升开发的质量。不要寄望通过测试来提升软件质量。在我看来，越是水平低的公司越把质量保证寄托在测试身上。 原则113：成功的测试应当发现错误 测试没有发现缺陷并不是什么好事，如果软件没有问题也就不需要测试了，测试的目的就是为了找出缺陷。所以，有的公司会把验证出的bug数量作为测试人员的KPI。 原则114：半数的错误出现在15%的模块中 Bug的分布也有二八法则，分析Bug分布对管理Bug来说很重要。 原则117：测试不正确的输入 不要只测试正确的输入，因为我们无法控制软件会被如何使用，需要测试不正确的输入。 原则119：大爆炸理论不适用 不要存在侥幸心里，认为可以跳过某些环节，即节省时间还能保证质量。不信你可以试试，跳过单元测试直接集成测试，临时性的时间会节省，但后面擦屁股成本恐怕高的离谱。 ◆管理原则 原则142：你可以优化任何你想要优化的。 发现问题不难，想到解决方案似乎也不难，但是执行很难。很多事情只要你想做都能做成，且不说“完美解决“吧，起码的”得到优化“是完全可能的。 原则147：不要设定不切实际的截止日期 一次两次还行，如果经常设定神仙来了都完成不了的deadline，项目成员就会麻木，失去紧张感。当截至日期失去了严肃性，那它基本也就形同虚设了。 原则153：相信排期。上接原则147，相信排期就是保持排期的严肃性，设定了就必须完成。排期如果是合理的，相应人员是认可的，那我们必须相信它，而且要严格要求和监控它。 原则167：管理偏差。 项目管理就是在管理偏差，无论是对项目控制还是对外报告，问题的着眼点都应放在偏差上。进度、成本、质量的偏差自不必说，在某种程度上，沟通不顺畅，对风险预估的不准确，都是一种偏差，是一种客观现实或者主观期望上的偏差。 ◆产品保证原则 原则176：组织配置管理独立于项目管理。 配置管理是个比较繁琐和需要细致操作的工作，这也就意味着它是耗时的。很多时候，配置工作做的不好都是因为屈服了其他项目指标，比如项目经理要求当天对外发布一个版本，版本发布也许是可行的，但配置工作不一定能完成，如果配置管理员是项目组的一部分，那配置工作必然会有所让步。所以，如果配置工作可以独立于项目管理，不受项目经理的控制，是可以起到第三方的质量监控的作用的。 原则178：给所有中间产品一个名称和版本。 这个原则不单适用于配置管理，日常的项目工作中所有的文件都应该有版本号的概念，最简单的版本号就是日期，比如20231229，如果当天有多次更新可以用20231229a，20231229b等。这是一种好的习惯，对于自己和对方管理文件都有好处。 原则179：控制基线 过CCB的目的是决定是否执行式样变更，如果执行了就会修改式样和代码等一些列内容，也就是导致了基线的变更。 原则180：保存所有内容。 说白了就是所有的东西都要有记录，特别是对外的东西，比如，设计考虑/针对修改内容的测试Case和测试结果/针对影响范围的测试Case和测试结果等。那一天出了问题需要追溯或者挖坟的时候，可以拿出这些东西确认哪个环节出了问题，是设计考虑不健全，还是测试Case不足，甚至是没有测试，这些东西对于内部反省和防止问题再次发生很有作用。 ◆演变原则 原则195：维护阶段比开发阶段产生的错误更多。 维护阶段意味着项目已经量产，用我们总经理的话来说，量产后所有的动作都像是悬崖边跳舞。维护阶段的错误不一定更多，但是如果发生，一定比开发阶段更严重，所以维护阶段的所有变更一定要更严格的控制，开发阶段执行的流程一点都不能省略，甚至要更严格，也应该更加切实的执行。 原则196：每次变更后都要进行回归测试。 回归测试被定义为一种软件测试，以确认程序或代码更改没有对现有功能产生不利影响。针对修改部分做验证是必须的，但是我们通常无法肯定改动不会对其他功能产生影响，所以回归测试也是必须的。 这本书英文版出版与1995年，距今28年，而其中绝大部分原则现在依然适用。忘了第几个原则了，书中说要对硬件的发展保持乐观，对软件的发展保持悲观，我想时间给了这两条原则充分的佐证。