(когда начинать портирование)
Это, безусловно, зависит от сложности модулей для переноса. Если есть действительно сложные / большие, может быть полезно начать рано, чтобы найти хитрые места, не находясь под давлением. Для меньших / стандартных я бы позже попытался найти больший временной интервал, в котором я могу портировать многие из них подряд, чтобы быстро запомнить запрограммированные вещи (и извлечь выгоду из, вероятно, улучшенной документации).
(тестовое покрытие)
Обычно я бы сказал, что желательно иметь хорошее тестовое покрытие перед началом рефакторинга / портирования. Но, учитывая, что Drupal-7 вносит существенные изменения в среду тестирования, перенося ее в ядро, я ожидаю, что в любом случае потребуется переписать значительное количество тестов. Поэтому, если нет необходимости поддерживать версии Drupal-6 после миграции, я бы сэкономил время / проблемы и стремился к увеличению охвата после портирования.
(ранний усыновитель и ожидание)
Используя Drupal начиная с версии 4.7, мы всегда ждали по крайней мере первого официального выпуска новой основной версии, прежде чем даже думать о портировании. В Drupal 6 мы ждали модуля представлений, прежде чем портировать наш первый сайт, и у нас все еще есть несколько небольших проектов на Drupal-5, поскольку они работают просто отлично, и нашим клиентам будет сложно оправдать дополнительный счет, пока все еще есть исправления обслуживания / безопасности для этого. Так много времени в день, и всегда есть куча ошибок, которые нужно исправить, функции, которые нужно добавить, и т. Д., Так что бесполезно играть с незавершенными технологиями, в то время как есть более неизбежные вещи, которые могут немедленно принести пользу нашим клиентам. Теперь это, конечно, было бы по-другому, если бы нам пришлось поддерживать один или несколько «официальных» дополнительных модулей, поскольку было бы неплохо предложить ранний порт.
Здесь я немного запутался - то, что ранний усыновитель, безусловно, приносит пользу сообществу, так как кто-то должен найти эти ошибки, прежде чем они могут быть исправлены, но, с другой стороны, бессмысленно бороться с ошибками час за часом другие могли бы найти / исправить, если бы вы просто подождали немного дольше. Пока я должен зарабатывать на жизнь, мне нужно следить за своими ресурсами, пытаясь найти приемлемый баланс между служением сообществу и извлечением из него пользы: - /
(стандарты качества)
«Если это работает, я счастлив», но это не значит, что я не хочу быть счастливым только на мгновение, но и завтра. Таким образом, один из моих стандартов качества заключается в том, что я должен быть (несколько) уверен, что я достаточно хорошо усвоил новые концепции, чтобы не просто заставить вещи работать, но и заставить их работать так, как они должны. Сейчас это трудно определить более точно, так как, очевидно, невозможно узнать, «кто-то получил», прежде чем «получить его», поэтому все сводится к интуитивному чувству / различению «да, это вроде работает» против «да» это выглядит правильно », и нужно признать, что он будет регулярно ошибаться по этому поводу.
Тем не менее, один конкретный момент, на который я обращаю внимание, это «вмешиваться как можно раньше». Как новичок, я часто подправлял материал «по факту» на этапе создания тем, в то время как было бы намного проще применить «исправление» ранее в цепочке обработки с помощью одного крючка или другого. Так что сейчас, когда я собираюсь «что-то скорректировать» в слое темы, я намеренно беру небольшой тайм-аут, чтобы проверить, не может ли это быть сделано более чисто / совместимо в хуке раньше. Поскольку я ожидаю, что Drupal-7 добавит еще больше опций перехвата, на это я буду обращать особое внимание, так как обычно он уменьшает конфликты и внезапные «поломки» при добавлении новых модулей.
(общие подводные камни)
Хорошо - в основном, портирование на ранние версии, выяснение впоследствии / между тем, что один или несколько необходимых модулей вообще не были доступны для новой версии или только в состоянии dev / alpha / ранней бета-версии. Поэтому я должен сначала скомпилировать полный список используемых / необходимых модулей, перечислив их состояние портирования, а также быстро проверить их очереди выдачи.
Кроме того, я до сих пор всегда был очень доволен новыми версиями и их улучшениями, и я с нетерпением жду появления Drupal-7.
(рефакторинг при портировании)
Можно сказать, что портирование само по себе является довольно большим рефакторингом, поэтому нет необходимости увеличивать его сложность путем реструктуризации не связанных с портированием вещей. С другой стороны, если вам все равно придется разбивать свои модули на куски, почему бы не использовать возможность сделать капитальный ремонт? Я бы попытался нарисовать линию, основанную на сложности - для больших / сложных модулей я бы сделал порт как можно более прямым и реорганизовал бы его позже, если потребуется. Для небольших модулей это не должно иметь большого значения, так как вероятность появления незначительных ошибок должна быть довольно небольшой.
(прочее)
... нужно подумать об этом ...