資料來源：http://www.ithome.com.tw/itadm/article.php?c=48552
資料來源：http://www.ithome.com.tw/itadm/article.php?c=48552
| 選定專案之後，從最小規模出發，建立第一個里程碑。首先試著編譯一小部分程式碼，編譯通過之後，再追求執行的正確性。另外，在心理層面上，也需克服心理障礙，視混亂如無物，才能增加生產力。 |
| 回收、再利用開放源碼的專案時，首先要做的，是盡可能搜尋滿足需求的開放源碼專案，接著依照專案的版權類型、程式語言、執行平臺及作業系統、採用度、專案規模及專案相依性來進行評估。 採用度、專案規模及專案相依性，是相對而言影響力較小的三個條件。一般來說，經由前3個條件篩選，已經能去除大多數的選項。倘若還有多個專案在伯仲之間時，你可以盡量選擇其中採用度較高者、專案規模和你所需程式碼較接近者、以及專案相依性較低者。 相依性越高，拆解難度也越高 採用度越高的專案，代表越多人使用，通常品質較好，因為這樣子的專案，不僅運行過各式各樣的環境及組態，同時也已經久歷使用者的考驗，品質及穩定度會有一定的水準。 專案規模和你所需程式碼越接近，代表需要拆解掉及額外組裝的程式碼越少。專案規模過大，就得投注更多的心力才能了解它的內容。 專案的相依性也關係到拆解時需要耗費的功夫。許多專案都會使用其他專案的產出，例如使用這些專案所開發出來的程式庫，或應用程式框架。當一個專案使用越多其他專案的產出時，它們之間的相依性就越高。 當你使用相依性高於其他專案的專案，意謂著你的專案也得一併將這些專案納入。那麼你的專案不僅會多出許多不需要的東西，同時體積也會變得龐大。因此，挑選專案相依性越低的，不僅可以減少體積的浪費，同時也省去拆解的力氣。 綜合上述的條件，不見得有一個專案能夠以壓倒性的優勢雀屏中選。每個專案總是有優點也有缺點。不過，魚與熊掌不可兼得，還是得從中取捨，最後從眾多符合標準的專案中挑選出一個。而這個專案，就成了我們回收再利用的基礎專案。 了解程式架構，拆掉不需要的部分 在再利用時，有7個大原則是必須牢記於心的： ● 了解程式架構，拆解出自己所需的部分 ● 訂定不同的階段，從最小的里程碑開始 ● 先求能編譯，再求正確執行 ● 暫時忽略那些非第一個里程碑的內容 ● 適度的斬斷關聯性，尋找適當的替代品 ● 整理介面，去除不必要的元素 ● 做好心理建設，面對混亂 找到基礎專案做為修改的標的後，程式人得投入更多的心力，了解該專案的程式架構。了解架構的目的，最主要還是希望在接下來的工作中，能夠了解全貌。 你得更明確地界定那些部分是你要的、那些是不需要的，有些你需要的部分，又會相依於不想要的部分。這閱讀及了解的動作，或許不是一次到位。在整個回收再利用的過程中，你會持續地回頭檢視，提高閱讀時的「粒度」，或觸及之前未曾閱讀過的程式碼區域。 通常，我們的目的是拆掉基礎專案中不需要的部分。但實務上，我們在了解程式架構後，會把基礎專案當做是一個資源池（Resource Pool），另外建一個新的專案，挑出基礎專案中所需的原始檔，逐一放入新的專案。 從最小規模出發，建立第一個里程碑 當我們從「資源池」中挑出需要的原始檔後，就會面臨到最嚴酷的挑戰，也就是讓原始碼得以編譯。然而你所挑出來的原始檔，通常無法在一開始就能通過編譯。 只憑藉這些挑選出來的原始檔，是很難一次就編譯過關的，因為在挑選的過程中，會捨棄掉一些看起來不會用到的原始檔，卻又得倚靠它們才能編譯成功。所以，把原始檔挑到新專案的籃子裡後，首要之務便是試著編譯。 如果你嘗試著把籃子裡所有的原始碼湊在一塊兒編譯，那麼通常只會收到數之不盡的錯誤。當你面對這麼多的編譯錯誤時，恐怕都會有一股不知從何著手的無奈心情，油然而生。 我的建議是，不要嘗試一次將所有的東西整合起來，相反的，應該盡可能從最小的規模出發，先試著編譯一小部分的程式碼。這正是我所謂「訂定不同的階段，並且從最小的里程碑開始」。你可以為自己訂下不同階段的目標，分批從籃子中取出原始檔加至編譯中的專案。每次加入一批，也只解決這批衍生的編譯錯誤。如此，就不會遭遇到成千上萬的編譯錯誤，同時又不知如何解的困境。 為自己設定的第一個可編譯的範圍，就是第一個里程碑。事實上，要達到它是最關鍵的。在完成的過程中，你會為接下來其他階段的目標打好基礎建設。所以應該把完成第一個里程碑當做是最重要的一件事。 許多和其他階段有關，但在第一個階段可以忽略的事物，你可以直接忽略，等進到其他的階段時再處理。例如許多可能會造成編譯錯誤的地方，而這些在第一個階段卻又是用不著的，直接將它們「註解掉」也無妨。 總而言之，盡可能先求第一階段的範圍能通過編譯，即使執行不見得正確也無妨。編譯通過是第一階段最重要的工作，之後，你便有實際可以執行的程式碼，這個時候，再來追求執行的正確性。 去除不必要的元素，降低複雜性 在追求成功編譯的過程中，大多數情況是缺少材料。這材料若不是回到原始的專案中去找尋並切割出，就是要自製填補或是尋找其他的替代品。通常，需要自行製造或是尋找其他替代品的情況，多半都是因為在原始專案中存在的程式碼片段有著極高的相依性。例如，某段動用到GList（跨平臺程式庫GLib中的一個資料結構）的程式碼，倘若直接含入整個GLib，便會增加編譯時的複雜性，也會使得專案中多出了許多不必要的東西。 倘若所需的部分，並沒有大量引用到GLib中所提供的功能，那麼，適度於此刻斬斷與GLib的關聯性，看起來就像是個不得不為的壯士斷腕。以GList所提供的功能來說，其實很容易自行實作，或是找到其他相依性低的實作品。 在追求通過第一階段的編譯時，你將持續地添加東西、也持續地移除或暫時移除某些東西。有時，由於基礎專案提供多於你所需的功能，所以取自基礎專案的函式、資料結構定義、介面，都多於所需。在這來來回回，既增加又移除的過程，倘若心有餘力，不妨整理這些函式或定義的介面、去除不必要的元素。使介面變得更清爽簡潔，可讀性提高，也更容易編譯成功。 克服心理障礙，視混亂如無物 除了技巧之外，心理層面的建設也同樣的重要。越是優秀的程式人，越難克服心理障礙，就是看不慣別人的程式碼。從排名、命名慣例、到程式架構設計等。因為看不慣，所以常常會忍不住動手修改。 在再利用程式碼時，請務必克服這個心魔。畢竟，我們想追求的是生產力，倘若還得幫別人的程式碼重新美容，那麼生產力則大打折扣。此時，面對混亂的程式碼，要能視如無物。等到日後時間允許，再利用重構的方法，漸漸修正你覺得有問題的地方。 作者簡介： 王建興 清華大學資訊工程系的博士研究生，研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。 |
資料來源：http://www.ithome.com.tw/itadm/article.php?c=48552
全站熱搜
留言列表
測試用 (1)
