从Drupal6升级到Drupal7:程序员的最佳实践？
虽然我从D4系列开始就开始使用drupal，但我只是开始使用D6进行专业的开发，所以-尽管我做了各种站点升级-我从未遇到过必须将我自己的代码移植到新版本的任务。
我知道Drupal社区会提供很多关于更改的应用编程接口和架构更改的技术支持(请参阅D5-D6的，甚至D6-D7的 的存根)。
然而，我在我的问题中寻找的更多的是战略思维，或者换句话说，我正在寻找关于如何计划/实现/审查移植我自己的代码的过程的输入和建议，根据同事开发人员从以前的经验中学到的东西。下面是一些例子：
- 你会建议我一有时间就开始移植我的模块，并在一段时间内保持一个并发的D7 (所以我已经为D- day做好了准备)，或者你是否更愿意等到移植即将到来的那一天，然后将模块升级到D7并放弃D6版本？
- 只有我的一些模块有完整的测试覆盖范围。您是否建议完成D6版本的测试覆盖范围，以便让所有测试都工作以检查D7端口，或者您是否建议在移植时编写我的测试指导，以测试D7版本？
- 您是否发现作为早期采用者在新功能和更好的API方面给您带来了优势，还是您觉得延迟转换更方便，以便利用更多现成的contrib模块？
- 您是否为自己设置了质量标准/评估标准，或者您只是将标准设置为“如果它有效，我很高兴”？为什么？如果你设定了特定的标准或目标，他们在哪里/将会是什么？它们是如何帮助你的？
- 有没有你过去遇到过的，并且你认为适用于D6-D7移植过程的常见陷阱？
- 正在移植一些重构的好时机，或者它只会使一切变得更加复杂，无法放回together?
- ...
这些问题并不是一个详尽的列表，但我希望它们能让我知道我在寻找什么样的信息。我更愿意说:任何你认为相关的东西，我没有在上面列出，都会得到一个“加号”！:)
如果我不能清楚地表达自己，请发表评论，并提供您认为我应该在问题中添加的信息。提前感谢您的宝贵时间！
附言:是的，我知道……D7还没有发布，在重要的contrib模块升级之前需要几个月的时间……但现在开始思考永远不会太早！:)
回答 1
Stack Overflow用户
发布于 2009-11-18 04:06:45
好问题，让我们来看看：
- (何时开始移植)
这当然取决于要移植的模块的复杂性。如果真的很复杂/很大，那么尽早开始可能会很有用，这样可以在没有压力的情况下找到棘手的地方。对于较小的/标准的，我会尝试稍后找到一个更大的时隙，在那里我可以连续移植许多它们，以便快速记住例程内容(并受益于可能改进的documentation).
- (test覆盖范围)。
通常我会说，在开始重构/移植之前，有一个良好的测试覆盖率肯定是明智的。但鉴于Drupal-7通过将测试框架移至核心而引入了关于测试框架的重大更改，我预计无论如何都需要重写大量测试。因此，如果在迁移后不需要维护Drupal-6版本，我会节省时间/麻烦，并在porting.
- (early采用者与观望之后扩大覆盖率。)
从4.7版本开始使用Drupal，在考虑移植之前，我们一直在等待新的主要版本的第一个正式发布。使用Drupal6，我们在移植我们的第一个站点之前等待视图模块，我们在Drupal-5上仍然有一些较小的项目，因为它们工作得很好，只要仍然有维护/安全修复，就很难为我们的客户证明额外的账单是合理的。一天中有这么多的时间，总是有这些积压的bug需要修复，有功能需要添加等等，所以在有更多迫在眉睫的事情要做的时候，使用未完成的技术是没有用的，因为这些事情会立即让我们的客户受益。现在，如果我们必须维护一个或多个“官方”贡献的模块，这肯定是不同的，因为提供一个早期的移植将是一件好事。
只要我必须以此为生，我就需要注意我的资源，试图在服务社区和从中受益之间取得可接受的平衡：-/
- (质量标准)
“如果它起作用了，我很高兴”并没有影响到它，因为我不想仅仅是暂时的快乐，而是明天也一样。因此，我的质量标准之一是，我需要(在某种程度上)确定我充分地“领会”了新概念，以便不仅能让事情正常工作，而且能让它们像应该的那样工作。现在很难更准确地定义这一点，因为在“得到它”之前，显然不可能知道一个人是否“得到了它”，所以它归结为一种直觉/区别：“是的，它有点有效”与“是的，看起来是对的”，人们不得不承认，他在这方面经常会出错。
也就是说，我特别关注的一点是“尽早干预”。作为一个初学者，我经常在主题化阶段“事后”调整东西，而通过一个或另一个钩子在处理链中更早地应用“修复”会容易得多。所以现在，每当我要“调整”主题层中的某些东西时，我会故意花一点时间来检查是否不能在之前的钩子中更干净地/兼容地完成这项工作。因为我预计Drupal-7会添加更多的挂钩选项，所以我会特别注意这一点，因为当添加新的modules.
- (common陷阱时，它通常会减少冲突和突然的“破坏东西”。)
嗯-主要是移植到早期，发现一个或多个需要的模块在新版本中根本不可用，或者只处于dev/alpha/早期测试版状态。因此，我要确保首先编译已使用/需要的模块的完整列表，列出它们的移植状态，并快速检查它们的问题队列。
除此之外，到目前为止，我一直对新版本及其改进感到非常满意，我期待着在移植时使用Drupal-7 again.
- (refactoring )
有人可能会说，移植本身就是一个相当大的重构，所以没有必要通过重构与移植无关的东西来增加复杂性。另一方面，如果你已经不得不将你的模块分解成碎片，为什么不利用这个机会进行一次大的检修呢？我会尝试根据复杂性来划分--对于大的/复杂的模块，我会尽可能的简单地移植，如果需要的话，以后会重构更多。对于较小的模块，这并不重要，因为引入细微bug的可能性应该是相当small.
- (other的东西)
..。需要考虑一下……
好的，其他的东西：
考虑到Drupals的“分段”、一步一步的更新策略，很难实现能够检测不同升级前状态并执行accordingly.的升级代码
https://stackoverflow.com/questions/1750972
复制相似问题