《开放原始码的回收与再利用.ppt》由会员分享，可在线阅读，更多相关《开放原始码的回收与再利用.ppt（33页珍藏版）》请在三一办公上搜索。
1、開放原始碼的回收與再利用,Qing(Email/MSN)2008/10/13,Google時代的程式撰寫,Google時代的來臨也加快了程式員的各種面向速度的提昇學習速度錯誤排除的速度Google是找到問題答案的最佳途徑，你會遇到的問題，別人多半也會IM軟體的流行也使得同儕網絡變成好的解題方式開發的速度開放原始碼質與量俱皆大增透過搜尋引擎極易取得所需的程式碼,前後Google時代的程式員的差異(1/3),學習的方式不同前Google時代的程式員：透過書籍或文章後Google時代的程式員：除了書籍或文章外，更從開放原始碼中學習解決問題或麻煩的方式不同前Google時代的程式員：嘗試、摸索，詢問前
2、輩，在線上社群或論壇BBS發問後Google時代的程式員：除了前Google時代的方法之外，更重視透過搜尋引擎尋找問題的原因、解法，甚至現成的程式碼,前後Google時代的程式員的差異(2/3),程式碼的來源不同前Google時代的程式員：一手打造後Google時代的程式員：除了自行撰寫必要的程式碼外，更善用網路上隨手可得的程式碼，加以裁切、添加、整合重視的技能取向不同前Google時代的程式員：撰寫品質佳、易於重覆運用的程式碼,後Google時代的程式員需要的新技能,建立好的整合架構善於搜尋所面臨問題的解決方案，並從中快速吸取新知善於搜尋既有的程式碼善於追蹤了解文件不足的程式碼善於拆解、修繕
3、既有的程式碼，以符合自己的目的,人們都拿開放原始碼專案做什麼？,使用開放原始碼專案產出的軟體大多數人從開放原始碼專案中學習reuse開放原始碼專案中的程式碼recycle開放原始碼專案中的程式碼,Musica：一個大量運用回收開放原始碼的專案,Musica：一個從公開音訊（例如數位廣播或網路廣播）做自動截斷歌曲的軟體Winamp的iPod sync模組ffmpegMPlayerLAME,Reuse vs.Recycle,Code Reuse不需要碰觸到原始碼就可以達到運用的目的需要原始程式碼設計完善夠彈性夠周延，或程式運氣夠好，遇到剛好滿足目的的程式碼Code Recyce程式碼來自世界各地，
4、其目的或範圍往往不盡人意需要施以回收再加工的作業，才能夠進一步加以利用,程式碼的重新打造 vs.回收再生,對一名工匠而言，倘若要製作一張椅子，他可以找到原始的木材，重頭開始製作椅子倘若有二手回收的家具，他也可以找到一張適用的木頭茶几 重新修整這張茶几 添加新的材料成為一張具有新面貌的椅子學問在那？如何找到好的資源施以最小幅度的心力，達成相同的目的,程式碼回收與再利用的方法,在網路上搜尋可用的原始碼，並選擇最適合的 了解程式架構，拆解出自己所需的部份 訂定不同的階段，從最小的里程碑開始 做細部拆解，先求能編譯，再求正確執行 暫時忽略非第一個里程碑的內容 適度的斬斷關聯性，尋找適當的替代品 整理介
5、面，去除不必要的元素 做好心理建設，面對混亂 跨出成功的第一步,在網路上搜尋可用的原始碼，並選擇最適合的,選擇執行平台相符或相似者相似時仍需花費移植心力選擇程式語言相符者 Java和C#之間互換較為容易選擇版權宣告合適者 選擇範圍接近者 選擇使用者眾者 選擇相依性低的 盡量不要選擇依賴程式庫多的專案,了解程式架構，拆解出自己所需的部份,即使已經盡量的選擇範圍接近自己所需的專案，但多出的部份仍需適當的拆解拆解前要先了解程式架構閱讀能取得的文件程式碼的追蹤如果不了解程式架構不知在此架構下的拆解的方式不知那些可以拆那些不能拆不知那些可以先不拆等日後再拆,訂定不同的階段，從最小的里程碑開始,在原始碼層
6、次的拆解告一個段落後，程式碼通常連編譯都無法編譯必須制定幾個不同階段的目標，並且從最小的里程碑開始出發達到第一個里程碑具有十分重要的象徵性意義 代表著你能夠正確的編譯而且執行（即使功能不太正確或功能尚不完備）但只要能夠達到第一個里程碑，之後的問題幾乎都能輕易迎刃而解,做細部拆解，先求能編譯，再求正確執行,在開放原始碼的回收與再利用活動中，最難的是就是讓拆解下來的原始碼成功的編譯 拆解出來的部份往往相依於未被拆解的原專案組成header file中的定義或巨集原專案中的其他函式為了成功的編譯，你需要再回到基礎專案中，把所需的部份拆解出來 此即所謂細部拆解細部拆解並不會直接把整個原始碼檔案移至回收
7、專案中，僅移動在基礎專案中所需的部份 在這個階段，會反覆的看到許許多多的編譯錯誤 逐一解決各個編譯上的錯誤 需要的耐心耐心加耐心,暫時忽略非第一個里程碑的內容,矇上眼睛假裝看不見有許多編譯錯誤是第一個里程碑後才會需要的適時的將它們註解掉，以求通過編譯檢查是一個很好的手段 被註解掉的部份，在通過第一個里程碑後，解決其編譯錯誤的方案，也會在處理第一個里程碑的過程中產生此時再取消對它們的註解，就可以套用這些解決方案,適度的斬斷關聯性，尋找適當的替代品,許多開放原始碼的專案是盤根錯節有時編譯的錯誤是來自於缺少某個函式或類別，而如果要加入這個函式，必須引入一大堆東西必須考慮適度的斬斷和該函式的關聯性 E
8、x,GList.c/GList.h相依於GLib其他部份尋找替代品的兩個途徑 自己撰寫 再找現成的開放原始碼 運用替代品的方式修整介面，保持作用，符合目的,整理介面，去除不必要的元素,被回收的程式碼本身的目標往往和你運用的目標不盡相同 其函式或類別的介面長相就會和你所需的不同 介面中的元素會較我們所需的為多 因為拆解的關係，有許多編譯錯誤會來自於未含入介面中額外多出的元素去除一些不必要的元素，並且重新整理這些介面的長相 得到第一個可以編譯的版本,做好心理建設，面對混亂,就算張開眼睛也仍然看不見別人的程式碼習慣風格和你必然不同不要浪費時間在重新整理上請先做好心理建設，讓自己能夠面對自己覺得混亂的
9、程式碼，視眼前之混亂如無物 有空閒時間，再套用refactoring的技巧，逐步的改善回收程式的結構,跨出成功的第一步,成功的達成第一個里程碑後，便逐一的依照同樣的方式加入後續的里程碑達成的速度會愈來愈快,Case Study：視訊檔案的格式探測,需求：檢查給定的視訊檔案是否屬於特定的數種格式限制：C/C+，在Win32上執行，編譯後大小必須在100KB以內,在網路上搜尋可用的原始碼，並選擇最適合的,ffmpeg有許多人使用，而且程式語言是C，在Win32平台上編譯不致於有太多問題ffmpeg的libavformat有提供此類的功能,了解程式架構，拆解出自己所需的部份,由上而下了解程式架構先找
10、到一段應用libavformat的範例av_register_all();/Open video fileif(av_open_input_file(,展開追蹤原始碼,善用grep工具（Win32上可用Windows Grep）逐一檢查dump_format()前的各個函式void av_register_all(void)static int inited=0;if(inited!=0)return;inited=1;avcodec_init();avcodec_register_all();mpegps_init();mpegts_init();./*一堆 xxxx_init()*/,採D
11、FS展開深度優先搜尋,接下來往mpegps_init()展開，利用grep找出它在mpeg.c中 int mpegps_init(void)#ifdef CONFIG_MUXERS av_register_output_format(,續追av_register_input_format(),void av_register_input_format(AVInputFormat*format)AVInputFormat*p;p=,看看AVInputFormat定義於何處,利用grep找出在avformat.htypedef struct AVInputFormat const char*nam
12、e;const char*long_name;int priv_data_size;int(*read_probe)(AVProbeData*);int(*read_header)(struct AVFormatContext*,AVFormatParameters*ap);int(*read_packet)(struct AVFormatContext*,AVPacket*pkt);int(*read_close)(struct AVFormatContext*);int(*read_seek)(struct AVFormatContext*,int stream_index,int64_t
13、 timestamp,int flags);int64_t(*read_timestamp)(struct AVFormatContext*s,int stream_index,int64_t*pos,int64_t pos_limit);int flags;const char*extensions;int value;int(*read_play)(struct AVFormatContext*);int(*read_pause)(struct AVFormatContext*);struct AVInputFormat*next;AVInputFormat;,判斷AVInputForma
14、t各欄位的作用,用非物件導向的方式來實作物件導向的多型 有很多一看就知道是探測格式時不會需要的我們應該要特別注意read_probe及extension兩欄位,訂定不同的階段，從最小的里程碑開始,我們試著訂出三個階段 探測mpegps格式 探測mpegts格式 探測其他格式試著編譯，一定會發生很多問題 結構之間的環環相扣：為了AVInputFormat中的read_header，我們得括入AVFormatContext和AVFormatParameters 後來我們會因為更了解而發現這個函式指標根本不需要但此刻的我們只好先把它們先加入 在utils.c中的眾多函式同樣的也被清的只剩下：av_r
15、egister_input_format()、match_ext()、av_probe_input_format(),適度的斬斷關聯性，尋找適當的替代品,av_probe_input_format()會用到許多utility函式av_realloc()、get_buffer()、url_open()、url_fseek()、url_fclose()這些函式看起來就是標準C函式庫中的函式差不多。所以決定退化回標準C函式庫中函式 改用malloc()來代替av_realloc()及get_buffer()的作用；改用fopen()來代替url_open()；改用fseek()來代替url_fsee
16、k()；改用fclose()來代指url_fclose()要建立防火牆，不能讓相依性的火一直蔓延的燒,整理介面，去除不必要的元素,在這過程中，我們愈來愈了解整體的運作方式 所以我們發現AVInputFormat裡的結構有很多欄位是不必要的 只需要保用read_probe這個函式指標即可 其他的部份我們都可以拿掉 更可以順手拿到一些不必要的資料結構定義 例如拿掉了read_header可以一舉拿掉AVFormatContext及AVFormatParameters的定義,做好心理建設，面對混亂,在這個過程中，我既不去修改它的命名慣例，更不會去重新排版 我把所有取出來的程式碼包在一塊，把它當做一個黑箱子來使用 有些取自標頭檔的定義也許還有精簡的可能性，但是先將它擱在一塊 此刻我們需要的只是生產力短期間內透過回收和整理取得我們想要的產物,結論,最後支援十種格式以上的這個格式探測程式庫，大小不到40KB幾乎沒有寫下半行程式碼，但憑藉著回收和整理的技巧，只需一晚，我們得到了一個相當實用的程式庫 原先對各視訊檔案格式完全不通的我，也能達成這個目標，而且在這個過程中對視訊檔案格式也有一定的認識開放原始碼的各種程式片段俯拾可得 需要的是化桌子為椅子的功夫,Q&A,Thanks,
