从 Drupal 6 升级到 Drupal 7：最佳程序员实践？
虽然我从 D4 系列开始就使用 drupal，但我只是从 D6 开始对其进行专业开发，因此 - 尽管我进行了各种站点升级 - 我从未面临过必须移植我自己的代码的任务到新版本。
我知道 Drupal 社区将会针对 API 变更和架构变更提供大量技术支持（请参阅 deadwood 模块 对于 D5-D6 甚至 D6-D7 操作指南的这些存根 模块 和主题< /a>）。
然而，我的问题更多地是在战略思维方面，或者换句话说，我正在寻找有关如何计划/实施/审查流程的意见和建议根据同事开发人员从以前的经验中学到的知识，移植我自己的代码。一些例子：
- 您是否建议我一有时间就开始移植我的模块，并维持并发 D7 一段时间（这样我就为 D 日“做好准备”）或者您是否建议等待移植实际上即将到来的那一天，然后将模块升级到 D7 并放弃 D6 版本？
- 只有我的一些模块具有完整的测试覆盖率。您是否会建议完成 D6 版本的测试覆盖范围，以便让所有测试都能检查 D7 端口，或者您会建议在移植时编写我的测试指导，以测试 D7 版本吗？
- 您是否发现成为早期采用者可以在新功能和更好的 API 方面给您带来优势，或者您是否发现延迟转换以便利用大量现成的 contrib 模块更方便？
- 您是否为自己设定了质量标准/评估标准，或者您只是将标准设置为“如果有效，我很高兴”？为什么？如果您设定了某些标准或目标，它们在哪里/将是什么？他们如何帮助你？
- 您过去遇到过并且您认为适用于 D6-D7 移植过程的常见陷阱吗？
- 移植是进行一些重构的好时机还是只会让一切变得更加复杂而无法重新组合在一起？
- ...
这些问题并不是详尽的列表，但我希望它们能让我了解我正在寻找什么样的信息。我宁愿说：无论你认为相关但我上面没有列出的内容都会得到“加号”！ :)
如果我没有能够足够清楚地表达自己的意思，请发表评论，其中包含您认为我应该在问题中添加的信息。预先感谢您的宝贵时间！
PS：是的，我知道...D7 尚未发布，重要的贡献模块需要几个月的时间才能升级...但开始思考永远不会太早！ :)
Although I am using drupal since the D4 series, I only started developing professionally for it with D6, so - despite I did various site upgrades - I was never faced by the task of having to port my own code to a new version.
I know the Drupal community will come up with lot of technical support about changed API's and architectural changes (see the deadwood module for D5-D6 or even these stubs of D6-D7 how-to's for modules and themes).
However what I am looking for with my question is more in the line of strategy thinking, or in other words, I am looking for inputs and advice on how to plan / implement / review the process of porting my own code, in the light of what colleague developers learned by previous experience. Some example:
- Would you advice to begin to port my modules as soon as I have time for doing it, and to maintain a concurrent D7 for some time (so I am "prepared" for the D-day) or would you advice to rather wait for the day in which the port will be actually imminent and then upgrade the modules to D7 and drop the D6 version?
- Only some of my modules have full test coverage. Would you advice to complete test coverage for the D6 version so to have all tests working to check the D7 port, or would you advice to write my test directing at porting time, to test the D7 version?
- Did you find that being an early adopter gives you an edge in terms of new features and better API's or did you rather find that is more convenient to delay the conversion so as to leverage the larger amount of readily available contrib modules?
- Did you set for yourself quality standards / evaluation criteria or did you just set the bar to "if it works, I'm happy"? Why? If you set certain standards or goals, what did they where / what will they be? How did they help you?
- Are there common pitfalls that you experienced in the past and that you think are applicable to the D6-D7 porting process?
- Is porting a good moment to do some refactoring or it is just going to make everything more complex to be put back together?
- ...
These questions are not an exhaustive list, but I hope they give an idea of what kind of information I am looking for. I would rather say: whatever you think is relevant and I did not list above gets a "plus"! :)
If I did not manage to express myself clearly enough, please post a comment with the info you think I should add in the question. Thank you in advance for your time!
PS: Yes I know... D7 is not yet out and it will take months before important contrib modules will be upgraded... but it's never too early to start thinking! :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好问题，让我们看看：
（何时开始移植）
这当然取决于要移植的模块的复杂性。如果确实存在复杂/大型的问题，那么尽早开始可能会很有用，以便在没有压力的情况下找到棘手的地方。对于较小/标准的，我会尝试稍后找到一个更大的时间段，在那里我可以连续移植其中的许多内容，以便快速记住常规内容（并从可能改进的文档中受益）。
（测试覆盖率）
通常我会说，在开始重构/移植之前拥有良好的测试覆盖率肯定是可取的。但鉴于 Drupal-7 通过将测试框架移至核心而引入了有关测试框架的重大更改，我预计无论如何都需要重写大量测试。因此，如果迁移后不需要维护 Drupal-6 版本，我会节省时间/麻烦，并致力于在移植后提高覆盖率。
（早期采用者与观望者）
从 4.7 版本开始使用 Drupal，我们总是至少等待新主要版本的第一个正式发布，然后才考虑移植。对于 Drupal 6，我们在移植我们的第一个站点之前等待了视图模块，并且我们在 Drupal-5 上仍然有一些较小的项目，因为它们运行得很好，只要仍有维护/安全修复。一天的时间太多了，总是有积压的错误需要修复、需要添加的功能等等，因此，在有更多迫在眉睫的事情要做、可以立即使我们的客户受益的情况下，玩未完成的技术是没有用的。现在，如果我们必须维护一个或多个“官方”贡献的模块，情况肯定会有所不同，因为提供早期移植将是一件好事。
我在这里有点进退两难——作为早期采用者肯定对社区有利，因为有人必须先发现错误才能修复，但另一方面，与错误作斗争一小时又一小时没有什么商业意义如果您再等一会儿，其他人可能已经找到/修复了。只要我必须以此为生，我就需要注意我的资源，努力在服务社区和从中受益之间取得可接受的平衡：-/
（质量标准）
“如果有效，我就很高兴”并不能解决这个问题，因为我不想只高兴一时，但明天也一样。因此，我的质量标准之一是，我需要（在某种程度上）确定我足够好地“理解”新概念，以便不仅使事情发挥作用，而且使它们按照应有的方式发挥作用。现在很难更准确地定义这一点，因为在“得到它”之前显然不可能知道一个人是否“得到它”，所以它归结为“是的，它有点管用”与“是的”的直觉/区别，看起来是对的”，人们必须接受他在这一点上经常犯错的事实。
也就是说，我特别关注的一点是“尽早干预”。作为一名初学者，我经常在主题阶段“事后”调整内容，而通过一个或另一个钩子在处理链的早期应用“修复”会容易得多。所以现在，每当我要“调整”主题层中的某些内容时，我都会故意花一点时间来检查是否可以在之前的挂钩中更干净/兼容地完成此操作。正如我期望 Drupal-7 添加更多挂钩选项，这是我会特别注意的事情，因为它通常会减少添加新模块时的冲突和突然的“破坏”。
（常见陷阱）
嗯 - 主要是移植到早期，之后/中间发现一个或多个所需的模块根本不适用于新版本，或者仅处于开发/阿尔法/早期测试状态。因此，我会确保首先编译已使用/需要的模块的完整列表，列出它们的移植状态，并快速检查它们的问题队列。
除此之外，到目前为止，我一直对新版本及其改进感到非常满意，并且我期待再次使用 Drupal-7。
（移植时重构）
可以说，移植本身就是一种相当大的重构，因此无需通过重构与移植无关的内容来增加复杂性。另一方面，如果您已经必须将模块撕成碎片，为什么不利用这个机会对其进行重大检修呢？我会尝试根据复杂性画一条线 - 对于大型/复杂模块，我会尽可能直接地进行端口，并在需要时进行更多重构。对于较小的模块，这并不重要，因为引入细微错误的可能性应该相当小。
（其他内容）
...需要考虑一下...
好吧，其他的东西：
资源需求 - 考虑到一些 Drupal-7 线程，看起来它们很可能会上升，所以在移植较小的站点之前应该对此进行评估 共享/受限托管帐户
首先是最新版本 - 这一点相当明显，并且在升级指南中总是强调，但仍然值得一提：在进行重大升级之前，首先将核心和所有模块升级到最新的当前版本，因为升级代码很可能会依赖最新的表/数据结构才能正常工作。考虑到 Drupals 的“零碎”、一次一步的更新策略，很难实现能够检测不同的升级前状态并采取相应行动的升级代码。
Good questions, so let's see:
(when to start porting)
This certainly depends on the complexity of the modules to port. If there are really complex/large ones, it might be useful to start early in order to find tricky spots while not being under pressure. For smaller/standard ones, I'd try to find a bigger time slot later on where I can port many of them in a row in order to get the routine stuff memorized quickly (and benefit from the probably improved documentation).
(test coverage)
Normally I'd say that having a good test coverage before starting refactoring/porting would certainly be advisable. But given that Drupal-7 introduces a major change concerning the testing framework by moving it to core, I'd expect the need to rewrite a significant amount of tests anyway. So if there is no need to maintain the Drupal-6 versions after the migration, I'd save the time/trouble and aim for increased coverage after the porting.
(early adopter vs. wait and see)
Using Drupal since the 4.7 version, we have always waited for at least the first official release of a new major version before even thinking about porting. With Drupal 6, we waited for the views module before porting our first site, and we still have some smaller projects on Drupal-5, as they are working just fine and it would be hard to justify the extra bill for our clients as long as there are still maintenance/security fixes for it. There is just so much time in a day and there is always this backlog of bugs to fix, features to add, etc., so no use playing with unfinished technology while there are more imminent things to do that would immediately benefit our clients. Now this would certainly be different if we'd have to maintain one or more 'official' contributed modules, as offering an early port would be a good thing.
I'm a bit in a bind here - being an early adopter certainly benefits the community, as someone has to find that bugs before they can get fixed, but on the other hand, it makes little business sense to fight hour after hour with bugs others might have found/fixed if you'd just waited a bit longer. As long as I have to do this for a living, I need to watch my resources, trying to strike an acceptable balance between serving the community and benefiting from it :-/
(quality standards)
"If it works, I'm happy" just doesn't cut it, as I don't want to be happy momentarily only, but tomorrow as well. So one of my quality standards is that I need to be (somewhat) certain that I 'grokked' new concepts well enough in order to not just makes things work, but make them work like they should. Now this is hard to define more precisely, as it is obviously impossible to know if one 'got it' before 'getting it', so it boils down to a gut feeling/distinction of 'yeah, it kinda works' vs. 'yup, that looks right', and one has to accept that he will quite regularly be wrong about this.
That said, one particular point I'm looking out for is 'intervene as early as possible'. As a beginner, I often tweaked stuff 'after the fact' during the theming stage, while it would have been much easier to apply the 'fix' earlier in the processing chain by means of one hook or the other. So right now, whenever I'm about to 'adjust' something in the theme layer, I deliberately take a small time out to check if this can not be done more cleanly/compatible within a hook earlier on. As I expect Drupal-7 to add even more hooking options, this is something I will pay extra attention to, as it usually reduces conflicts and sudden 'breaking of stuff' when adding new modules.
(common pitfalls)
Well - mainly porting to early, finding out afterwards/in between that one or more needed modules were not available for the new version at all, or only in dev/alpha/early beta state. So I'd make sure to compile a complete list of used/needed modules first, listing their porting state, along with a quick inspection of their issue queues.
Besides that, I have so far always been very pleased with the new versions and their improvements, and I'm looking forward for Drupal-7 again.
(refactoring while porting)
One could say that porting is a rather large refactoring in itself, so there is no need to add to the complexity by restructuring non porting related stuff. On the other hand, if you already have to shred your modules to pieces anyway, why not use the opportunity to make it a major overhaul? I'd try to draw a line based on complexity - for big/complex modules, I'd do the port as straight as possible, and refactor more later on, if need be. For smaller modules, it shouldn't really matter, as the likelihood of introducing subtle bugs should be rather small.
(other stuff)
... need to think about it ...
Ok, other stuff:
Resource needs - given some of the Drupal-7 threads, it looks like they are likely to go up, so this should be evaluated before porting smaller sites that sit on a shared/restricted hosting account.
Latest versions first - This one is rather obvious and always stressed in the upgrade guides, but nevertheless worth mentioning: Upgrade core and all modules to their latest current version first before doing a major upgrade, as the upgrade code is highly likely to depend on the latest table/data structures to work correctly. Given Drupals 'piecemeal', one step at a time update strategy, it would be very hard to implement upgrade code that would detect different pre-upgrade states and acted accordingly.