对于一家以软件研究作为核心竞争优势的公司，除了工程技术的持续推进之外，如何在软件开发过程中，提高开发效率并且保证软件质量，可以说是相当严峻的挑战。

        Synology NAS的核心作业系统DiskStation Manager（DSM），就是一个亿级代码行大型软件开发的典型案例。以最近的两个DSM版本，DSM 6.2.4与DSM 7.0更新来看，两版之间的代码有近千万行的差别，为了应对日益增长的软件规模和复杂度，我们花费了更多的人力、时间在 DSM 7.0 的研发上，这两年来公司内部有超过 200 名 RD 进行开发、组建了 700 多个不同的专长小组，都是为了让DSM 7.0成为一个更加千锤百炼的系统，进一步应对更加严苛的IT环境。

什么是软件质量？浅谈 Synology 的产品开发架构

        要打造一套稳定、流畅的操作系统，需要许多严谨的步骤，而要如何在整个产品开发的流程中确保软件质量更是至关重要。首先，我们先来了解Synology在整个产品开发的流程中，主要有哪三个主要环节。

        第一个阶段，产品设计（Product Design）。这个阶段需要跨部门合作，RD、PM、Support、QC等相关部门会一同确认架构设计与规格。此外，包括安全性问题，也会在产品设计时一并考察进去。Synology的安全应变小组（SIRT，Security Incident Response Team）也会在这个阶段协助安全方面的架构设计，在产品开发初期即做到Security by Design / Default的源头管理。

        第二个阶段，产品研发（Develop）。通过使用静态分析工具（SAST）、编译失败预防机制（Build fail prevention）与持续整合（Continuous Integration），得以确保整个软件开发环节的质量。此外，我们也藉由Code Review，让RD彼此检视代码中是否有自己没有办法观察出的盲区并进而改善。

        第三个阶段，验收测试（Acceptance Test）。在此阶段进行针对DSM系统以及各套件不同的性能与压力测试方式。

        而在第二个产品研发阶段，是以工程的角度来看与软件质量最直接相关的环节。以下我们会专注谈，在DSM 7.0的产品研发阶段，主要通过解决了哪三个问题来提升软件质量。

        （Synology在产品研发流程中，通过解决软件编译，通过自动化工具找出缺陷以及执行性能验证来提升产品品质。）

为了让您的产品更好，我们做了哪三件事？

        第一，是解决软件编译失败的问题。

        软件编译是将代码转变成机器码的过程。在这个过程中，如果发生了代码因为某些原因（例如语法错误等）无法正确转换成机器码，则会发生编译错误。一旦发生软件编译错误，就必须回头修复后再度提交代码，影响到的会是所有与项目相关的工程人员。

        DSM套件是由700多个不同项目组合而成的复杂操作系统，由Synology内部超过200名全职RD协作进行开发，也因为人数众多，导致项目的变动次数相当可观，而大量项目之间的依赖关系，更进一步提升了编译失败的可能性。

        我们可以简单的计算一下编译失败所花费的时间成本：如果每次编译失败，得面临最少将近半天（一次编译时间以4.5小时来计算）的工作时间停摆，所有相关的项目人员（RD & QA）以200人计，那么每次编译失败所造成的时间成本就等于：「RD & QA数量*修复为止的耗时*」，整体耗费的成本相当惊人。因此，提升编译的成功率在推动项目进行可说是扮演关键性角色。

        为了防止编译失败，我们于是自行开发了代号为「甘道夫（Gandolf）」的系统，这个系统可以确保我们在任一项目签入（Commit）的时候，执行所有依赖项目的完整编译和单元测试，如此一来，就可以在签入阶段为编译错误以及单元测试的错误做把关，造成编译错误的代码就不会进一步进入到我们的储存库（Repository）中，直接降低了编译失败的可能性。

        过去我们一年平均每天执行甘道夫系统31次，一年总计执行了一万次，平均降低6.73%的编译失败率。以节省的成本来计算，就是200（RD & QA数量）* 4.5 * 200（4.5小时工作时间* 200个工作天）* 6.73 = 13325hr，总计为我们节省了超过一万个小时的开发时间，大幅提升开发效率，并降低沟通成本。

        第二，是自动发现缺陷（Defects）。

        首先先解释一下，随着系统的规模、复杂度不断成长，所谓的功能性弱点、漏洞（Bug），这些我们可以通称为缺陷（Defects）的项目，也会在正常情况下出现，且数量会越来越多。因此，通过使用静态分析工具（SAST）等自动化测试工具，可以协助我们提前找出各种缺陷跟安全性问题，并在每版更新发布之前，review完所有的缺陷并做相对应的调整。

        通过自动化测试工具，我们能定时且有规律扫出安全性问题与bugs，自动预防潜在的安全漏洞和Bug，更好且更有效率的把关安全性，且发布更新前，从源头就优先改善缺陷，也让研发人员可以将心力投注在更具价值的测试项目上。

        回到Synology的产品政策，随着Synology的使用者逐步从家用使用者成长到企业市场，我们在大概7年前即开始采用自动化测试工具，并在DSM 7.0上，导入更多不同的编码规范（Coding Standard）如CERT、MISRA等，为企业用户提供更佳的软件质量。

        （执行自动化全平台性能验证，协助提升Synology NAS的传输表现，满足对于服务器性能有高度要求的企业与使用者。）

        第三、执行自动化全平台性能验证

        从用户的角度来看，除了产品的稳定性、安全性外，性能（Performance）也至关重要，因此我们也花了不少经历在性能的改进上。

        相较于安全性问题与Bug能够通过手动测试或是自动化工具来找出来，性能问题则是很难在产品开发端就察觉，这是由于软件的开发是有一层一层的层级的，每一层都有机会导致性能出现落差，必须回头重新审视构架找出根本原因（Root cause）所在。

        有些软件公司采取的作法，是只在年度性重大版本更新才验证性能，平常每月或每季的稳定性更新并没有加入性能追踪指标。但Synology相当重视性能表现，也不希望使用者在每一版升级时遇到性能与预期不符，甚至下降的问题，我们因此建立自动夹板测试机制，协助我们在研发阶段提早找出性能可能下降的瓶颈。

        自动夹板测试，意即我们会针对每一个内部版本都进行性能测试，并追踪性能测试的各项指标在各版本之间的差异，只要和原先预期的有落差，就会通知相关的工程人员进行即时处置。执行夹板测试最大的好处在于，每一版之间的变化不会太多，因此较易于追踪最有可能导致性能下降的原因，让问题可以被更频繁的检视。

        例如，过去在某次版本升级时，我们就曾因为升级某个Open source版本，导致重要的档案传输性能下降。当时归功于夹板测试保留了每一板的完整性能测试报告，让我们在第一时间即可缩小范围，在追踪后发现是Open source的预设参数调整导致的性能变化。如果没有夹板的完整测试报告，我们可能要耗费更多倍的时间才可以找出这个问题。

更好的质量与更高的效率

        通过改善软件编译失败的问题，用自动化工具找出缺陷，以及执行夹板测试追踪性能变化这三种方式，让Synology得以在大规模的软件开发项目中更好的掌握软件质量，也让整体开发流程更为顺畅。

        事实上，一套复杂的系统的练成相当不简单，但背后的核心理念其实相当一致：尽量在越早期的阶段发现问题，就能在相对短的时间内处理问题，再到解决问题，提升开发效率并节省成本。未来，我们也会持续建立审核软件质量的指标，并且标准化自动化测试流程，持续增加程序的稳定，提供Synology的使用者更好的产品服务。