作为Capital One的软件工程师，我为我们的商业银行开发了新的应用程序。我和我的团队最近以银行关系经理和分析师的网络应用程序的形式构建了一个数据管理工具。该团队包括两名软件工程师，四名数据分析师和科学家，以及一名产品经理。我们在原型设计的前五个月中进行了交叉协作，以定义满足用户分析需求的数据库模式。

在此期间，我的技术主管和我决定探索模式迁移工具，以便在我们设计数据库时简化开发。我们为数据库确定的是Flyway。 Flyway是一个开源数据库迁移工具，使开发人员能够将版本控制实践应用于他们的数据库。虽然我们查看了其他几个架构迁移工具，但这个工具似乎最适合我们的特定用例。

为什么我们需要架构迁移工具？

架构迁移和工具的好处

随着敏捷方法的发展并在21世纪初被广泛采用，对模式迁移工具的需求变得更大。允许数据库设计随着应用程序的发展而发展的技术允许工程师更有效地迭代软件。

在此期间，数据库迁移工具越来越受欢迎。架构迁移为数据库添加版本控制功能。迁移是逐步管理的，并且是可逆的。 Flyway等工具可以在处理多个环境（例如dev，test和prod）或切换分支时阻止数据库模式不匹配。它们允许开发人员从头开始重新创建数据库，这在创建新环境时很有用。迁移工具可确保应用程序将以数据库的当前状态运行。例如，这可以防止开发人员遇到列未找到错误。

Flyway概述

Flyway对数据库所做的更改称为迁移。在Flyway中，迁移有两种类型;它们可以是版本化的也可以是可重复的，版本化是最常见的。

版本化迁移具有版本，描述和校验和，并且按顺序应用一次。可重复迁移具有描述和校验和，并在每次校验和更改时重新应用。当需要更改数据库的模式时，开发人员会添加SQL脚本，通常位于db / migrations目录中。

将Flyway指向数据库后，它开始扫描应用程序的文件系统以进行迁移。它第一次运行第一次迁移时，会创建一个名为schema_version的表，其中包含多个列，包括版本，描述，脚本和校验和。该表用于跟踪数据库的状态。迁移根据其版本号进行排序并按顺序执行。

应用每个迁移后，schema_version表会相应更新。每次Flyway扫描应用程序的文件系统进行迁移时，它都会查询schema_version表以查看数据库所处的版本，并相应地升级数据库。

可用但未应用的迁移称为挂起迁移。

我们的用例的优点

使用迁移工具的最大优点是，它确保始终使用数据库的匹配状态提供软件版本。这对我们的产品尤其重要，因为我们快速迭代并且需要能够快速，自信地部署功能以收集用户反馈。

将Flyway集成到现有项目中很简单，因为设置所需的配置很少。该过程中的最小步骤包括通过在配置文件conf / flyway.conf中指定url，username和password将工具指向数据库。

Flyway严格的迁移规则强制执行纪律，因此也是最佳实践。这可以类似于禁用git中的force push。严格的规则Flyway强制执行与在部署到环境后保持SQL文件不可变的做法一致。由于我们的团队致力于遵循最佳软件工程实践，因此Flyway适合我们的产品。

作为对数据库迁移工具缺乏经验的人，Flyway易于学习且易于使用。以增量方式捕获所有架构迁移。 API公开了六种基本方法 - 迁移，清理，信息，验证，基线和修复。 （您可以在此处了解有关这些命令的更多信息）。这些方法使我们的团队能够将Flyway集成到我们的CircleCI部署命令中。

最后，Flyway既灵活又强大 - 它只需几个简单的命令即可修改列名，并将数据从一列传输到另一列。

 

我们的用例的缺点

如前所述，Flyway在迁移文件更改方面非常严格。在签入之后更改迁移并不容易。更改文件的内容或名称可能会导致每台具有该文件先前版本的计算机上的迁移失败。

即使需要进行简单的更改（例如调整字段名称），通常也需要新的迁移脚本。作为我的技术主管和我快速迭代，我们发现自己每周都会添加Flyway Scripts。这导致我们的迁移文件夹中存在过多的文件。在我们的原型设计的前五个月中，我们的应用程序仅部署到开发环境中，几乎不需要在我们的应用程序中逐步保留微小的模式更改。

值得一提的是，可以编辑以前执行的迁移，但只有高级用户才能这样做，因为它需要更新schema_version表中的行以调整校验和值。

当团队成员在不同分支上并行工作时，版本号可能会发生冲突。有一些过程可以解决此问题，例如使用版本号的时间戳而不是整数，并设置选项outOfOfOrder = true。

撤消迁移（例如删除先前迁移中添加的列）可能会非常棘手，并且通常需要开发人员创建数据备份。

 

我们应用的结果

事后看来，如果我们稍后在应用程序和数据库设计成熟时将其集成，我的团队可以更好地利用Flyway。为了在原型设计的第一阶段实现快速迭代，我认为我们的双人工程团队只需要一个定义初始模式的SQL文件，一个模拟数据文件和一个用于加载我们的表的脚本就足够了。模拟数据集。

使用这种方法，我们可以通过修改git分支中的初始模式和模拟数据文件来更改模式。在每次合并以构建或部署到环境之后，通过CircleCI启动的步骤，数据库将使用模式和模拟数据集进行转储，拆除，重新创建和重新加载。我认为Flyway可以最好地应用于存在多个环境的应用程序中，并且围绕数据库更改的决策的波动性较小。

Flyway是一种有价值的工具，许多优点都超过了它们的缺点。在我们的产品开发过程中，它确保我们的应用程序始终以数据库的匹配状态运行。从我们的主分支中提取更改时，遇到数据库不匹配错误的风险几乎为零。我们的迁移文件夹也是历史记录;我们的团队能够跟踪我们的数据库设计随时间的变化。

作为我的技术主管，我与我们团队的数据科学家合作，提供数据库状态的透明度是关键。在我们的CICD平台的帮助下，每次迁移的部署导致我们几乎没有停机时间。

Flyway是我使用迁移工具的第一次经历，它被证明可以有效地管理数据库的状态。如果在正确的阶段集成到应用程序中，它有可能更加强大。

 

原文 : https://medium.com/capital-one-tech/database-migrations-with-flyway-16b6478e55a6

 

在过去的四年中，我们一直在使用Flyway在大型客户端项目中迁移我们的数据库。该项目涉及多个站点的100多人。随着时间的推移，应用程序和数据迅速增长。因此，数据库必须发展以应对应用程序的更改。我们在临时环境中迁移数据库时遇到了一些挑战。在这篇博文中，我想分享我们如何使用Flyway迁移数据库。

使用Flyway进行数据库迁移

以代码开发迁移脚本

作为启动，我们在一组JPA实体中定义域模型。我们还使用JPA注释来约束不可为空的数据类型max。然后我们使用JPA mapping-tool生成与JPA实体对应的DDL，并使用DDL设置初始数据库。这组DDL与源代码一起被检入Git存储库。当开发人员对数据库进行更改时，他必须再次生成DDL，然后创建对数据库的更改集。他可以看到Git中当前DDL与之前DDL之间差异的变化。根据差异，开发人员为数据库迁移创建了一些脚本。脚本还迁移数据库模式和现有数据。

我们在scrum中开发并在sprint结束时提供发布包（我将其命名为增量）。下图说明了不同增量的脚本。

Database migration scripts in different versions

当sprint结束时，我们的jenkins发布版本将Flyway脚本打包到新版本包中。 通常，脚本放在我们讨论过并与DevOps达成一致的目录中。 DevOps将Flyway配置为在预定义目录中扫描。 在部署新应用程序之前，他们运行Flyway来执行找到的脚本。 通过这种方式，数据库迁移以受控方式工作。

 

我们使用Flyway迁移数据库的工作流程

我们有一个经典的分期流程来促进我们增加到PROD（生产）阶段。 下图是从DEV到PROD的开发过程的简化版本。 如图所示，我们有三个阶段，DEV，TEST和PROD。

 

 

The promotion of increment from Local to PROD

在sprint结束时，我们将新增量提供给最低测试环境（DEV）。 DevOps接收传递并在DEV上部署增量以进行测试。 如果测试并批准了此增量，那么他们会将其部署到TEST。 我们不会等待外出增量的测试结果，而是继续开发新版本，然后在下一个sprint中提供它。 如果在暂存环境中通过测试找到问题，我们将在同一个git分支中修复它。 根据修复，我们构建一个新的增量，并将其作为修补程序提供给同一个阶段。

使用Flyway架构历史诊断数据库

完成Flyway迁移后，我们可以在架构历史记录表中看到更改历史记录。 模式历史记录记录执行的Flyway脚本的所有重要信息。 下图显示了环境DEV，TEST和PROD的简化模式历史记录。

Flyway Schema History

 

当您获得一个损坏的数据库并且您应该修复它时，架构历史记录中的信息可能非常有用。由于我们使用Flyway自动化数据库迁移，因此我们可以轻松找出数据库发生的情况和时间，然后快速识别不规则性。有时，如果在环境中部署了先前的修补程序，则可能会很棘手，因为架构历史记录包含额外的修补程序脚本。在下一节中，我将解释修补程序迁移的处理方法。

Flyway的修补程序

我们不时会在某个临时环境中发现问题。如上所述，我们通过修补程序修复问题。我们遇到了修补程序开发中的一些挑战。例如，一个挑战是以正确的时间顺序保持每个阶段环境的数据库模式历史。

通常，我们开始在最高阶段修复问题，然后尝试将数据库更改填充到其他分段环境。我们使用一些技术转换脚本以避免重复执行的副作用。

 

首先修复问题环境

