18

虽然我从 D4 系列开始就使用 drupal，但我只是开始使用 D6 进行专业开发，所以——尽管我进行了各种站点升级——我从来没有面临过将自己的代码移植到新版本的任务。

我知道 Drupal 社区会提供很多关于更改 API 和架构更改的技术支持（请参阅 D5-D6 的deadwood 模块，甚至这些 D6-D7 how-to 的存根模块 和主题）。

但是，我的问题更多的是在战略思维方面，或者换句话说，我正在寻找有关如何计划/实施/审查移植我自己的代码的过程的输入和建议，根据同事开发人员从以前的经验中学到了什么。一些例子：

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

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

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

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

4

1 回答 1

16

好问题，让我们看看：

  1. (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).

  2. (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.

  3. (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 :-/

  4. (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.

  5. (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.

  6. (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.

  7. (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.

于 2009-11-17T20:06:44.887 回答