开放原始码的回收与再利用

開放原始碼的回收與再利用[e-mail](Email/MSN)2008/10/13Google時代的程式撰寫Google時代的來臨也加快了程式員的各種面向速度的提昇學習速度錯誤排除的速度Google是找到問題答案的最佳途徑，你會遇到的問題，別人多半也會IM軟體的流行也使得同儕網絡變成好的解題方式開發的速度開放原始碼質與量俱皆大增透過搜尋引擎極易取得所需的程式碼前後Google時代的程式員的差異(1/3)學習的方式不同前Google時代的程式員：透過書籍或文章後Google時代的程式員：除了書籍或文章外，更從開放原始碼中學習解決問題或麻煩的方式不同前Google時代的程式員：嘗試、摸索，詢問前輩，在線上社群或論壇BBS發問後Google時代的程式員：除了前Google時代的方法之外，更重視透過搜尋引擎尋找問題的原因、解法，甚至現成的程式碼前後Google時代的程式員的差異(2/3)程式碼的來源不同前Google時代的程式員：一手打造後Google時代的程式員：除了自行撰寫必要的程式碼外，更善用網路上隨手可得的程式碼，加以裁切、添加、整合重視的技能取向不同前Google時代的程式員：撰寫品質佳、易於重覆運用的程式碼後Google時代的程式員需要的新技能建立好的整合架構善於搜尋所面臨問題的解決方案，並從中快速吸取新知善於搜尋既有的程式碼善於追蹤了解文件不足的程式碼善於拆解、修繕既有的程式碼，以符合自己的目的人們都拿開放原始碼專案做什麼？使用開放原始碼專案產出的軟體大多數人從開放原始碼專案中學習reuse開放原始碼專案中的程式碼recycle開放原始碼專案中的程式碼Musica：一個大量運用回收開放原始碼的專案Musica：一個從公開音訊（例如數位廣播或網路廣播）做自動截斷歌曲的軟體Winamp的iPodsync模組ffmpegMPlayerLAMEReusevs.RecycleCodeReuse不需要碰觸到原始碼就可以達到運用的目的需要原始程式碼設計完善夠彈性夠周延，或程式運氣夠好，遇到剛好滿足目的的程式碼CodeRecyce程式碼來自世界各地，其目的或範圍往往不盡人意需要施以回收再加工的作業，才能夠進一步加以利用程式碼的重新打造vs.回收再生對一名工匠而言，倘若要製作一張椅子，他可以找到原始的木材，重頭開始製作椅子倘若有二手回收的家具，他也可以找到一張適用的木頭茶几重新修整這張茶几添加新的材料成為一張具有新面貌的椅子學問在那？如何找到好的資源施以最小幅度的心力，達成相同的目的程式碼回收與再利用的方法在網路上搜尋可用的原始碼，並選擇最適合的了解程式架構，拆解出自己所需的部份訂定不同的階段，從最小的里程碑開始做細部拆解，先求能編譯，再求正確執行暫時忽略非第一個里程碑的內容適度的斬斷關聯性，尋找適當的替代品整理介面，去除不必要的元素做好心理建設，面對混亂跨出成功的第一步在網路上搜尋可用的原始碼，並選擇最適合的選擇執行平台相符或相似者相似時仍需花費移植心力選擇程式語言相符者Java和C#之間互換較為容易選擇版權宣告合適者選擇範圍接近者選擇使用者眾者選擇相依性低的盡量不要選擇依賴程式庫多的專案了解程式架構，拆解出自己所需的部份即使已經盡量的選擇範圍接近自己所需的專案，但多出的部份仍需適當的拆解拆解前要先了解程式架構閱讀能取得的文件程式碼的追蹤如果不了解程式架構不知在此架構下的拆解的方式不知那些可以拆那些不能拆不知那些可以先不拆等日後再拆訂定不同的階段，從最小的里程碑開始在原始碼層次的拆解告一個段落後，程式碼通常連編譯都無法編譯必須制定幾個不同階段的目標，並且從最小的里程碑開始出發達到第一個里程碑具有十分重要的象徵性意義代表著你能夠正確的編譯而且執行（即使功能不太正確或功能尚不完備）但只要能夠達到第一個里程碑，之後的問題幾乎都能輕易迎刃而解做細部拆解，先求能編譯，再求正確執行在開放原始碼的回收與再利用活動中，最難的是就是讓拆解下來的原始碼成功的編譯拆解出來的部份往往相依於未被拆解的原專案組成headerfile中的定義或巨集原專案中的其他函式為了成功的編譯，你需要再回到基礎專案中，把所需的部份拆解出來此即所謂細部拆解細部拆解並不會直接把整個原始碼檔案移至回收專案中，僅移動在基礎專案中所需的部份在這個階段，會反覆的看到許許多多的編譯錯誤逐一解決各個編譯上的錯誤需要的耐心耐心加耐心暫時忽略非第一個里程碑的內容矇上眼睛假裝看不見有許多編譯錯誤是第一個里程碑後才會需要的適時的將它們註解掉，以求通過編譯檢查是一個很好的手段被註解掉的部份，在通過第一個里程碑後，解決其編譯錯誤的方案，也會在處理第一個里程碑的過程中產生此時再取消對它們的註解，就可以套用這些解決方案適度的斬斷關聯性，尋找適當的替代品許多開放原始碼的專案是盤根錯節有時編譯的錯誤是來自於缺少某個函式或類別，而如果要加入這個函式，必須引入一大堆東西必須考慮適度的斬斷和該函式的關聯性Ex,GList.c/GList.h相依於GLib其他部份尋找替代品的兩個途徑自己撰寫再找現成的開放原始碼運用替代品的方式修整介面，保持作用，符合目的整理介面，去除不必要的元素被回收的程式碼本身的目標往往和你運用的目標不盡相同其函式或類別的介面長相就會和你所需的不同介面中的元素會較我們所需的為多因為拆解的關係，有許多編譯錯誤會來自於未含入介面中額外多出的元素去除一些不必要的元素，並且重新整理這些介面的長相得到第一個可以編譯的版本做好心理建設，面對混亂就算張開眼睛也仍然看不見別人的程式碼習慣風格和你必然不同不要浪費時間在重新整理上請先做好心理建設，讓自己能夠面對自己覺得混亂的程式碼，視眼前之混亂如無物有空閒時間，再套用refactoring的技巧，逐步的改善回收程式的結構跨出成功的第一步成功的達成第一個里程碑後，便逐一的依照同樣的方式加入後續的里程碑達成的速度會愈來愈快CaseStudy：視訊檔案的格式探測需求：檢查給定的視訊檔案是否屬於特定的數種格式限制：C/C++，在Win32上執行，編譯後大小必須在100KB以內在網路上搜尋可用的原始碼，並選擇最適合的ffmpeg有許多人使用，而且程式語言是C，在Win32平台上編譯不致於有太多問題ffmpeg的libavformat有提供此類的功能了解程式架構，拆解出自己所需的部份由上而下了解程式架構先找到一段應用libavformat的範例av_register_all();//Openvideofileif(av_open_input_file(&pFormatCtx,(char*)fileName,NULL,0,NULL)!=0)returnfalse;//Retrievestreaminformationif(av_find_stream_info(pFormatCtx)0)returnfalse;//Couldn'tfindstreaminformation//Dumpinformationaboutfileontostandarderrordump_format(pFormatCtx,0,(char*)fileName,false);展開追蹤原始碼善用grep工具（Win32上可用WindowsGrep）逐一檢查dump_format()前的各個函式voidav_register_all(void){staticintinited=0;if(inited!=0)return;inited=1;avcodec_init();avcodec_register_all();mpegps_init();mpegts_init();.../*一堆xxxx_init()*/採DFS展開－深度優先搜尋接下來往mpegps_init()展開，利用grep找出它在mpeg.c中intmpegps_init(void){#ifdefCONFIG_MUXERSav_register_output_format(&mpeg1system_mux);av_register_output_format(&mpeg1vcd_mux);av_register_output_format(&mpeg2vob_mux);av_register_output_format(&mpeg2svcd_mux);av_register_output_format(&mpeg2dvd_mux);#endif//CONFIG_MUXERSav_register_input_format(&mpegps_demux);return0;}續追av_register_input_format()voidav_register_input_format(AVInputFormat*format){AVInputFormat**p;p=&first_iformat;while(*p!=NULL)p=&(*p)-next;*p=format;format-next=NULL;}看看AVInputFormat定義於何處利用grep找出在avformat.htypedefstructAVInputFormat{constchar*name;constchar*long_name;intpriv_data_size;int(*read_probe)(AVProbeData*);int(*read_header)(structAVFormatContext*,AVFormatParameters*ap);int(*read_packet)(structAVFormatContext*,AVPacket*pkt);int(*read_close)(structAVFormatContext*);int(*read_seek)(structAVFormatContext*,intstream_index,int64_ttimestamp,intflags);int64_t(*read_timestamp)(structAVFormatContext*s,intstream_index,int64_t*pos,int64_tpos_limit);intflags;constchar*extensions;intvalue;int(*read_play)(structAVFormatContext*);int(*read_pause)(structAVFormatContext*);structAVInputFormat*next;}AVInputFormat;判斷AVInputFormat各欄位的作用用非物件導向的方式來實作物件導向的多型有很多一看就知道是探測格式時不會需要的我們應該要特別注意read_probe及extension兩欄位訂定不同的階段，從最小的里程碑開始我們試著訂出三個階段探測mpegps格式探測mpegts格式探測其他格式試著編譯，一定會發生很多問題結構之間的環環相扣：為了AVInputFormat中的read_header，我們得括入AVFormatContext和AVFormatParameters後來我們會因為更了解而發現這個函式指標根本不需要但此刻的我們只好先把它們先加入在utils.c中的眾多函式同樣的也被清的只剩下：av_register_input_format()、match_ext()、av_probe_input_format()適度的斬斷關聯性，尋找適當的替代品av_probe_input_format()會用到許多utility函式av_realloc()、get_buffer()、url_open()、url_fseek()、