通常，如果舞台环境中出现问题，我们会在同一个git分支上解决该问题，然后将修补程序提供给该环境。这对我们来说是最简单，最省时的方式。

假设我们在版本7的PROD上检测到数据库相关问题，那么我们使用包含一些脚本的修补程序v7.1来处理它。当版本8的应用程序增量到达PROD时，Flyway可以识别出v8中的脚本版本高于PROD上的版本7.1并且在v7.1之上执行v8的脚本。对于Flyway来说，脚本版本应该始终是升序而不是降序。

Hotfix v7.1 is deployed on PROD

 

将Flyway脚本从修补程序合并回主流

在部署了修补程序v7.1之后，我们在PROD上完成了数据库更改，这在DEV和TEST上是不存在的。 我们如何使DEV和TEST DB与PROD保持一致？ 简短的回答是将v7.1中的脚本合并回主流。

Merge Flyway scripts from hotfix back to main stream

 

上图显示了从修补程序v7.1到主流（v10）的合并。乍一看似乎很简单，因为我们可以挑选修补程序提交并将脚本移动到主流中。实际上，简单的复制粘贴不起作用，因为Flyway只在最高版本之上执行脚本。我们可以回想一下，TEST中数据库模式历史记录中的最高版本是版本8和DEV版本9.Mayway会注意到v7.1脚本的版本低于v8或v9，因此在DEV和TEST上都忽略它们。同样，Flyway的默认行为是按升序执行脚本。

现在让我解释一下我们如何合并脚本。

• 首先，我们将修补程序中的脚本合并到具有更高版本号的开发分支
• 其次，我们重写脚本，使它们可重新运行并具有幂等性。具体来说，合并的脚本能够发现是否在数据库上完成了相同的操作，然后相应地跳过它们自己。当新的增量随后部署在PROD上时，这些“新”脚本将自行跳过，因为之前已经部署了修补程序。

零停机时间使用Flyway迁移数据库

由于我们的应用程序是24×7在线，因此不允许在生产环境中停机。这意味着当我们迁移数据库时，应用程序必须保持活动状态。

 

蓝绿色部署零停机时间

我们遵循的策略是所谓的蓝绿色部署。也就是说我们在每个阶段同时维护2台服务器。下图描述了蓝绿部署的工作原理。如图所示，两台服务器共享一个数据库。

 

Blue green deployment before and after

 

在部署之前，路由器将请求重新路由到具有较新版本的蓝色服务器，而具有旧版本的绿色服务器则作为备份。当新版本发布并交付到此阶段时，我们将新版本部署到绿色服务器。我们通常在部署之前迁移数据库。

在数据库上迁移并且绿色服务器上的部署完成后，我们将请求重新路由到绿色服务器。然后，此服务器开始主动提供请求，我们现在将其称为活动服务器。下次将另一个新版本发送到此阶段时，它将部署到蓝色服务器。我们一遍又一遍地重复相同的过程。

两阶段数据库迁移，以支持蓝色和绿色服务器

由于我们让蓝色和绿色服务器共享数据库，因此该数据库必须在每次迁移后支持两个服务器。这样，如果新部署的版本无效，我们可以切换回旧版本的服务器。我们对此用例应用了所谓的两阶段迁移技术。例如，假设我们要从表USER中删除列PHONE。下图说明了我们的工作：

在第一阶段，我们删除了应用程序v6中对列的引用。没有架构更改。由v6插入的记录不包含colum PHONE的值。如果我们需要切换回v5，我们会创建一个触发器，它会使PHONE列填充一些值。因此，带有v5的服务器仍然可以使用新插入的数据。

在第二阶段，我们从表USER中删除列PHONE。数据库架构更改。但它完全没问题，因为两个服务器（v7和v8）都没有列的引用。

2 phase database migration

 

具有零停机时间要求的迁移结果

• 蓝色和绿色服务器在每个阶段共享一个数据库，而此数据库随时支持两个服务器。
• 我们总是有一台主动服务请求的服务器，另一台服务器待命。
• 如果新应用程序失败，我们可以将被动服务器重新联机。但我们不撤消数据库迁移。

环境特定数据库迁移

通常，我们使用相同的迁移脚本在每个环境中设置数据库。有时，这将无法正常工作，而数据库表的某些配置因环境而异。例如，我们在表CUSTOMER中有一个LOCALE列用于语言首选项。然后我们使用该列的默认值“EN”编写初始迁移脚本，这对于西方国家的环境是正确的。但对于欧洲以外的环境来说并非总是如此。在中国等非英语国家的环境中，该列的默认值应为“CN”。困境在于设计脚本以便在环境与环境之间以不同的方式工作将是一种过度的做法。

幸运的是，Flyway可以选择这种情况。我们将原始脚本复制到不同的目录中并根据目标位置进行调整，然后在中国环境中配置Flyway以在此目录中扫描脚本。这样，该目录中的迁移脚本可以根据环境正确设置LOCALE列。

此环境特定目录的解决方案使Flyway能够解析数据库模式中的本地依赖关系。但是，这种方法应该谨慎使用，因为它可能导致不同环境中的不同模式历史记录，并且模式历史记录的差异将使数据库分析变得复杂。

 

使用Flyway迁移大表

生产数据库中的一些表包含数千万条记录。那些大表使迁移比我们预期的更复杂。简而言之，迁移大型表需要更长的时间。由于每个Flyway脚本都在事务中运行，因此我们需要更大的磁盘空间来启用回滚。当我们迁移大型表时，阻止了其他访问（从应用程序）到大型表。在最坏的情况下，访问在迁移完成之前达到超时并失败。

 

迁移大表的数据

在实践中，我们将在迁移数据之前分析大表。我们总是在真实PROD数据库的副本上组织测试运行，以查看迁移需要多长时间。如果迁移到一个大型表是一个长时间运行的过程，比如超过30秒，我们只需将该脚本从Flyway中取出，进行优化并手动执行。此外，我们必须应用分而治之的原则。那就是将数据分成适当的部分，然后在提交中迁移每个部分。我们将阈值定义为30秒，因为应用程序事务在30秒后超时。

 

迁移大表的模式

触摸大桌子有点可怕，因为你害怕受到伤害。但是，我们必须更改架构，否则它无法支持应用程序更改。如果更改是数据库上的REORG挂起操作，那么我们必须对该表执行REORG。没有DBA会在PROD数据库的大表上批准这样的REORG，因为它将完全阻止对表的访问很长时间，这违反了零停机时间策略。

目前，我们正在实践一个概念来解决这个问题。我们所做的是将大表重命名为USER to USER_OLD，然后立即创建一个具有相同名称和我们想要的正确模式的新空表USER。之后，我们将旧数据从表USER_OLD递增传输到新表USER。诀窍是我们必须在单个事务中进行重命名和创建。这样就可以优雅地完成模式迁移，应用程序甚至不会注意到表已经更改。

 

总结

Flyway帮助我们以可控的方式管理所有临时环境中的复杂数据库迁移。我们开发迁移脚本并将其包含在交付包中。然后，DevOps负责暂存环境中的其余部分。虽然我们仍然需要与DBA密切合作，但开发人员不再需要负担数据库迁移的负担。如果出现数据库问题，则Flyway架构历史记录是检查数据库状态的便捷工具。

除了与Flyway的例行数据库迁移之外，由于我们项目中的挑战，以下几点是调整。

• 合并的修补程序脚本必须是幂等的，同时将修补程序合并回主流。
• 我们应用蓝绿部署和两阶段数据库迁移，以便应用程序具有零停机时间。
• 分别迁移大表

 

原文:https://www.novatec-gmbh.de/en/blog/database-migration-flyway-large-project/

本文：http://jiagoushi.pro/database-migration-flyway-large-project

讨论：请加入知识星球或者微信圈子【首席架构师圈】

 

性能测试和工程通常被认为是纯粹的技术问题。然而，根据我们在许多不同行业和组织中的经验，关键非技术角色的人员可以对最终产品的性能和交付团队的理智产生最大的影响。

转移性能（进一步）

许多系统质量问题（包括性能）可以追溯到交付项目生命周期早期的重大决策。这种理解正在推动整个行业的左转趋势 - 在生命周期的早期推动质量活动。

不幸的是，Performance Engineering中的左移通常会停止在开发人员身上。开发团队与测试人员和运营团队密切合作，尽早调整和缓解性能问题。但我们需要更进一步 - 回到产品负责人认为“哎呀，我敢打赌我们的客户会喜欢功能X，让我们为此做一个商业案例”。从那时起，每个人都应该在计划和做出决策时开始考虑性能。

很多时候，从构思到开发（有时甚至是过去），功能性都是很酷的孩子。每个人都很容易对花哨的新功能X及其可以做的很酷的事情感到兴奋，并且简单地假设类似Google的速度和规模将免费提供。功能X获得批准，通过通常的分析和设计过程，开始开发。这通常留给那些必须成为坏消息的承担者的测试人员和开发人员，他们说，'嘿功能X非常棒，但如果超过5个人尝试同时使用它，则响应时间超过2分钟'。

在经历了所有的努力和兴奋之后，可怜的旧功能X已经从今年的英雄功能版本发布到了将项目烧毁到地面的性能垃圾火灾。最重要的是，现在你有：

愤怒的产品负责人甚至不知道这可能是一个问题

一个吓坏了的PM，他没有分配足够的时间或预算来调整性能问题

一个迷茫的BA在非功能性需求上做一个速成课程

一个沮丧的用户体验设计师认为这与他们无关

性能思维

