diff --git "a/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\347\241\256\344\277\235\345\274\200\346\272\220\344\273\243\347\240\201\350\264\250\351\207\217\347\232\204\345\207\240\344\270\252\350\246\201\347\202\271.md" "b/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\347\241\256\344\277\235\345\274\200\346\272\220\344\273\243\347\240\201\350\264\250\351\207\217\347\232\204\345\207\240\344\270\252\350\246\201\347\202\271.md" index a64aefe930841591e7929257dc4951ba99815972..86f39a271f4233337814c180a50d93a915e63f62 100644 --- "a/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\347\241\256\344\277\235\345\274\200\346\272\220\344\273\243\347\240\201\350\264\250\351\207\217\347\232\204\345\207\240\344\270\252\350\246\201\347\202\271.md" +++ "b/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\347\241\256\344\277\235\345\274\200\346\272\220\344\273\243\347\240\201\350\264\250\351\207\217\347\232\204\345\207\240\344\270\252\350\246\201\347\202\271.md" @@ -1,47 +1,85 @@ +# 确保开源代码质量的几个要点 + > 本篇内容将会引导大家思考一些治理开源项目中，代码质量的问题 ## 引子 -2014 年 4 月，OpenSSL 向外界公布 OpenSSL 的实现上，存在 Heartbleed 漏洞隐患，截止 2014 年 5 月 20 日，在 80 万最热门的启用 TLS 的网站中，仍有 1.5％ 易受心脏出血漏洞的攻击。如果说 Heartbleed 带来了什么好处，那就是它让人们更加关注软件测试的重要性。它影响了 50 多万个网站。因此，专家们现在正在梳理 OpenSSL 的代码，以及许多其他开源项目的代码，以确保提高公开源代码的质量和安全性 +2014 年 4 月，OpenSSL 向外界公布 OpenSSL 的实现上，存在 Heartbleed 漏洞隐患，截止 2014 年 5 月 20 日，在 80 万最热门的启用 TLS 的网站中，仍有 1.5％ 易受心脏出血漏洞的攻击。如果说 Heartbleed 带来了什么好处，那就是它让人们更加关注软件测试的重要性。它影响了 50 多万个网站。因此，专家们现在正在梳理 OpenSSL 的代码，以及许多其他开源项目的代码，以确保提高公开源代码的质量和安全性。 + +基于贡献代码构建的事实是，没有任何一个开源项目是完全不可破解的。正如世界上没有“银弹”一样，开源社区也没有完美的开源代码。我们要能够容忍开源代码有缺陷，但容忍不代表对其放任自由，不做约束。低质量的开源代码是放在路边的“潘多拉魔盒”，会对开源代码的众多追随者造成巨大的影响！因此，我们需要通过一系列的措施，确保开源代码质量。 + +## 质量衡量标准 + +如何衡量代码质量？维护好大家编写代码就可以了吗？答案当然是否定的。确保开源代码质量，不仅仅需要维护和保证代码质量，而是要保障整体项目的质量。 + +那么我们如何管理和衡量项目质量呢？我们可以参考软件质量的衡量标准，来进行开源项目的管理。 + +软件质量的主要衡量标准如下（想要获得更多信息，请参考资料）： -基于贡献代码构建的事实是，没有任何一个开源项目是完全不可破解的。然而，有四个关键的要点，开发社区可以采取行动，以确保项目是最新的，并检测出潜在的缺陷。 +- 功能性：当软件在指定条件下使用时，软件产品提供满足明确和隐含要求的功能的能力 +- 可靠性：在指定条件使用时，软件产品维护规定的性能级别的能力 -``` -本篇需要重点补充软件质量管理的内容，从技术和工具角度来给与建议 -``` +- 易用性：在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力 +- 效率性：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力 +- 维护性：软件产品可被修改的能力。包括纠正、改进或对环境、需求和功能规格说明变化的适应 -## 人才 +- 移植性：软件产品从一种环境迁移到另外一种环境的能力 -首先，重要的是要知道谁在操作代码。随着开源社区变得如此多样化，有许多不同的工作风格。因此，需要有人拥有每个项目并提供架构审查。 +## 管理周期与内容 -通常，会有一个项目维护者(个人、团体或组织)支持一个开源项目，也会有一些贡献者在此基础上构建项目。在很大程度上，开源项目也是建立在逐渐信任的基础上。因此，在项目中寻找并维持人才是关键。 +对于一个项目来说，项目管理周期一般按照迭代周期管理，开源项目也是如此。 -虽然在开源社区中有可能存在不良行为者，但确实很少有项目维护者能够审查贡献者编写的每一行代码。这就是像 GitHub 和 CodePlex 这样的网站更容易审查贡献者和审查他们的项目工作的地方。 +一个项目的迭代周期主要包括：调研、需求、设计、开发、测试、部署、运维等阶段。不同的阶段，管理的内容不同，管理的方式也有所不同。 -同样，像 Linux 基金会和 Apache 软件基金会这样的组织已经联系了来自不同公司的专家开发人员，以帮助培养高质量的开源代码。 +各个阶段需要管理的内容如下： -## 时间 +- 调研：明确任务目标，确定任务方向，主要以市场调研、可行性分析、会议讨论等方式进行 +- 需求：完成需求采集，需求分析整理，主要以需求拆解、会议讨论、输出文档等方式进行 +- 设计：完成产品设计、概要设计、详细设计、数据库设计，主要以设计评审、输出文档等方式进行 +- 开发：完成功能实现，主要以制定代码规范、实现功能、代码审查等方式进行 +- 测试：完成功能测试、性能测试、安全性测试，主要以制定测试用例、输出测试报告等方式进行 +- 部署：完成项目的部署（一般开源项目没有该步骤，如果有，可能仅限于项目使用者） +- 运维：后期项目运维保障（一般开源项目没有该步骤，如果有，可能仅限于项目使用者） -有了合适的人才，开源社区还必须找到时间定期检查代码，并进一步分配时间来更新它。未能及时更新是部署中存在易受攻击软件的主要原因。 +**当然，以上只是项目的常见阶段，不必照本宣科，可根据项目实际情况选择性管理。** -## 预算 +## 管理方式与方法 -除了时间，开放源码项目，开源基金会的支持，如 Linux 基金会的作用与 Linux 和 Apache Hadoop 的角色，往往会有更大的能力和策略来确保代码质量，特别是有一个分配的预算项目，在某些情况下，开发人员为他们的贡献得到报酬，像 RedHat Linux 或 Cloudera Apache Hadoop。 +开源项目的管理方式和方法，用一个词来形容，那就是“百家争鸣”。因为每个项目所处的阶段不同，管理重点不同，甚至是成员性格不同，所以也就出现了各式各样的方式和方法。没有最好的管理方式，只有最适合的管理方式。 -如果一个开源项目没有商业支持，这并不一定意味着它不可能成功。像 Red Hat 和 Apache 这样的商业实体可以帮助解决服务器、事件和技术开发方面的预算问题，独立的开源开发人员可能无法轻松获得这些资源。 +在管理周期和内容中，其实已经涉及一部分管理方式和方法。这里，我们列举多个维度的方式方法供大家参考。 -## 工具 +- 会议沟通 + - 适用于全部阶段，重要事项及问题的讨论与决策 + - 小技巧 + - 控制议题数量，明确重点议题 + - 将大议题切分为小议题，避免冗长的会议 +- 文档输出 + - 适用于所有阶段，细节讨论的落实 + - 小技巧 + - 口述的内容要落实到纸面上，用来指导项目迭代，可作为后期项目复盘的依据，也有助于降低人员变动带来的风险 +- 制定代码规范 + - 适用于开发阶段，统一编码规范 + - 大部分开源项目都会提供编码规范，包括编码规范、日志规范、注释规范、数据库规范等等。比如：提供不同IDE的开发规范配置文件“***.xml”，又或者安装开发规范插件……等等 +- 代码review + - 适用于开发阶段，对照软件质量衡量标准进行完善项目 +- 合理利用工具 + - 适用于所有阶段，巧用工具提升效率 + - 比如：使用JIRA进行项目管理，使用Axure绘制原型，使用Word编写文档，使用GitHub 平台进行代码开发，使用Selenium进行功能测试，使用FindBugs 在 Java 查找缺陷，使用Clang 静态分析器分析C、C++ 和 Objective-C 程序中的错误。 +- 其他方式 + - 引入人才 + - 适用于所有阶段，借助组织的力量提升项目 + - 像 Linux 基金会和 Apache 软件基金会这样的组织已经联系了来自不同公司的专家开发人员，以帮助培养高质量的开源代码 + - 设置报酬 + - 适用于所有阶段，通过报酬机制，激励参与者保证开发智力 + - 开放源码项目，开源基金会的支持，如 Linux 基金会的作用与 Linux 和 ApacheHadoop 的角色，往往会有更大的能力和策略来确保代码质量，特别是有一个分配的预算项目，在某些情况下，开发人员为他们的贡献得到报酬，像 RedHatLinux 或 Cloudera Apache Hadoop。 -但是，即使有经验丰富的贡献者，我们也必须承认，人类还是容易犯错的。这包括可以在代码中编写无意缺陷的开发人员，如果漏洞未被发现，那么基于该漏洞构建的站点和软件就会变得脆弱。 +## 参考资料 -对于开放源代码项目来说，好消息是有许多免费工具可以确保代码的完整性，并且可以在开放源代码中找到许多漏洞和缺陷。 -对于代码开发，GitHub 平台是非常有用的。对于功能测试，Selenium 等工具也是如此。 -在静态分析中，FindBugs 是一个在 Java 中查找错误的开放源码工具。 -类似地，Clang 静态分析器是一个源代码分析工具，它可以发现 C、C++ 和 Objective-C 程序中的错误。 +- [做软件质量管理需要方面的知识，度量要如何开展？](https://www.zhihu.com/question/20825147) -项目维护者和组织可以知道是否已修复缺陷的另一种方法是注册观察已注册 Coverage Scan 服务的大约 2500 个开源项目中的一个，该项目最初是与美国国土部合作创建的现在可以为开源开发人员提供免费代码分析的安全性。 +- [质量特性及子特性：功能性、可靠性、易用性、效率、维护性、可移植性](http://www.cnitpm.com/pm/6274.html) -项目观察员可以查看关于项目质量的高级统计数据，包括固定缺陷的数量、突出缺陷和缺陷密度率——所有这些都支持开源社区在他们的软件开发过程中构建质量和安全性。 \ No newline at end of file