老板認為插件式開發等于不用寫代碼，程序員：這是想把我也省了？

有個不懂技術的老板真是災難！我前老板希望我做個框架，不希望每個項目代碼都需要重新寫，這樣非常耗時間，人力成本非常大，于是我就說那我就寫個通用框架吧，把一些通用性的東西封裝起來，下次要用的時候直接配置一下最后反射就可以了，但是，在老板心里，他的卻想歪了！

老板心里想的是，寫過的代碼寫過一次就不用寫了，所以，事情越往最后，寫得代碼越少，直至最后一行代碼都不需要要寫，直接配置配置，程序就出來了！

我在上家公司的時候推進了這個事情的發展，并且親自擬定了框架思路，后來因為項目比較急，這個事情就不在我手上了。

于是，老板花重金招聘了一個“經驗豐富”的大齡程序員來搞這個事情，相信您也看出來了，這個“經驗豐富”被我打了雙引號，明眼人都能看出來這個事情不簡單！

其實，所謂通用框架的思路無非就是插件式開發，在我們搞非標設備的程序員眼里，能夠被插件化的東西無非就那幾樣，常用的邏輯、常用的硬件、可動態的配置文件等等。

我們可以將這些邏輯、硬件、配置文件分別繼承統一的基類，然后軟件在加載時通過加載反射這些基類，然后動態加載基類的實現類，這樣就可以做到動態的效果。

這么做的意義是啥呢？比如說我們公司有一些PLC，上位機軟件需要跟PLC通訊，但是，不同廠家的PLC它的通訊邏輯是不一樣的，那么我們可以找到所有需要跟PLC通訊的共同點，比如說讀寫一個Int、String、Boolean類型的地址值，這時候所有廠家的PLC我們可以繼承PLC讀寫的基類，然后實現Int、String、Boolean類型的讀寫函數即可。這樣，即使是一個項目中，中途換了PLC的品牌，我們也只需要將對應的實現包丟到軟件中，讓軟件動態加載PLC的實現，從而做到一行代碼不改。

說到這里，大部分人應該都可以理解這種思路吧？

但是，越到最后，我發現老板的理解越來越恐怖了！

通過那個“經驗豐富”的程序員后面跟我們溝通得到的反饋，老板其實要的是一個“能干掉公司大多數程序員的東西”！

雖然老板嘴上沒有明說，但是我們后來理解了老板的意圖，說簡單點，老板其實要的是一個低代碼或者無代碼的系統，基本上通過拖拉拽和簡單配置就能組裝一個上位機軟件。

但是，想要徹底不寫代碼，或者寫少量代碼，那么必須有一個前提，那就是你得先把所有項目的業務邏輯全部都理清楚，并且提前把相關代碼寫好，這時候才能夠做到所有邏輯通過拖拉拽的方式，以流程的方式去運行。

我不知道大家有沒有用過?？档腣isionMaste或者康耐視的VisonPro，是的，老板要的其實就是這樣的東西，可是，因為VisionMaster和VisionPro對于普通人來說，還是有一些上手成本的，所以，老板的要求還要更嚴苛，最好是一個普通人都能輕輕松松拖拉拽出一個上位機軟件系統來！

那個“經驗豐富”的程序員最后直接崩潰了，因為光寫一個插件式開發的框架并不難，難的是如何找出所有項目的共通點，然后把所有邏輯封裝起來。

干到最后，他發現，我們公司的項目幾乎找不出太多的共同點（因為太非標）了，無論怎么搞，其實只能說代碼工作量小了，但是編碼量頂多也就只能減少一半而已，然后就卡在了業務邏輯這塊。

最后，說結果吧，這個“經驗豐富”的程序員最后被開除了，因為他寫的框架沒有達到老板的期望，又因為卡在業務邏輯的整合這塊卡了很久，后來甚至都不知道怎么往下寫了，然后就擺爛了，而老板又非常關心進度，找他談了次話，得出的結論就是-這個東西根本不存在，因此，就把他開了！

結語

你說這叫什么事，花好幾萬請來的大牛，干了幾個月，公司白白付了十幾萬的工資，最后發現是一場空！而且，中途有些人已經反應過來了，老板的最終目的其實還是想省人力成本，假如他期望的系統真的能被實現，我估計最后公司那十幾號人能留下的也沒多少了！

這也是我前公司人心散了的其中一個大原因吧！

現在想起來，我提插件式開發只是為了后面的項目更加省時省力，但是，如果老板提的思路如果真的能實現，到時候老板可能把我都省了，招幾個年輕且工資要得比我少的程序員就把項目給干了！