通常关于这一点，我们的测试和优化专家会被召唤来帮助灭火。大多数时候，我们可以弄清楚如何使它全部工作和嗡嗡声，并实现产品负责人首先设想的功能X的潜力。但是，当每个人都有一个表现思维时，对于每个人来说，在考虑性能时，它会更加轻松（通常也会更便宜）。

拥有“表现心态”究竟意味着什么？它不是要成为性能调优专家。这意味着在接近您的日常任务时考虑性能和功能。

具体而言，产品负责人，PM，BA和UX设计师可以做些什么来帮助避免上述情况？以下是将伟大与单纯善良分开的一些关键行为。

产品所有者：

请记住，用户要求的性能与酷炫的新功能一样多，甚至更多。如果功能不执行，用户将讨厌功能X.

请注意，某些功能会导致性能折衷。尽早向您的工程师提供X特征X，以确定是否需要进行成本/收益分析。

考虑功能X将如何影响用户数量和行为。您期望有多少新用户？您是定位移动用户吗？他们会生活在农村地区，网络连接不稳定吗？

功能X将如何推出？随着大张旗鼓和公布的开始日期/时间？ （认为​​人口普查）。或者在无数天/小时或用户群中交错？

项目经理：

预算时间在开发冲刺/阶段内预先进行性能优化，而不仅仅是“必要时临时”。

在进入下一个sprint /阶段之前，确保性能标准是“完成定义”的必要部分。

通过采购和推动及时提供，确保您的团队装备精良，提前计划并节省浪费的时间

适合用途的性能测试环境。

充分的应用和基础设施性能监控。

数据依赖性和要求。

适当的凭据，许可证和访问权限。

 

业务分析师：

专注于实时和理解非功能性需求。了解它们是什么以及它们为何重要。在设计和开发之前准备好这些，以便工程师可以准确地估计广告，围绕他们的系统架构做出最佳选择。

研究详细的指标以告知详细要求。模糊的非功能性要求是非常无用的，例如“功能x应在3秒内响应”。目标是“功能x应在3秒内响应，同时在50,000个用户会话的持续负载下，每秒520个请求”。

熟悉与性能相关的多种信息来源。即使您无法自己捕获信息（例如原始日志数据），也要了解要查找的内容，并让其他人捕获它。

历史用法例如营销分析，应用程序性能监控，操作日志分析。

预测用量，例如产品所有者，业务案例，使用报告，财务预测。

UX设计师：

研究并了解前端性能的原理。

探索设计师通过巧妙地使用（或避免）诸如旋转器，启动页面，骨架图像/图标等内容来使应用程序“感觉”高效的方式。

考虑屏幕上元素数量对性能的影响。

尽可能减少图像文件的大小

使用巧妙的设计吸引注意页面/功能的关键部分，而背景或屏幕外元素可以继续加载而不被注意。

使命

我们作为测试和优化顾问的使命不仅仅是'测试x'或'让你快速'。这是为了使我们的专业知识尽可能有价值，这意味着帮助您首先避免这些性能火灾。有点像那部精彩的电影'Inception' - 如果你能早点进入并在所有利益相关者中灌输'表现心态'，那么每个人都会获胜。

有人说编程是一门科学，有些人说它是一门艺术，还有一些人认为它是两门艺术。无论哪个是真的，没有工程师提供的稳定的手和实际的重点，程序员只会给我们科学理论和大胆的艺术视野。得益于工程实践，我们拥有适合我们口袋的工作设备，只需轻点几下即可获得全世界的知识。

自从它是国家工程师周以来，唯一有意义的是庆祝工程学科如何使计算机变得可访问，必不可少，值得信赖和变革。我收集了自己的想法，甚至是一些个人经历​​，提出了五种必不可少的工程实践，这些实践总是落后于人类产生的最佳软件。当这些系统出现崩溃或故障时，故障可能不在于工程师，而在于喜怒无常的艺术家或云端科学家。

 

测试至关重要

每个程序员都知道进行黑客攻击是什么感觉，像机枪一样吐出一行代码。当你对这个架构有一个宏伟的愿景时，你永远不能把它变成代码。这就是米开朗基罗画西斯廷教堂时的感觉，但在一个72小时的延伸中。

虽然弯曲机的代码通常很棒，但它通常是毛茸茸的，并且在某些地方都没有完成。更糟糕的是，作者并不总是记得以后留下空隙的地方。对于所有代码的宏大艺术，它还没有准备好发货。我们将粗略的初稿转化为完成的代码的方式是使用顶级应用程序安全测试工具之一进行严格的严格测试。

在过去的十年中，测试变得比以往任何时候都更好，因为开发团队已经创建了强大的协议并构建了自动化功能来实施它们。团队正在使用新的持续集成机制，它们接受我们的代码并在我们检查后立即开始戳戳和刺激它。只要我们构建良好的单元测试 - 这是它自己的挑战类型 - 测试自动化机器人将确保我们的代码向前推进。如果我们犯错误，它会抓住它们并麻烦我们直到它们被修复。当我们的代码通过所有单元测试时，我们可以确定它不会失败 - 至少不是我们在编写测试时预期的方式。不能保证代码真正没有错误，但是测试严格确保我们得到了明显的代码。

 

存储库让我们修复我们的错误

你犯了多少次错误，并希望你能及时回过头来修复它？我们走了一条路，扯开代码并粘在新结构中，却发现这都是错误的。原始代码更好。

幸运的是，我们在编码过程中将工作提交给版本控制系统。良好的版本控制存储库（如CVS，Subversion和Git）可以实验代码并对其进行改进，而无需担心我们可能会朝错误的方向前进。存储库跟踪代码的演变，如果一切都是错误的话，让我们回过头来。

存储库还允许我们同步我们的项目工作，跟踪差异，并在时机成熟时将我们的工作与其他人合并。如果没有这种稳定，中立的服务来协同工作，团队会发现构建可靠的代码要困难得多，并且他们会害怕尝试新的功能。

 

开发方法很重要

大胆的心灵可能会跳入深渊，但是理性的头脑会形成一个战略性的计划，可以轻轻地下降到它的深处。如果没有仔细地将所有这些疯狂的直觉，直觉和梦想融合到一个理性的，完全规划的工作流程中，我们将无法构建大型或中型软件项目。

关于不同类型的编程方法存在持续的争论，其中许多方法相互对立。例如，有些人完全相信，如果没有敏捷方法的灵活性，就无法建立好的软件。然后还有其他人将敏捷抛到一边，因为它过于反复无常。就个人而言，我喜欢的敏捷过程有很多方面，但是当太多的程序员在牧场外游荡时，我发现它会误入歧途。

软件工程师一直在思考如何共同编写代码。他们尚未达成共识，但这并不意味着这些想法并非总比没有好。我们的野心如此之大，以至于我们需要数十人，如果不是数百人或数千人，他们一起工作，没有协调就会变得混乱。你可以选择你喜欢的任何一方 - 只要你选择一方。

代码必须继续存在

软件存在缺陷和局限性，但年龄不是其中之一。钢铁锈和有机材料破坏了，但软件的逻辑继续存在。正如我们所说的那样，IBM大型机运行COBOL代码，这些代码由从未长时间发送推文或在Facebook上发布状态更新的人编写。它们可能已经消失，但它们的代码依然存在。

应用程序仅在与当前系统不兼容或者当前软件产品中没有新功能和更新时才会出现与年龄相关的问题。只有代码维护才能使旧应用程序保持有用。

良好的代码维护从良好的工程开始。当团队使用模块化接口编写记录良好的代码时，他们的工作可以继续运行。软件工程使我们中的一部分人能够继续生活。这与将我们的灵魂下载到矩阵中的方式不同，但确实有相似之处。

代码分析

很久以前，我错误地对赖斯定理过于相信，赖斯定理是计算机科学的一个重要部分，它指出一个计算机程序无法分析另一个计算机程序并决定它是否具有一些非常重要的属性。而这个定理在最抽象的意义上意味着“非平凡”。如果某些程序的某些属性是真的而不是其他程序，那么它被认为是“非常重要的”。

该定理似乎表明，花费任何时间尝试编写寻找错误或发现错误的代码是徒劳的。但是这个定理实际上说机器智能不能一直正确地做到这一点。我假设没有代码可以查找错误并发现错误。

软件工程师并没有被深刻的理论结果所迷惑。他们知道编写可以扫描我们的代码并查找常见错误或不良实践的软件是可能的。好的工具可以查找诸如未初始化的变量和缓冲区溢出或SQL注入漏洞等更深层问题之类的草率错误。

这是良好工程的教训。它不需要是完美的。它不需要很深。它不需要令人惊讶。只需要勤勉而有条不紊地专注于正确性，就需要精心打造。这个过程可能永远不会纠正所有的错误，但这并不意味着我们不能乐于找到它们中的一些。如果重复这个过程，我们可以足够接近。

您认为什么是软件开发中最重要的工程实践？

原文：https://techbeacon.com/security/5-essential-software-engineering-practices

本文：http://pub.intelligentx.net/node/502

讨论：请加入知识星球和小红圈【首席架构师圈】

当您的软件团队快速增长时，确保代码质量是一个巨大的挑战。但是，即使有固定数量的软件开发人员，维护代码质量也会引起麻烦。

如果没有工具和一致的系统，整个项目可能积累巨大的技术债务，长期造成的问题比短期解决的问题要多。

最好的事情是，你不必成为一个火箭科学家来避免这一点（当然，如果你是火箭科学家的话，这不是问题）。

我们提供了一个很重的指南，帮助您从根本上提高团队生成的代码的质量，无论您是与内部团队还是软件外包公司合作。

这篇文章的某些部分可能看起来很明显，但其价值在于这些部分是如何连接起来并建立起一个有效的代码质量保证系统的。

