Shitlist驱动开发（2016）

最近，我与之合作的团队完成了一个项目，以允许Shopify在多个数据中心中运行。这个项目是一个变相的重构项目。当您使用100位开发人员和100,000行代码行对代码库进行大规模重构时，您将无法通过发送电子邮件进行调整。单个合并请求的合并冲突会使我不寒而栗。在大型代码库中弃用时，可靠地避免新的过时行为的唯一方法是测试失败，并告诉您该怎么做。否则，引入新的过时代码的步伐很容易超过您删除它们的速度，或者挫败感的巨大根源。

通常，弃用以软警告的形式出现：登录到文档中的stderr，大写字母和感叹号，或方法或类名的旧前缀。归根结底，每个人都需要做好工作，并且尽管看到这些软警告，但如果他们看到已经从代码库的10个位置使用了代码路径，那么引入另一个似乎并不疯狂。但是，如果在这些不建议使用的代码路径上阻止了另一个项目，则堆积可能会付出巨大的代价。

为了解决这个问题，弗洛里安·温加滕（Florian Weingarten）在我们的团队中介绍了他所谓的“ shitlists”（shitlists）：过时的行为白名单。禁止对deprecatedAPI进行新的使用，并且测试失败并出现明确定义的错误。

Shitlist = [ClassA，ClassB，ClassC] def push_job_that_does_crazy_things（klass）如果Shitlist .include？（klass）＃调用了现有的不赞成使用的行为。否则引发Shitlist ::错误，＆lt;＆lt; -EOS您正在推动一项疯狂的工作。此代码库中已弃用该API。 ＆lt;团队＆gt;正在积极尝试摆脱此代码-path，因为＆lt;原因＆gt;。我们建议您改为＆lt;替代＆gt;。如有疑问，请＆lt; team＆gt;。 EOS结束

对于特定的代码路径，shitlist可能像git grep一样简单：

测试没有新的遗留代码路径的介绍＆＃34;做实际=`git grep some_legacy_method_with_a_unique_name` assert_equal 321，实际结束

RedisShitlist = [会话，FragmentCache，AuthenticationTokens]测试＆＃34;未引入新的Redis模型＆＃34;做assert_equal RedisShitlist，RedisModel .descendants结束

确保仅在特定上下文中读取特定数据存储区（或根本不使用）。这将允许使用只读从设备，或提高特定区域的弹性。

确保备用数据存储的所有用途都有备用。例如。如果您在Redis中访问会话并且Redis处于关闭状态，则您仍应该能够呈现该页面（即会话为空）。

在没有业务连接的表之间进行Shitlisting连接。这有助于保持数据模型和范围的整洁，或分离应用程序的一部分。

如果您有一个项目的lint，则可以对规则进行编码。例如，您可以将Foodcritic用于Chef，或将Rubocop用于Ruby。

强大的反馈回路。目标是将Shitlist减少为emptyArray，并始终完全提高或删除代码。从列表中删除一个类，修复代码和测试，庆祝并继续前进。

止血了。除非与团队联系或采取错误中定义的其他措施，否则不会引入新的过时行为。

成功指标。如果您有项目清单需要完成的所有项目的清单，则可以跟踪指标。每周您都可以查看这些列表的缩减情况。一次进行数月的重构可能会很累，但是如果您发现在移动指标方面取得了进步，那将是非常有意义的。

强制执行保证。例如，您可以拥有所有作业都具有重试机制的Shitlist。在这种情况下，您知道您可以随时优雅地杀死任何工作人员，因为该作业将重试。由于1-3，您知道获得此保证将需要多少工作。

shitlist错误是可操作的，这一点很重要。如果您碰到另一支球队的名单，则需要知道下一步该怎么做。理想情况下，该错误确切地说明了您需要执行的操作，并且无需任何人说话，但是与您的恋爱清单所有者保持联系应该始终是该恋爱清单的一部分。

如果您拥有名单，则必须对遇到问题的每个人都充满同情。如果您只是不赞成使用新的行为而没有提供替代方案，那么您将成为沮丧的源头。如果清空shitlist的价值远远超过添加到shitlist的价值，则可以不提供其他直接解决方案，而请遇到错误的人修改其解决方案也可以。

重要的是，人们应尽可能早地进入开发名单。如果您花了几个小时来实施解决方案后遇到了垃圾邮件列表，那么您将不那么受欢迎。有些名单可能需要对某些团队的解决方案进行整体重新架构。

在我们的情况下，为期数月的重构可能是不堪重负的工作。借助名单列表中引入的强大反馈循环，您可以看到隧道尽头的灯光。您知道在不知道的情况下什么也不会添加到shitlist。

在某些情况下，创建名单可能非常困难。有些需要花费数小时才能创建，而另一些则需要数周，而我们的案例需要花费数月才能得出。您必须将开发shitlist的成本与不拥有shitlist的成本进行比较。在某些情况下，如果您断言新行为的风险很小，而引入垃圾邮件列表的复杂性很大，那么在遇到错误的代码路径时进行日志记录可能就足够了（simplesoft警告弃用）。

与shitlists委派很棒。由于紧密的反馈循环，询问其他团队或加入新的团队成员变得容易得多。删除名单上的内容，修复代码和测试，然后继续。有时在大型重构期间，您可能需要其他团队，他们需要在代码库某个区域拥有更多领域专业知识，以提供帮助。名单上的人物成为指点人物的大石头。

如果您打算进行大型重构，强烈建议您将工具列表添加到工具箱中。 从不透明的目标转到列表列表，您的项目看起来将不再那么艰巨。