从 Drupal 6 升级到 Drupal 7：程序员的最佳实践？

Question

虽然我从 D4 系列开始就使用 drupal，但我才开始使用 D6 进行专业开发，所以 - 尽管我进行了各种网站升级 - 我从未面临过必须移植我自己的代码的任务 到新版本。

我知道 Drupal 社区会提供很多关于更改 API 和架构更改的技术支持（请参阅 D5-D6 的 deadwood module 甚至这些 D6-D7 操作方法的存根for modulesand themes)。

但是，我的问题更多的是战略思考，或者换句话说，我正在寻找有关如何计划/实施/根据同事开发人员从以前的经验中学到的知识，回顾移植我自己的代码的过程。一些例子：

1. 您是否建议我一有时间就开始移植我的模块，并在一段时间内保持并发 D7（因此我为 D 日“做好了准备”），还是建议您宁愿等待移植真正迫在眉睫的那一天，然后将模块升级到 D7 并删除 D6 版本？
2. 只有我的一些模块具有完整的测试覆盖率。您是否建议完成 D6 版本的测试覆盖，以便让所有测试都能检查 D7 端口，还是建议在移植时编写我的测试指令以测试 D7 版本？
3. 您是否发现作为早期采用者在新功能和更好的 API 方面为您提供了优势，或者您是否发现延迟转换以利用大量现成的 contrib 模块更方便？
4. 您是否为自己设置了质量标准/评估标准，或者您是否只是将标准设置为“如果有效，我很高兴”？为什么？如果你设定了某些标准或目标，它们在哪里/它们会是什么？他们对您有什么帮助？
5. 您过去是否遇到过常见的陷阱，并且您认为这些陷阱适用于 D6-D7 移植过程？
6. 移植是进行一些重构的好时机，还是只是让一切变得更加复杂而需要重新组合在一起？
7. ...

这些问题并非详尽无遗，但我希望它们能让我了解我正在寻找什么样的信息。我宁愿说：任何你认为相关且我没有在上面列出的东西都会得到一个“加号”！ :)

如果我没有足够清楚地表达自己，请发表评论，并附上您认为我应该在问题中添加的信息。提前感谢您的宝贵时间！

PS：是的，我知道... D7 还没有推出，重要的贡献模块升级还需要几个月的时间...但是现在开始思考永远不会太早！ :)

Answer 1

好问题，让我们看看：

1. （何时开始移植）
   这当然取决于要移植的模块的复杂性。如果确实有复杂/大的问题，早点开始可能会很有用，以便在没有压力的情况下找到棘手的地方。对于较小的/标准的，我会尝试找到一个更大的时间段，以便我可以连续移植其中的许多，以便快速记住常规内容（并从可能改进的文档中受益）。

2. （测试覆盖率）
   通常我会说在开始重构/移植之前有一个好的测试覆盖率肯定是可取的。但是鉴于 Drupal-7 通过将测试框架移至核心引入了一个重大变化，我预计无论如何都需要重写大量测试。因此，如果迁移后不需要维护 Drupal-6 版本，我会节省时间/麻烦，并在移植后扩大覆盖范围。

3. （早期采用者与观望）
   从 4.7 版本开始使用 Drupal，我们总是在考虑移植之前至少等待新主要版本的第一个正式发布。对于 Drupal 6，我们在移植我们的第一个站点之前等待视图模块，我们仍然在 Drupal-5 上有一些较小的项目，因为它们工作得很好，而且很难证明我们的客户的额外费用是合理的仍然有维护/安全修复。一天中只有这么多的时间，而且总是有很多待修复的错误、要添加的功能等，所以玩未完成的技术是没有用的，因为还有更多迫在眉睫的事情要做，这将立即使我们的客户受益。现在，如果我们必须维护一个或多个“官方”贡献的模块，这肯定会有所不同，因为提供早期端口将是一件好事。
   我在这里有点困惑 - 作为早期采用者肯定会使社区受益，因为有人必须在修复之前发现错误，但另一方面，与错误斗争一小时又一小时几乎没有商业意义如果您稍等片刻，其他人可能已经找到/修复了。只要我必须以此为生，我就需要关注我的资源，努力在服务社区和从中受益之间取得可接受的平衡：-/

4. （质量标准）
   “如果它有效，我很高兴”并没有削减它，因为我不想只是暂时的快乐，但明天也是如此。因此，我的质量标准之一是我需要（在某种程度上）确定我足够好地“理解”新概念，以便不仅使事情发挥作用，而且使它们按应有的方式工作。现在这很难更准确地定义，因为在“得到它”之前显然不可能知道一个人是否“得到它”，所以它归结为“是的，它有点工作”与“是的”的直觉/区别，这看起来是对的”，人们不得不承认他经常会在这方面犯错。
   也就是说，我正在寻找的一个特别点是“尽早干预”。作为初学者，我经常在主题阶段“事后”调整一些东西，而通过一个或另一个钩子在处理链中更早地应用“修复”会容易得多。所以现在，每当我要在主题层中“调整”某些东西时，我都会故意花一点时间来检查这是否不能在更早的挂钩中更干净/兼容地完成。由于我希望 Drupal-7 添加更多挂钩选项，因此我会特别注意这一点，因为它通常会减少添加新模块时的冲突和突然“破坏”。

5. （常见的陷阱）
   好吧 - 主要是移植到早期，然后发现一个或多个所需模块根本不适用于新版本，或者仅处于 dev/alpha/early beta 状态。所以我会确保首先编译一个完整使用/需要的模块列表，列出它们的移植状态，以及快速检查它们的问题队列。
   除此之外，到目前为止，我一直非常对新版本及其改进感到满意，我再次期待 Drupal-7。

6. （移植时重构）
   可以说移植本身就是一个相当大的重构，因此没有必要通过重构与移植无关的东西来增加复杂性。另一方面，如果您已经不得不将您的模块撕成碎片，为什么不利用这个机会对其进行大修呢？我会尝试根据复杂性画一条线——对于大/复杂的模块，我会尽可能直接地做端口，如果需要，稍后再进行更多重构。对于较小的模块，这并不重要，因为引入细微错误的可能性应该很小。

7. （其他东西）
   ...需要考虑一下...

---

好的，其他的：

• 资源需求 - 鉴于某些 Drupal-7 线程，看起来它们可能会上升，因此在移植位于共享/受限主机帐户上的较小站点之前，应评估这一点。

• 最新版本优先 - 这是相当明显的，并且总是在升级指南中强调，但仍然值得一提：在进行重大升级之前，首先将核心和所有模块升级到最新的当前版本，因为升级代码是很可能依赖于最新的表/数据结构才能正常工作。鉴于 Drupal 的“零碎”，一次一步的更新策略，很难实现能够检测不同的升级前状态并采取相应行动的升级代码。