• 代码质量到底是什么？
• 为什么要关心代码质量？
• 为您的团队构建代码质量保证体系
  • 确保代码质量和透明度的版本控制工具
  • 可读和可理解代码的样式指南
  • 通过功能测试提高代码质量
• 如何测量测试
• 用户界面测试
• 使用持续集成工具
• 后期代码质量
• 案例研究

代码质量到底是什么？

代码质量是一组不同的属性和需求，由您的业务决定和确定优先级。以下是可用于确定它的主要属性：

• 清晰：对于不是代码创建者的人来说，阅读和监督都很容易。如果很容易理解，那么维护和扩展代码就容易多了。不仅仅是计算机，人类也需要理解它。
• 可维护性：高质量的代码并不复杂。任何使用代码的人如果想做任何更改，都必须理解代码的整个上下文。
• 文档化：最好的事情是当代码是自解释的，但是总是建议在代码中添加注释来解释它的角色和功能。它使没有参与编写代码的人更容易理解和维护代码。
• 重构：代码格式需要一致，并遵循语言的编码约定。这里有一些代码重构技巧。
• 测试良好：代码的错误越少，质量就越高。彻底的测试会过滤掉关键的错误，确保软件按照预期的方式工作。
• 可扩展：你收到的代码必须是可扩展的。几周后你不得不扔掉它，这真的不太好。
• 效率：高质量的代码不会使用不必要的资源来执行所需的操作。

质量代码不一定满足上述所有属性，但满足的越多，质量就越高。这些需求更像是取决于项目特性的优先级列表。

 

为什么要关心代码质量？

伟大的作家写的书有引人入胜的故事，很容易阅读和理解。从某些方面来说，作者的工作类似于开发人员的工作。主要区别在于开发人员使用不同的行话。

由于作者的写作必须易于阅读和全面，所以软件开发人员的代码也应该如此。

我知道，当你在压力下不得不在下一个截止日期前完成工作时，很难关注代码质量，但是如果你想长远考虑，你肯定需要生成可读和可维护的代码。以下是代码质量重要的三个主要原因：

• 可读性：使代码更可读，更容易理解，为每个人在项目上工作。读和理解一个质量低劣的代码要比写它困难得多。
• 可维护性：维护和测试质量代码更容易、更安全、更省时。
• 较低的技术债务：高质量的代码可以加速长期的软件开发，因为它可以重用，开发人员不必花那么多时间修复旧的错误和抛光代码。它还使新的项目成员更容易加入项目。

质量代码是软件质量的基石，无论你从事什么行业，质量软件都能让你的生活更轻松。

Robertc对干净码的定义。马丁“鲍勃叔叔”

干净的代码可以让你快速工作

基本的主题是，如果你想走得快，满足时间表，让你的客户和经理高兴，保持你的代码尽可能干净。没有什么比保持工作区整洁和坚持高编码标准更能让您更快地构建软件了。

测量函数的大小

您可以测量方法或函数的大小。这本干净的代码书的很大一部分都围绕着这个想法。这很简单：把你的函数做得尽可能小。

一旦超过五行或六行代码，它们就开始变得太大。许多程序员发现小函数的想法令人不安。这对他们来说是新鲜事，他们担心这会压倒他们。

把你的功能命名好

但这不会让你不知所措，因为你需要说出他们的名字，这是一次让人大开眼界的经历。你必须想出一些小概念的名字。他们的名字往往很长，因为概念非常精确，所以需要几个词来描述。

所以函数的名字几乎都是句子。当你把它们和“if”和“while”语句混合在一起时，你就开始形成完整的句子。然后你的代码开始像自然语言一样阅读。

保持函数尽可能小，命名好就等于好的代码，保证了高的结构质量。

 

 

为您的团队构建代码质量保证体系

在这一部分中，我将向您展示如何使用版本控制、样式指南和自动化测试来确保我们的代码符合预定义的质量标准。

通过遵循这些方法，您可以轻松地复制我们的系统，并从根本上提高您的团队生成的代码质量。您只需执行以下步骤：

• 安装程序版本控制
• 确定惯例
• 运行功能质量测试

一。版本控制工具，确保代码质量和透明度

版本控制工具是我们系统的基础。

最流行的版本控制工具是Git。它还提供了一个分支样式的指南，称为GitFlow，它支持团队成员之间的无缝协作，并使扩展开发团队变得容易。

它提供了一个易于跟踪的系统，将活动产品与具有未发布特性的不太稳定的开发人员分支分离开来。

当我们团队的开发人员完成一个特性时，他/她会在GitHub上发送一个pull请求。这描述了请求的内容和详细信息。

此系统确保没有未查看的代码将与主分支合并。代码检查很重要，您需要正确的工具来完成它。

以下是我们的流程：

• 一个团队成员向开发分支发送一个pull请求。
• 这将出现在“准备审阅”部分中，等待项目成员审阅（同行审阅）。
• 团队成员审查请求，如果它满足需求，它将被合并到开发分支。

这是一个很好的控制版本和使每个人的工作完全透明的系统。Git有很多GUI扩展，比如支持Gitflow的GitKraken。在这里您可以看到如何轻松地启用它。

但是你如何决定代码是否足够好呢？

在下一部分中，我将向您展示跟踪代码质量的工具和可用于度量代码质量的度量。

1。可读和可理解代码的样式指南

 

 

样式指南是最佳实践和约定的集合。使用样式指南可以确保每个开发人员的代码看起来完全相同，从而使代码更易于检查和使用。

幸运的是，您不必创建自己的样式指南。有许多免费的样式指南，主要针对不同的编程语言和范围：

公司：像Airbnb和Google这样的酷公司已经创建并发布了他们自己的风格指南。这是Airbnb的JavaScript风格指南。

项目：公司内不同的项目或产品可能有不同的约定。我们并不推荐基于项目的风格指南，因为它使人们在项目之间切换变得更加困难。

使用linters自动测试代码样式

 linter 是款式指南的一部分。它是一个小软件，可以自动检查代码是否符合预定义的代码约定规则。您不必手动检查代码库来检查样式。

几乎每种编程语言都有linter，仅举几个例子：

• JavaScript ESLint
• TypeScript TSlint
• Python pylint /flake8
• Sass/SCSS sass-lint
• Go golang lint
• Bash ShellCheck

您也可以在这里查看我们自己的 JavaScript style guide here （尽管需要更新）。

许多代码编辑器都支持可配置的linting，例如VSCode。这里有一个如何设置自己的 linter的指南。

EditorConfig 帮助开发人员定义和维护不同编辑器和ide之间的一致编码样式。EditorConfig项目由一个用于定义编码样式的文件格式和一组文本编辑器插件组成，这些插件使编辑器能够读取文件格式并遵循定义的样式。

3。通过功能测试提高代码质量

当使用linter的样式指南测试代码的外观时，功能质量测试显示代码是否实际工作。

这个简单的金字塔显示了一个测试过程的结构和你的努力方向。

一般来说，我们可以说您必须运行大量的单元测试，更少的集成测试，甚至更少的端到端测试。

通过单元测试，您可以通过模拟依赖项来检查软件的一个模块。集成测试显示了在端到端测试检查整个客户机-服务器循环时，不同组件如何协同工作。

对于运行单元和集成测试，可以使用以下工具：

• Mocha
• Jasmine

对于端到端测试，我们建议使用：

• Jasmine
• Karma (for angular)

• Protractor
• Cucumber

附加阅读：Mobile Labs Inc在部署任何应用程序之前都会列出一个很酷的清单。

如何测量测试

衡量测试有效性的最佳方法是跟踪测试覆盖率。它显示了测试算法所覆盖的代码的百分比。为了更好地理解，有必要分解测试覆盖率：

• 语句覆盖率（%）：测试期间执行的语句数除以所有语句
• 分支覆盖率（%）：执行的条件数除以所有条件
• 函数覆盖率（%）：执行的函数数除以所有函数
• 行覆盖率（%）：测试期间运行的行数除以所有行数

Istanbul 尔是一个很酷的工具，用于测量JavaScript代码库的测试覆盖率。

用户界面测试

UI测试也可以自动化，但它需要更多的资源，特别是当组件正在更改时，因此应该重写完整的测试环境。

自动用户界面测试有很酷的应用程序：用于Android UI压力测试的Monkey测试、用于跨浏览器测试的Saucelabs和用于更全面的端到端测试（包括用户界面）的dragor。

• Monkey test for Android
• Saucelabs
• Protractor

使用持续集成工具

我们的理念是总是对我们正在构建的软件的状况有反馈。这就是图中的持续集成。我们最喜欢的博主之一，Martin Fowler，明确了持续集成的定义。

“持续集成是一种软件开发实践，在这种实践中，团队成员经常集成他们的工作，通常每个人至少每天集成一次，导致每天进行多个集成。每个集成都由自动化构建（包括测试）进行验证，以尽快检测集成错误。”

          马丁·福勒

以下是我们的流程：

1. 持续集成平台将在代码上运行linter。如果失败了，这个过程将在此停止，开发人员必须修复与样式相关的问题。
2. 如果代码按照计划运行，它将运行功能测试并转到下一步。
3. 然后开始计算测试覆盖率。如果它不符合预定义的阈值，它将失败。
4. 如果请求正在与主分支合并，那么也应该部署它。

推荐工具：

• Shippable
• TravisCI

后期代码质量

你真的不应该在产品上线后就放弃质量跟踪。诸如Sentry和Newrelic之类的工具可以实时监控错误，这样就不必要求用户报告崩溃和错误，因为系统会自动通知您。你只需要在你的应用程序中添加一小段代码。

工具：

