Table of Contents
我看到好多獨立的事情被外包或者衆包出去，在完成速度和效率上，都很是出色。好多開源的組織也是這樣，接納全世界軟件開發着的貢獻，而後對這些貢獻進行整理，這是衆包的過程。項目經理在分派任務的過程當中，將系統分割成不一樣的部分，而這不一樣的部分又關聯的不那麼緊密; 讓他們齊頭並進，這樣讓項目效率提升很多。vim
1 高度集中的集權模式
在以前的一家公司，在開發的過程當中，當你寫完代碼，你根本就不能去測試你的代碼。首先你的代碼沒有測試模塊，由於電信的業務錯綜複雜，要調試須要牽扯到不少系統。我發現這些系統是互相關聯，少了哪同樣都不能正常運行（徹底造成不了所謂的插件模式）。還有就是你們在本地寫好代碼，都會上傳到同一個服務器上，編譯; 有時候恰好碰到某我的也在上傳本身的模塊，你要等一下，而後等他編譯完成以後，你才能接着你的工做。這就是我要說的中心模式，因爲擁有一箇中心，你必須排着隊去處理任務，當你的模塊出現問題，還會影響到其餘人工做。windows
如今不一樣了，在一家遊戲公司，每一個人都擁有本身的數據，本身的服務端，本身的客戶端; 我開發好本身的服務端。在本身的虛擬機裏面運行，徹底不會影響其餘的人工做。同時，客戶端開發人員，也擁有和我同樣的部署。當客戶端和服務端都開發完以後，只須要將客戶端鏈接上服務端就能夠進行聯調。聯調完成以後，將模塊代碼歸總到工程的svn主幹，通常一個模塊都會指定一個客戶端和一個服務端來作。若是人員比較多，兩兩配對，能夠同時作多個模塊，而相互不想幹擾。這就是分佈式開發模式。服務器
分佈式開發模式是基於插件模式的基礎之上，模塊被分割出來以後，它們是互不相關聯的。高度集權模式，就像獨木橋同樣堵得緊。分佈式開發模式則擁有更多車道，八面玲瓏。咱們很快可以看清分佈式開發的好處。框架
在測試上，分佈式也體現其優越性。程序猿分別開發本身的模塊，每一個人爲本身的模塊寫入測試模塊，確保本身的模塊運行良好以後; 而後將不一樣的模塊彙總，由測試人員查處各個模塊之間的銜接bug。假使每一個開發人員不確保本身的模塊工做正常，全部的bug聚集到測試人員那裏，將是不可開交的。eclipse
2 千篇一概的固定框架
每一個公司都有一個框架，一個開發人員進入這家公司就必須得按照固定的模式去寫這個模塊。那種千篇一概的工做會讓那些想追求新鮮事物的程序猿們厭煩不已; 因而乎不停的跳槽，不停的換工做，最後仍是沒有跳出這個尷尬的局面; 這恰是一個碼農的真實寫照。寫重複性代碼是必須，咱們每一個人都是生產線上的工人，作重複性的事情，能夠減小工做的難度，提升工做效率。可是軟件開發畢竟不是富士康裏面的生產線。編輯器
插件模式，最後要打造的就是這種方式，減小開發的難度，造成固定的插件開發套路。有沒有什麼方法來解決這樣的問題了？分佈式
減小重複性工做的方法，就是讓這部分重複性的勞做成果自動產生–作一個代碼生成工具。如今一些主流的IDE(eclipse、vim、emacs)都支持插件，大部分公司能夠根據本身的框架結構，來開發IDE插件，定製本身的IDE。我之前使用VC開發過MFC程序，咱們發現使用它可以很方便的添加消息、類、事件等，這些只須要啓動classwizard。咱們能夠設計插件，與IDE相融合，來建立框架裏面的一些組建，以及在剛開始的時候，建立本身的模塊模板。VC也是這樣作的，它會建立Dialog等模板。插件會在各個組建模板須要添加代碼的地方，去添加TODO標誌，這樣子提醒開發人員去補全代碼。ide
按照這樣的方式，能夠減小大量的複製粘貼的工做，同時也減小了複製粘貼過程的大量錯誤。要記住，當你產生了大量的複製粘貼，說明好多東西是能夠自動生成的。這樣子，程序猿能夠專一於本身關心的事情，也就不會以爲很枯燥了。svn
3 左右逢源的插件模式
上面以及包括前幾篇文章裏面屢次提到插件模式，插件模式其實也是一種弱中心化的過程。它有一箇中心，起到統籌的做用，各個插件互不關聯，表現出不一樣的特性。當一個插件工做失常，不會影響其餘插件的工做。我所見到大部分編輯器，都擁有不少插件。編輯器是一箇中心，它擁有最基本的要素; 插件來豐富其特性。函數
在windows下面擁有一款編輯工具，notepad++; 我特喜歡，其有豐富的插件，其由C++開發而成的。插件開發全部的特性是：1.插件與插件之間互不依賴; 2.在開發插件的時候不須要去更改主體的代碼; 3.主體自動去加載插件。想一想，當咱們下了notepad++的一個插件，咱們並無去更新或者更改notepad++或者其某個插件; 當咱們將notepad++的插件放置到其plugin目錄下時，從新啓動notepad++，notepad++就可以使用這個插件的特性了。
這種不斷的更新模塊，並不會致使整個工程的從新的編譯生成的特性; 只有動態庫才能很好完成這樣的工做。notepad++的插件就是一系列的dll文件。
不一樣的操做系統動態加載dll的API不同，Poco庫，一個跨平臺的C++庫，爲咱們解決了不一樣平臺的差別，提供了統一的加載dll的API。在開發咱們的插件的時候，咱們必需要約定插件的一個入口函數，主體應用經過調用相應dll的入口函數，而後在針對插件的不一樣特性，來作一系列的操做。
下面是一個例子：
1 //主題程序經過配置文件加載dll，而dll_config.txt配置文件裏面包含了全部插件dll的路徑 2 bool LoadPlugin() { 3 file.open("dll_config.txt"); 4 while (!iseof(file)) { 5 dll_path = file.readline();//從配置文件讀取dll路徑 6 HAND hDll = LoadLibrary(dll_path); //加載dll 7 Proc proc = GetProcAddress(hDll, "Init"); //獲取函數地址 8 proc();//調用函數 9 } 10 } 11 12 13 //配置文件dll_config.txt 14 xxx/a.dll 15 ... 16 xxx/n.dll 17 18 //插件模式dll,必需要實現Init入口函數，並且使用C，防止產生聯編，由於咱們要根據函數名稱獲取dll中的Init函數地址，能夠在入口函數裏面調用插件的C++接口 19 __declspec(dllexport) void Init() { 20 xxx 21 }
這是主體程序加載插件的模式，還有不少事情要作，主題程序必須提供清晰的程序結構來供插件調用。好比編輯器會有工具條，菜單，編輯框，狀態欄等，插件要在這些上產生特性，要對這些組建作操做的。
插件模式讓事情變得更加簡單化，同時讓開發變得沒有挑戰性; 同時也可讓程序猿關注更重要的事情，抽出更多的時間來作本身喜歡的事情。