從Drupal 6升級到Drupal 7：最好的程序員的做法？

Question

儘管我從D4系列開始就使用Drupal，但我只用D6開始專業開發，所以 - 儘管我做了各種網站升級 - 我從來沒有面臨不得不將我自己的代碼移植到新的版。

我知道Drupal社區會想出很多關於改變API和架構變化的技術支持（見deadwood module爲D5，D6，甚至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. （早期採用者與觀望）
   使用Drupal的，因爲在4.7版本中，我們一直在等待新的主要版本，甚至想轉出前，至少第一次正式發佈。在Drupal 6中，我們在移植我們的第一個站點之前等待了views模塊，而且我們在Drupal-5上仍然有一些小型項目，因爲它們工作得很好，並且只要客戶爲我們的客戶額外支付賬單就很難證明這一點。它仍然有維護/安全修復程序。一天只有這麼多時間，總會有這些積壓的bug修復，添加的功能等等，所以沒有必要使用未完成的技術，而有更多迫在眉睫的事情可以立即使我們的客戶受益。如果我們必須維護一個或多個「官方」貢獻模塊，現在這肯定會有所不同，因爲提供早期端口將是一件好事。
   我在這裏遇到了一些麻煩 - 作爲一個早期採用者，肯定會給社區帶來好處，因爲有人必須在問題得到解決之前找到問題，但另一方面，一小時一小時地打一點點商業意義如果你只是等了一會兒，其他人可能會發現/修復的錯誤。只要我不得不爲生計做到這一點，我需要看我的資源，試圖罷工服務社會並從中獲益之間可以接受的平衡： -/

4. （質量標準）
   「如果它有效，我很高興「只是不削減它，因爲我不想只在一瞬間快樂，但明天也是如此。所以我的一個質量標準是，我需要（有點）確定，爲了不只是讓事情順利運作，而且讓他們像他們應該做的那樣工作，我已經足夠好地培養了新的概念。現在很難更準確地定義，因爲在「得到它」之前知道是否「得到它」顯然是不可能的，所以它歸結爲「是的，它有點作用」與「是的」 ，看起來是正確的「，而且人們必須承認，他經常會在這方面出現錯誤。
   也就是說，我正在尋找的一個特定點是'儘早干預'。作爲一名初學者，我經常在主題階段調整'事實'之後的東西，而通過一個鉤子或另一個鉤子在處理鏈中早些時候應用'修復'會更容易。所以，現在，無論何時我要調整主題層中的某些內容，我都會特意抽出一點時間檢查一下，在早期的鉤子中，這樣做是否能夠更加乾淨/兼容。正如我期望Drupal-7添加更多的hooking選項，這是我會特別注意的，因爲它通常會減少衝突並在添加新模塊時突然「破壞東西」。

5. （常見的陷阱）
   好 - 主要是移植到年初，找出事後/在一個或多個需要的模塊之間沒有可用於新版本可言，或僅在開發/阿爾法/早beta狀態。所以我會確保首先編譯一個完整的使用/需要的模塊列表，列出它們的移植狀態，並快速檢查它們的問題隊列。
   除此之外，我到目前爲止一直對非常滿意對新版本及其改進感到滿意，並且我很期待Drupal-7的再次發佈。

6. （重構同時移植）
   可以說，移植本身就是一種相當大的重構，所以沒有必要通過重組非移植相關的東西，以增加複雜性。另一方面，如果你已經不得不將模塊碎片化，那麼爲什麼不利用這個機會進行大修呢？我會嘗試根據複雜性繪製一條線 - 對於大型/複雜模塊，我會盡可能直線地完成端口，並且如果需要的話可以稍後重構。對於較小的模塊，它應該沒有問題，因爲引入細微錯誤的可能性應該很小。

7. （其他的東西）
   ...必要去想它...

---

好了，其他的東西：

• 資源需求 - 考慮一些Drupal-7線程，看起來他們可能會上升，所以這應該評估之前，移植較小的網站，坐在一個共享/限制託管帳戶。

• 最新版本首先 - 這一點在升級指南中相當明顯，並且始終強調，但值得一提的是：在升級代碼高度升級之前，先將核心和所有模塊升級到最新的當前版本可能依賴於最新的表/數據結構才能正常工作。鑑於Drupals'零碎'，一步一步更新策略，這將是很難實現升級代碼，將檢測到不同的升級前狀態，並採取相應的行動。