• Sentry (can be integrated with Slack and GitHub)
• Newrelic

 

案例研究

艾伦·叶芝

首席技术官

袖珍手有限公司

“我们认为，尽可能避免技术债务是最好的办法。通过代码审查，确保代码标准得到遵守，避免黑客攻击，您可以及早发现许多问题。

很明显，有时在项目的最后期限和里程碑到来时，你无法避免增加技术债务。那么最好把所有的事情都记录下来。我们保留一份文件，其中列出了所有问题，它们在哪里，为什么要这样做，以及哪些可能的措施可以解决这些问题。这样我们就可以跟踪我们在哪里看到的问题，以及什么时候它在我们的脑海里是新鲜的。

当涉及到提高代码质量时，它会根据具体情况工作。有时候你不得不接受一些永远无法解决的问题，在解决的时候记住它。其他时候，它可以被安排到未来的sprint中，以便在下一次需要查看该功能时进行修复。”

结论

就这样。这就是您如何为您的团队创建一个工作流，确保每个人的代码遵循相同的样式指南，并通过预定义的测试来检查功能质量。

除了在发布前测试代码质量之外，您还需要监视用户开始使用应用程序时发生的情况。

我们知道编写没有bug的代码是不可能的，但是遵循上面提到的过程肯定会提高团队代码的质量。

 

原文：https://codingsans.com/blog/code-quality

本文：http://jiagoushi.pro/comprehensive-guide-code-quality-best-practices-and-tools

讨论：请加入知识星球【首席架构师圈】或者微信圈子【首席架构师圈】

 

从 2021 年顶级明星 Github 存储库中了解技术趋势、人口统计和开发者文化

动机、方法和热门领域

动机：Github 是世界上最大的源代码托管商，拥有超过 2.54 亿个存储库（根据 x-lab 报告，2020 年至少有 5200 万个公共存储库）。 除了源代码之外，Github 已成为全球超过 7300 万开发人员（2021 年新增 1600 万）的更广泛的社区中心。

方法论：截至 12 月 27 日，我在 Github 上下载了 247 个热门存储库的数据（按净明星增长），并有条不紊地对每个存储库进行分类：首先是技术存储库还是教育存储库，然后是子类别。

出现了六个明显的趋势领域——每个领域都深入到以下部分：

• 教育资源（~70/250）：模式、面试准备、构建列表……
• Web 开发技术 (~43/250)：框架上的框架
• 开发人员工具 (~35/250)：IDE、终端和真正随机的东西
• 数据、人工智能、机器学习（~21/250）：主要是深度学习
• 新语言：TypeScript、Go 和 Rust
• MISC：微软、Dev Counterculture 和 Surveillance

可以在此处下载完整的存储库列表（包括每个存储库的描述、总贡献者、分叉、问题和拉取请求计数），我在下面提供了一个汇总表。

Category	Subcategory	Total # Repos	Total 2021 New Stars
Tech	webdev	43	601,062
	Other	35	342,338
	Dev-utility	28	339,440
	Data, AI, ML	16	162,183
	App	8	84,383
	Dev-misc	7	67,452
	Crypto	5	53,638
	Programming language	4	41,489
Education	Other	27	422,935
	Patterns	20	317,162
	Interview Prep	6	111,918
	Interviews-leetcode	6	96,322
	Build	6	84,508
	Data, AI, ML	5	64,338
	webdev	1	43,460
	Cybersecurity	1	9,226
MISC		29	401,110
Grand Total		247	3,242,964

 

领域 #1：教育资源

虽然 Github 旨在存储代码，但它已成为众包知识和教育资源的主要枢纽。事实上，今天只有 3/10 的顶级 Github 存储库是“技术”（Vue、React 和 Tensorflow），而到目前为止，Github 上最受欢迎的存储库是一个免费的、非盈利的编码营。

值得注意的子类别和示例：

• 模式列表：各种编程语言（例如 javascript、python、unix、go）中流行算法的最佳实践实现
• 面试准备：面向工作面试准备的资源（例如编码面试大学、技术面试手册）。其中一半是面向 leetcode 平台的，其中大部分也有中文翻译。
• 构建项目：精选的 DIY 项目列表，以提高技能并获得乐趣（例如，构建您自己的 x、应用程序创意、初学者真棒、首次贡献）

我们可以从开发者文化和人口统计中推断出什么？

大量劳动力正在进行技能培训。全球有数百万人第一次学习编程——他们的动机通常是经济解放。这是强大的，但也受到劳动力市场深刻变化的推动。世界经济论坛估计，到 2025 年，技术将消除约 8500 万个工作岗位，同时创造约 9700 万个新工作岗位（链接）。不是每个人都能成功地实现这一转变，我们需要记住这一点，我们需要机制来支持那些没有成功的人。

开发人员❤️ 学习和构建。我最喜欢在科技行业工作的一件事是参与其中的人：喜欢持续学习的书呆子和喜欢建造的创客！

创始人和创业领袖能带走什么？

内容营销为王：通过为持续学习者和/或为喜欢构建的制造者提供教育来编写好的内容😃

标记“良好的第一个问题”可能是有效的：一些“构建项目”列表实际上主要是开源存储库中标记为“良好的第一个问题”的问题的汇编……如果你，新开发人员可以磨练他们的技能，同时成为你的项目的贡献者引导他们走向更容易的机会。在 Github 的 2021 Octoverse 报告中，实际上有一整节是关于使用这个标签的效果的！

给予获得：教育可用于创建护城河并解锁新的 TAM。例如，dbt Labs 社区已成为整整一代数据分析师寻求提升技能的事实上的来源，并正在帮助数千家公司加入现代数据堆栈。他们有自己的一套在线课程。甚至还有一些独立的项目，例如分析工程师俱乐部，提供为期 10 周的基于群组的项目。

另一个有趣的例子是 Conduktor，该公司利用广受欢迎的在线 Udemy 课程并围绕企业 Kafka 平台建立了一个社区，该平台简化了 pub 子系统的管理。

亮点：开发者路线图

作为出色可视化的粉丝，我想重点介绍我最喜欢的教育资源库之一：Kamran Ahmed 的开发者路线图。 请注意，有前端、后端、DevOps 和特定语言的交互式版本。 它们非常酷，请在 https://roadmap.sh/ 上找到它们，这对于试图在更高层次上理解各种技术领域的人们也很有用。

领域 #2：Web 开发

我包括下面的顶级仓库。 Ant-design 位居榜首，尽管我怀疑手头有一个数据怪癖。

跨平台框架正在流行：谷歌的多平台框架 Flutter 越来越受欢迎。 Tauri 是一个利用前端技术开发桌面应用程序的框架，是该列表中相对增长最快的框架之一。 WebAssembly 的发展将如何进一步启用这个空间仍然待定。

名单上有两个 Firebase 的开源替代品：Supabase 和 Appwrite。 我将在即将发布的文章中撰写有关开源替代方案的文章。

关于前端 Web 开发技术的短暂性的说明

Web 开发技术发展得非常快，Web 开发人员的偏好非常短暂。 例如，请参见下面的两个图表：

随着时间的推移，顶级 Web 开发存储库的贡献者

前端框架相当善变：

 

• Gatsby，后来的紫色高峰，从 2017 年 6 月到 2020 年 6 月飙升，然后同样迅速下降
• Flutter，黄色，在 2021 年 3 月达到顶峰，然后开始突然下降
• 甚至 Next.js 也在 2021 年 3 月左右开始略有下降
• React-native，粉红色，在 2017 年左右迅速达到顶峰，然后开始下降）

后端框架更持久：尤其是 Rails、Django 和 Node

随着时间的推移，顶级 SRE¹（想想云原生）存储库的贡献者

请注意，SRE¹ 堆栈的核心技术的崛起速度和持久性似乎要慢得多，尤其是紫色的 Kubernetes，它是所有项目中活跃和合格贡献者数量最多的。

注意：我将在以后的文章中写更多关于这种方法的内容，以及从这个角度来看更详细的基准测试......

创始人和创业领袖能带走什么？

不要成为一招一式的小马，尤其是在前端：考虑到该领域的变化速度，单一的趋势 Web 开发技术不太可能维持一家大型且经久不衰的公司。即使在开发偏好更加持久的领域（想想早期的数据基础设施公司锁定 Hadoop），坚持单一核心技术也是公司的垮台。认识到这一点，在 Next.JS 仍然广受欢迎的同时扩展它，并聘请 Svelte 的创建者，是 Guillame Rauch 才华横溢的一部分。我们可能会开玩笑说每个人都会为 Vercel 工作，但这可能是该领域罕见的可行持久策略！

知道你的社区生活在哪里：

至少在 Github 上，Web 开发人员的数量仍然远大于数据或其他开发人员的数量。 在 2021 年的前 250 个存储库中，Web 开发存储库收集了约 60 万颗星，而与数据、AI 和 ML 相关的存储库仅约为 162K，减少了 4 倍。 请注意，根据以下 2018 年 Slashdata 的估计，Github 可能准确地表明当今世界上以网络为中心与以数据为中心的*开发者*要多得多。

我想有两种力量在起作用，会改变这种动态：1）随着时间的推移，越来越多的“软件工程师”将开始主要利用数据基础设施与 Web 框架并与之交互，2）越来越多的非技术数据从业者（任何业务分析师）都将变得越来越技术化，无论是通过学习 Python 还是 SQL/dbt……虽然不太确定是否会成为 Github 的铁杆用户！

领域 #3：开发工具

老实说，我在这里没什么好说的……Github 上到处都是古怪而酷的开发者工具。其中一些顶级存储库是 shell、终端、IDE 或代码编辑器，它们可能是开发人员体验中最重要的组成部分：

• 微软的 VS Code 以 20K 星位居榜首，并且可能是当今最好的代码编辑器之一，这对许多人来说是一个难以接受的事实 😅 Ofc，Powershell 也在 2021 年以约 9K 星位居榜首
• Coder — 浏览器中的 VS Code，也是其他活动指标增长最快的存储库之一
• 列表中还有一些新的 shell，包括 Tabby 和 Nushell，它们都有大约 7K 星，尽管 Nushell 是一个更新得多的项目

还有一些有趣的插件，同一组工具的附加组件：

• Fig 于 2020 年底开始，今年几乎从零开始增长了约 8000 颗星，它为您的终端添加了高级自动完成功能，无论您选择使用哪个
• 有点滑稽的是，Github（65K 星）上较旧且更受欢迎的实用程序和总体上更受欢迎的存储库之一是“thefuck”，它会自动更正您以前的控制台命令
• 另一方面，Starship 有助于自定义您可能正在使用的任何 shell 的提示

领域 #4：数据、人工智能和机器学习

这并不奇怪：深度学习是最受欢迎的子类别，包括面部转换器存储库、YOLOv5、Tensorflow 和 Deepmind 的 Alphafold。令人惊讶的是，列表中唯一合适的基础设施-ey 存储库是 Meil​​isearch 和 Clickhouse，考虑到 VC 世界中收到的所有炒作数据基础设施，这有点令人惊讶，但同样，可能只是最终用户人口规模的问题 + 是否有数据科学家们在 Github vs. Web Developers 上花费了大量时间……

我还有很多关于数据的文章要写，计划发布未来的帖子……现在，我将重点介绍另外两个很酷的资源：

AI 专家路线图（交互式网页）

似乎从上面链接的开发人员路线图中获得了灵感，非常棒。我喜欢他们如何区分不同的角色，从数据科学家到机器学习，再到深度学习，再到数据工程等等。浏览起来真的很棒而且很有趣！将其与前面提到的开发者路线图以及分析工程师俱乐部并列也很有趣，因为他们收集了很多现代技术，有点 MECE² (#BCG) 方式😃

2. 我喜欢的第二个仓库是 Eugene Yan 的 Applied ML 仓库。

这是一个绝妙的想法，实际上是我计划在我不存在的空闲时间随意做的事情……无论如何，这是一份来自顶级工程团队（Netflix、亚马逊、Pinterest、Linkedin 等）的技术帖子的精选列表.) 详细说明他们如何构建不同类型的 AI/ML 系统（例如预测、推荐、搜索和排名等）。 Ofc，它专注于 AI/ML，但可以为传统或面向 BI 的分析堆栈以及流媒体世界制作类似的东西，对从业者来说超高价值！顺便说一句，我在 BCG 最喜欢的事情之一是查看我们的 IT 架构团队的参考架构图……理解技术的最佳方式是查看大量的东西是如何构建的……它很有趣！

区域#5：街区的新语言

迄今为止，Typescript 是 2021 年热门技术存储库中的主导编程语言，其次是 Javacript、Python、C++、Go 和 Rust。有点有趣的是，顶级教育存储库的组成非常不同，Javascript #1、Python #2 和 Java 仍然排在第 3 位。

技术存储库可能反映了黑客对什么和未来感到兴奋，而教育存储库则反映了当今哪些语言仍然最受欢迎。一位朋友向我建议，这也与“最容易进入障碍”的语言有关，这是有道理的！

为此，我在下面比较了另外三个编程语言流行度的数据源。看起来，查看热门的 Github 存储库实际上是未来最强大的前瞻性指标！

Github 实际上发布了他们自己在整个服务中使用的编程语言的排名：

您可以在下面看到 Typescript 的趋势有多强，尽管 Rust 和 Go 甚至还没有进入该列表！

2. 也许最普遍的来源是 TIOBE 索引，它聚合了跨搜索引擎对不同编程语言的搜索。

令人惊讶的是，Java 和 C 在这个榜单上仍然占据主导地位，Python 仅在上个月超过了它们！

3. 另一个有趣的来源是查看 Stack Overflow 上的标签。

Python 在这里确实占主导地位，但我确实认为，大量面向数据的人利用该网站可能存在一些选择偏差……但是，C# 是 2009 年平台上最流行的，而 JavaScript 仍然表现良好。 你也可以看到 Typescript 的好转。

区域 #6：几个 MISC 点

A.就开源、开发人员友好性和更广泛的公司战略而言，微软已经走了很长一段路。

微软的高级战略主管曾经将开源公司比作那些导致互联网泡沫危机的公司——不负责任和不计后果地免费提供服务。比尔盖茨甚至曾经声称开源对工作不利😂

2014 年任命 Satya Nadella 为 CEO 以及 .NET 堆栈的开源（维基百科对这一切都有很好的回顾）带来了重大变化。今天，微软在 Github 上发现了 2021 年最受欢迎的 8 个存储库：

• 三门教育课程——面向初学者的 Web Dev、ML 和 IoT。注意重新使用教育资源作为营销策略，至少 ML 课程链接到各种 Azure 服务。谷歌也经常这样做，Collab notebooks 经常被用来演示教育材料。
• 开发工具和实用程序，包括 VS Code、Microsoft Terminal 和 PowerToys，
• Web 开发技术，包括占主导地位的 TypeScript 语言，以及用于浏览器自动化测试的越来越流行的 Selenium 替代品：Playwright

B.黑客体现了一种健康的反文化

反买东西，反广告，强烈支持劳工💪

• 绕过付费墙 chrome 是一个插件，它完全按照它所说的那样做，让用户绕过网站付费墙来访问内容。请注意，如果可以，请为优质新闻付费。
• 阻止现场有助于阻止互联网上的广告。我不喜欢隐藏的、广告驱动的商业模式。这实际上是我更广泛地喜欢企业与消费者技术、更清洁和合乎道德的商业模式的重要原因
• 996.ICU 是一个了不起的资料库，基本上是中国不良科技雇主的名单（现在可能更广泛）。它在 2019 年开始流行时受到了媒体的极大关注。他们自己的描述如下：

996.ICU这个名字指的是“996工作，ICU病房”，这是中国开发者的讽刺谚语，意思是按照“996”的工作时间表，你有进入ICU（重症监护室）的风险。 )

C.有一些粗略的趋势，并不是所有的技术都很好（例如，结束事情的一种不那么有趣的方式）

AI/ML 很棒，会给世界带来很多好处，但也存在严重的风险和安全考虑。加强监视和国家控制肯定是其中之一，也许最成熟的滥用用例之一就是面部识别。 2021 年最热门的存储库之一是腾讯的 GFPGAN，它“旨在开发用于真实世界面部恢复的实用算法”。另一个趋势库是 DeepFaceLab，用于创建深度伪造。

顺便说一句：在这个名为 Awful AI 的存储库中有一个非常好的 AI 糟糕用例汇编

另外两个趋势存储库用于在社交媒体帐户中定位人们：Sherlock 项目和社交分析器 - 有点粗略地看到像这样的技术在公共和易于下载的域中漂浮，并很好地提醒我们在互联网上的生活是多么公开。

[1] SRE — 站点可靠性工程，例如CNCF

[2] MECE — 互斥、集体详尽、超级咨询发言（链接）

 

本文：https://jiagoushi.pro/node/2033

不确定性锥的概念已经存在了一段时间。Barry Boehm在“软件工程经济学”的著作。普伦蒂斯·霍尔，1981年。下面的帖子来自Steve McConnell的网站，它清楚地说明了一些事情。

但首先，让我们建立一个框架假设。当你听说项目的不确定性没有随着项目的进展而减少时，问一个简单的问题。为什么会出现这种情况？为什么随着项目的进展，新的信息、交付的产品、降低的风险，整体的不确定性没有减少？在声称不确定性没有减少之前，先去找出造成这种情况的根本原因。不确定性作为所有项目的原则，应该通过项目管理的直接行动来减少。如果不确定性没有减少，情况可能是——糟糕的管理，失控的项目，或者你在纯粹的研究世界里工作，诸如此类的事情就会发生。

那么什么是不确定性锥呢？

• Cone是一个项目管理框架，描述了估算（成本和进度）和其他项目属性（成本、进度和技术性能参数）的不确定性方面。与锥体右侧的估计相比，锥体左侧的成本、进度和技术性能估计具有较低的精确性和准确性。这是由于许多原因造成的。一个是项目早期的不确定性水平。解释性和认识性的不确定性，给项目的成功带来了风险。造成风险的其他不确定性包括：
  • 不切实际的绩效期望，缺少有效性衡量标准和绩效衡量标准
  • 对风险的评估不充分，以及通过适当的处理计划未减轻对这些风险的暴露。
  • 与保持有效性的替代计划和解决方案有关的未预料到的技术问题
• 由于所有项目工作都包含不确定性，减少这种不确定性——这降低了风险——是项目团队及其管理层的职责。团队本身、项目经理或项目经理，或大型项目的风险管理所有者。

以下是不确定性锥的简单定义：

不确定性锥描述了项目期间不确定性度量的演变。为了项目的成功，不确定性不仅必须随着时间的推移而减少，而且必须减少其对项目结果的影响。这是通过积极的风险管理，通过概率决策来实现的。在项目开始时，通常对产品或工作结果知之甚少。估计是必要的，但存在很大的不确定性。随着更多的研究和开发工作的进行，人们了解到了更多关于该项目的信息，不确定性随之降低，当所有风险都得到缓解或转移时，不确定性达到0%。这通常发生在项目结束时。

那么问题是？-为了提高项目成功的概率，项目属性（风险、有效性、性能、成本、进度——如下所示）需要在多大程度上减少差异？这是闭环项目控制的基础。对所需不确定性减少的估计、对不确定性可能减少的估计以及对这些减少工作的有效性的估计是闭环项目控制系统的基础。

这是不确定性锥的范式——它是一个计划开发合规性工程工具，而不是事后数据收集工具。

Cone不是项目过去表现的结果。Cone是项目进行过程中所需减少不确定性（或其他性能指标）的计划边界（上限和下限）。当成本、进度和技术性能的实际指标超出计划的不确定性范围时，如果项目要达到成本、进度或技术性能目标，就必须采取纠正措施，将这些不确定性转移到不确定性范围内。

如果你的项目的不确定性在计划范围之外，而此时它们本应在计划范围之内，那么你并没有降低项目成功的风险

在不确定性锥中建模的度量是建立绩效度量目标的控制过程的定量基础。获取实际性能，将其与计划性能进行比较，并遵守控制上限和下限，为进行调整以将变量性能保持在可接受的范围内提供了指导。

使用不确定性锥的好处

计划值、控制上限和下限、实际值的测量值形成闭环控制系统-一个基于测量的反馈过程，通过[1]提高项目管理过程的有效性和效率

分析有助于尽早关注问题领域的趋势——当受控变量开始行为不端时，可以采取干预措施。没有必要等到最后才发现你活不下去了。

• 提供对易出错产品的早期见解，然后可以更早地进行纠正，从而降低成本——当趋势走向UCL和LCL时，可以进行干预。
• 通过及早发现成本超支和进度延误，通过观察违反UCL和LCL的趋势，避免或最大限度地减少成本超支和工期延误。
• 在项目中足以实施纠正措施
• 执行更好的技术规划，并根据计划进度和实际进度之间的差异对资源进行调整。

所有项目工作的一个关键成功因素是风险管理。风险管理包括对各种风险的管理。风险来源于各种不确定性，包括技术风险、成本风险、进度风险、管理风险。这些不确定性及其产生的风险中的每一个都可以采用概率和统计分布函数描述的一系列值。了解哪些范围是可能的，哪些范围是可接受的，是项目成功的关键因素。

我们需要知道影响我们项目成功的所有变量的范围的控制上限（UCL）和控制下限（LCL）。我们需要知道这些范围是时间的函数。通过这种范式，我们将项目管理过程与控制系统过程逻辑连接起来。如果由UCL和LCL之外的不确定性造成的差异。这是一篇正在进行的论文“项目管理有一个基本理论吗”，它解决了项目活动控制的一些问题。

以下是一些计划差异和实际差异管理的例子，以确保项目按计划进行。

作为程序成熟度增加的函数的产品重量。在这种情况下，计划基本重量，并将每个主要子系统的计划重量作为时间的函数进行布局。项目基本权重的公差带为管理层提供了有关项目进展的可操作信息。如果车辆超重，则需要金钱和时间来纠正不希望出现的偏差。这是一个闭环控制系统，用于通过技术性能度量（TPM）管理程序。也可以采用成本和进度绩效衡量标准。

下面是具有错误带的“权重减少”属性的另一个示例。在本例中（与上述示例类似的实际车辆），当程序从左向右进行时，必须减轻重量。我们在测试准备审查中的目标重量为23KG。提案中出售了一辆25公斤的汽车，我们需要一个有安全裕度的目标重量，因此23公斤是我们的目标。

随着项目的进行，有UCL和LCL波段遵循计划的重量。橙色圆点是来自各种来源的实际重量——设计模型（3D Catia CAD系统）、详细设计模型、可测量的台式模型、非飞行原型，然后是第一次飞行文章）。随着程序的进行，每个模型到最终产品的每个重量测量值都会与计划重量进行比较。如果我们要坚持计划，我们需要将这些值保持在“需要减肥”的误差范围内。

这是成功项目管理的关键概念

我们必须为项目的关键属性——任务有效性、技术性能、关键性能参数——制定计划。如果这些不符合要求，项目将成为程序性能不足的根本原因之一。我们必须有一个燃耗或燃耗计划，以便在项目过程中为项目产生与这些参数相匹配的最终项目交付物。当然，我们一开始对每一项都有广泛的可能结果。随着程序的进行，这些项目的差异度量朝着符合目标数字的方向发展，在这种情况下为权重。

这是不确定性锥的另一个例子，在这种情况下，不确定性是由工程团队设计的烤箱的温度。UCL和LCL是在项目开始之前定义的。这些信息用于在项目进行过程中告知设计者项目的进展情况。保持在控制范围内是实现最终目标的计划进度路径——在这种情况下是温度。

不确定锥是闭环控制系统的信号边界，用于管理项目的成功

事实证明，圆锥体也可以是一个平坦的范围，具有正在开发的变量的控制上限和控制下限——一种对变量的设计——在本例中是一种性能度量。在这种情况下，当项目通过大门时，需要保持在上限和下限范围内的绩效衡量标准。如果这个变量超出了界限，项目将不得不以某种方式支付费用，才能将其退还给Green。

性能度量表征了在特定条件下测量或估计的与系统运行相关的物理或功能属性。性能度量是（1）确保系统有能力和能力执行的属性；（2）对系统进行评估，以确保其满足设计要求，从而满足有效性度量；（3）当实际性能超出控制上限和控制下限时，采取纠正措施，使实际性能恢复到计划性能。同样，这是简单的统计过程控制，使用反馈采取纠正措施来控制未来的结果——前馈。在概率和统计程序管理范式中，前馈控制使用过去的性能，以及未来的模型（未来行为的蒙特卡洛模型）来确定需要采取哪些纠正措施来保持程序的绿色。

另一种锥形风格是对交货日期的信心锥形。实际情况是低地球轨道飞行器的发射日期。在这种情况下，随着程序从左向右移动，我们需要确保启动日期从低置信度日期移动到有可能正确的日期。蓝色条是当前估计日期的概率范围。随着程序的推进，如果我们要根据需要出现，这些范围必须缩小。计划日期和带边距的日期是生成日期。随着程序的移动，日期的可信度必须增加，并朝着需要的日期移动。

• 概率完成时间随着程序的成熟而变化。
• 产生这些改进的努力必须加以界定和管理。
• 评估点的误差带也必须包括风险缓解活动。
• 计划的活动显示了误差带是如何随着时间的推移而变窄的：
  • 这是风险容忍计划的基础。
  • 随着风险缓解和成熟度评估增加了对计划发射日期的信心，概率区间变得更加可靠。

再次提醒一下——不确定性锥是一条理想的路径，而不是非托管项目结果的结果。

风险管理，如下所示，是成年人管理项目的方式

不确定性锥的目的和价值误区综述

当你听到。。。

我有数据表明，不确定性（或任何其他需要的属性）不会减少，因此COU是一个假的。。。或者。。。我看到我的项目数据，随着我们的前进，差异越来越大，而不是像计划COU告诉我们的那样缩小，应该实现我们的目标。。。

……然后该项目就失去了控制，从一个缺失的指导目标开始，这意味着它是开环控制，而且会迟到，超出预算，很可能无法达到所需的有效性和性能参数。当你看到这些失控的情况时，去寻找根本原因并制定纠正措施。

这些数据是对一个项目没有得到管理的观察，正如Tim Lister所建议的那样——风险管理就是成年人如何管理项目。

如果这些观察结果是在没有对绩效不足的根本原因采取纠正措施的情况下进行的，那么管理层的行为就很糟糕。他们只是对即将发生的火车事故的观察者。

不确定锥模型的工程原因及其对设计人员的价值

不确定性锥不是项目行为的输出，到那时已经太晚了。

不确定锥是管理框架的指导目标，用于增加项目成功的可能性。

这是项目的程序管理，以支持项目的技术管理。过程是一门工程学科。系统工程、风险工程、安全和任务保证工程是我们工作的典型角色。

否则的建议就是颠倒范式，从项目绩效的事后观察中去除任何价值。到那时已经太晚了，马已经离开了，再也回不来了。

在项目中的计划点定义计划和所需的方差水平是闭环控制系统的基础，需要提高成功的概率。

当出现计划差异之外的差异时，必须找到这些差异的根本原因并采取纠正措施。

以下是Galorath演示中的一个例子，使用了不确定性锥的框架，以及如何将这些放在一起的实际项目锥。再次重申，不确定性锥是

计划减少项目关键绩效指标的不确定性。

如果你的项目没有按计划减少这些关键性能指标（成本、进度和技术性能）的不确定性，那么它就会陷入麻烦，你甚至可能不知道。

Resources

[1] Systems Engineering Measurement Primer, INCOSE

[2] System Analysis, Design, and Development Concepts, Principles, and Practices, Charles Wasson, John Wiley & Sons

[3] SMC Systems Engineering Primer & Handbook: Concept, Processes, and Techniques, Space & Missle Systems Center, U.S. Air Force

[4] Defense Acquisition Guide, Chapter 4, Systems Engineering, 15 May 2013.

[5] Program Managers Tool Kit, 16^th Edition, Defense Acquisition University.

[6] "Open Loop / Close Loop Project Controls"

[7] "Reducing Estimation Uncertainty with Continuous Assessment: Tracking the 'Cone of Uncertainty'," Pongtip Aroonvatanaporn, Chatchai Sinthop, Barry Boehm. ASE’10, September 20–24, 2010, Antwerp, Belgium. 

[8] Boehm, B. “Software Engineering Economics”. Prentice-Hall, 1981.

[9] Boehm, B., Abts, C., Brown, A. W., Chulani, S., Clark, B. K., Horowitz, E., Madachy, R., Reifer, D. J., and Steece, B. Software Cost Estimation with COCOMO II, Prentice-Hall,

2000.

[10] Boehm, B., Egyed, A., Port, D., Shah, A., Kwan, J., and Madachy, R. "Using the WinWin Spiral Model: A Case Study," IEEE Computer, Volume 31, Number 7, July 1998, pp.  33-44 

[11] Cohn, M. Agile Estimating and Planning, Prentice-Hall, 2005

[12] DeMarco, T. Controlling Software Projects: Management, Measurement, and Estimation, Yourdon Press, 1982.

[13] Fleming, Q. W. and Koppelman, J. M. Earned Value Project Management, 2nd edition, Project Management Institute, 2000

[14] Galorath, D. and Evans, M. Software Sizing, Estimation, and Risk Management, Auer-bach, 2006

[15]Jorgensen, M. and Boehm, B. “Software Development Effort Estimation: Formal Models or Expert Judgment?” IEEE Software, March-April 2009, pp. 14-19

[16] Jorgensen, M. and Shepperd, M. “A Systematic Review of Software Development Cost Estimation Studies,” IEEE Trans. Software Eng., vol. 33, no. 1, 2007, pp. 33-53

[17] Krebs, W., Kroll, P., and Richard, E. Un-assessments –reflections by the team, for the team. Agile 2008 Conference

[18] McConnell, S. Software Project Survival Guide, Microsoft Press, 1998

[19] Nguyen, V., Deeds-Rubin, S., Tan, T., and Boehm, B. "A SLOC Counting Standard," COCOMO II Forum 2007

[20] Putnam L. and Fitzsimmons, A. “Estimating Software Costs, Parts 1,2 and 3,” Datamation, September through December 1979

[21] Stutzke, R. D. Estimating Software-Intensive Systems, Pearson Education, Inc, 2005. 

Related articles

如何使用代码生成和脚手架工具加快开发速度？

1. 什么是代码生成？
2. 什么是脚手架？
3. 代码生成和脚手架如何加快开发速度？
4. 您可以使用哪些工具来生成代码和搭建脚手架？
5. 如何学习和使用代码生成和脚手架工具？

什么是代码生成？

代码生成是从更高级别的表示（如模型、模板或规范）创建源代码或配置文件的过程。代码生成可以自动化常见或冗长的任务，例如创建CRUD操作、数据库模式、API端点或UI组件。代码生成还可以确保一致性、质量以及符合标准和最佳实践。

什么是脚手架？

脚手架是一种特殊类型的代码生成，它基于一些预定义的选项或参数为项目创建基本结构或骨架。脚手架可以帮助您引导新项目、设置初始文件和文件夹、安装依赖项以及配置环境。脚手架还可以提供一些示例代码或测试，让您开始使用。

代码生成和脚手架如何加快开发速度？

代码生成和脚手架可以在几个方面加快您的开发。首先，它们可以通过生成代码来节省您的时间和精力，否则您将不得不手动编写或复制粘贴这些代码。其次，他们可以通过创建遵循语言或框架的约定和语法的代码来减少错误和bug。第三，它们可以让你专注于项目的核心逻辑和功能，而不是样板或设置，从而提高你的生产力和专注力。第四，他们可以通过向您展示最佳实践和模式来增强您的技能和知识，您可以从中学习并应用于自己的代码。

您可以使用哪些工具来生成代码和搭建脚手架？

根据您的语言、框架和偏好，有许多工具可用于代码生成和脚手架。例如，如果您使用Java，您可以将Spring Boot、JHipster或Lombok用于web应用程序、微服务或数据访问层。或者，如果您使用Python，Cookiecutter、Django或FastAPI可以用于构建项目、web框架或RESTful API。同样，如果您使用JavaScript，Yeoman、Create React App或Angular CLI可以创建和管理项目、UI库或单页应用程序。最后，对于C#开发。NET Core CLI、Entity Framework Core或Blazor可以为跨平台应用程序、数据库模型或web组件生成代码。

 

如何学习和使用代码生成和脚手架工具？

要学习和使用代码生成和脚手架工具，您需要进行一些研究和实验。您可以先查看您感兴趣的工具的官方文档和教程，看看它们提供了哪些功能和选项。您还可以查找涵盖这些工具及其用例的在线课程、书籍或博客。然后，您可以尝试将这些工具用于自己的项目，或者创建一些示例项目来练习和测试它们。您还可以比较和对比不同的工具，看看哪些更适合您的需求和偏好。

代码生成和脚手架是强大的技术，可以帮助您加快开发速度并提高代码质量。通过为您的语言和框架使用正确的工具，您可以自动化和简化许多任务，并专注于项目中最重要的方面。您还可以从工具生成的代码中学习，并采用可以增强您的技能和知识的最佳实践和模式。

以下是其他需要考虑的事项

这是一个分享不适合前面任何部分的例子、故事或见解的空间。您还想添加什么？

为了编写好的软件文档，需要了解一个秘密：没有一种叫做文档的东西，有四种。

它们是：教程、操作指南、技术参考和解释。 它们代表四种不同的目的或功能，并且需要四种不同的方法来创建它们。 了解这一点的含义将有助于改进大多数文档——通常是极大的。

关于系统

此处概述的文档系统是一个简单、全面且几乎普遍适用的方案。它已在广泛的领域和应用中得到实践证明。

有一些非常简单的原则来管理文档，这些原则很少被阐明。它们似乎是一个秘密，尽管它们不应该是。

如果您能将这些原则付诸实践，它将使您的文档变得更好，并使您的项目、产品或团队更加成功——这是一个承诺。

该系统广泛用于大小、开放和专有的文档项目。

• 介绍
  • 问题和解决方案
    • 它解决的问题
    • “秘密”
  • 使文档工作
    • 对于作者
    • 对于读者
• 教程
  • 烹饪类比
  • 如何写出好的教程
    • 让用户边做边学
    • 让用户开始
    • 确保您的教程有效
    • 确保用户立即看到结果
    • 使您的教程可重复
    • 专注于具体步骤，而不是抽象概念
    • 提供最低限度的必要解释
    • 只关注用户需要采取的步骤
  • Divio 文档中的示例
• 操作指南
  • 烹饪类比
  • 如何编写好的操作指南
    • 提供一系列步骤
    • 关注结果
    • 解决特定问题
    • 不要解释概念
    • 允许一些灵活性
    • 把事情放在一边
    • 名称指导很好
  • Divio 文档中的示例
• 参考指南
  • 烹饪类比
    • 如何编写好的参考指南
    • 围绕代码构建文档
    • 始终如一
    • 除了描述什么都不做
    • 准确无误
  • Divio 文档中的示例
• 解释
  • 烹饪类比
  • 如何写一个好的解释
    • 提供上下文
    • 讨论替代方案和意见
    • 不指导或提供技术参考
  • Divio 文档中的示例
• 关于结构
  • 为什么这不明显？
  • 崩溃的趋势
  • 系统的采用
  • 关于分析及其应用
• 谁在使用该系统？
  • 其他提及和感兴趣的参考

原文：https://documentation.divio.com/

本文：https://jiagoushi.pro/documentation-systemp-grand-unified-theory-docume…

不确定性锥只是意味着估计不确定性随着项目的进展而减少。

不确定性锥的概念是过去50年软件项目统计的结果。20世纪50年代引入工程和化学工程，并在20世纪80年代进一步推进软件开发。不确定性锥的概念最早是由AACE国际（美国成本工程师协会）的创始人根据维基百科介绍的，用于化学工业的工程和施工研究。后来，不确定性锥被广泛用作飓风预测中的图形，其最具标志性的用法更正式地称为NHC跟踪预测锥，更常见的是称为误差锥、概率锥或死亡锥。在软件行业，项目经理和软件开发人员使用不确定性锥来指导和管理项目估计。

在软件开发中，史蒂夫·麦康奈尔（Steve McConnell）在1997年出版的《软件项目生存指南》（software Project Survival Guide）一书中首次使用了“不确定性锥”一词，当时他将其作为估计具有不确定性或未知性的分类系统的标准类型。它说明了在项目的生命周期中，估计是如何变得更加准确的。

“软件评估的主要目的不是预测项目的结果，而是确定项目的目标是否足够现实，以使项目能够得到控制，从而实现这些目标”——Steve McConnell。

在软件项目的早期阶段，准确性水平较低，因此误差幅度较大。该项目可能会从许多未知和不明确的需求开始。在项目管理的最初收集需求阶段，任何任务估计都将非常松散，并且可能非常不准确。在软件生命周期中，随着项目接近完成阶段，可变性程度降低，这是一种常见的模式。了解可变性是制定现实项目计划的关键，因此项目可能会在初始规划阶段以正负40%的粗略估计开始。

不确定度图的圆锥体由横轴上的时间和纵轴上的估计方差表示。随着时间的推移，图向右移动，高估线的范围收敛到接近零。在项目开始时，时间线上的不确定性在圆锥体的大端最大，圆锥体的小端在所有细节都已知的末端。

使用不确定性锥的主要好处：

在软件开发中，不确定性锥用于管理需求和任务不断变化的项目，包括产品开发中使用的业务需求和技术。在工程成本和软件开发中的不确定性数量之间建立直接关系。

为什么不确定性锥很重要

在项目经理估计软件需求的交付成本的情况下，不确定性锥是非常可取的。它影响软件团队估计生产工作量、业务流程、时间表和功能的能力。开发人员离实际实现软件需求目标越远，他们的估计就越不确定和不准确。

• 减少不确定性
• 真实准确的估计
• 有效的规划
• 降低风险
• 度量资源分配
• 确定期望值