[附加題] 結對項目對接的苦痛

 

[附加題] 結對項目對接的苦痛

本次很榮幸地，個人程序做爲不少程序員隊伍的備胎計算模塊被加入了各大程序的附加題參考中，有如下幾位同窗都曾與我進行模塊的對接：

• GNU_Linuxer
• 馬克斯
• kanelim
• PocketPanacea
• kibbon
• ruoyuwang
• 夜微涼evol

苦逼的計算模塊—快被吐槽死了

先來談談我做爲計算模塊的提供者的感覺吧：

總的感覺就幾個字：請別吐槽我了...

個人代碼質量我以爲仍是能夠的，可是在這過程當中出現的最嚴重的問題是啥呢，是設計的問題，是設計者對於需求的理解和框架、接口統一與否的問題。

關於計算核心質量，不一樣的人的見解有着天壤之別，好比ruoyuwang組在我給他們計算核心與簡短的使用說明後，他們就很成功地對接上了咱們的模塊，而且表示仍是挺好用的。固然這過程當中也有一點點曲折，個人計算模塊單向引用了個人UI模塊裏的一個靜態變量，原來是爲了可以動態更改Grade.txt的生成路徑使用（如今想一想這種作法也真是下下之策...）。由於若愚同窗要的早，一開始給的不是封裝好的dll模塊，而是一堆計算的.cs文件，而最後若愚同窗他們拿到後編譯都編譯不過...雖然改動是比較好改吧，可是個人這種設計上的小毛病也是爲他人帶來了很是大的不便，真是很是抱歉...一樣的問題也出如今了江昊同窗那裏，對這兩位同窗表示歉意...

在跟kanelim的對接過程當中產生了比較大的問題，由於他們是用xml傳參的，因此咱們就又作了一個用xml傳參的前端與後端給他們來對接。可是我發現一切根本不是想象中的簡單...即便兩組都是使用xml傳參的，可是kanelim組增長了不少功能，他的前端和個人後端基本沒有辦法對接：他的不少附加的小功能咱們組都沒有實現，而他們的附加功能是在計算模塊裏擴展的。最後勉強用咱們的前端在改動了xml有關的代碼後，算是對接了。

可是最嚴重的問題出如今跟GNU_Linuxer組的對接上。咱們的計算核心和他們的前端徹底不匹配，問題主要是出如今一個設計的思路上：是前端作寫入文件的邏輯，仍是後端作寫入文件的邏輯呢？在他們組看來，後端應當是一個純粹的計算模塊，就像一個庫同樣，計算模塊就只須要有計算模塊該有的功能。

而咱們的程序，就像是爲scanf加上了默認讀取文件路徑同樣，有了許多的附加做用，這些原本看起來爲了開發者方便的附加做用如今成爲了對接上最大的困擾，然而下降了對接組對接的效率，從而致使鳴神對我吐槽不斷。

而我在第一次嘗試對接失敗以後也反思了本身的緣由：確實咱們的計算模塊不像是個類庫，倒更像是個一鍵式程序：給你提供三個函數，你不一樣的功能調用不一樣的函數，一步到位，信息隱藏得十分隱祕。簡短的幾行代碼就能夠完成複雜的功能，不須要作額外的事情，只須要將它和對應按鈕的Click事件綁定就好。

這樣真的是好的作法嗎？我在對接以前仍是信心滿滿的，由於我以爲它最大程度地遵照了信息隱藏的原則，最後只開放一個公共類可讓你調用幾個函數，這確實作到了很好的「封裝」。但在逐漸的思考過程當中我發現，實際上我「意譯」了老師的需求：做爲一個計算模塊，就該是計算模塊的樣子，就不應牽涉到文件的寫入。計算模塊帶來的反作用，違反了接口設計規範裏的單一職責原則，是超出其職能範圍的一種誤操做。

在這過程當中我還反思了另外一個問題：我做爲計算模塊的提供者，究竟要不要爲了更好地適應作出不一樣版本的計算模塊？這樣是否是有違鬆耦合的原則呢？我是否是隻要作一個能實現基礎功能的計算模塊就好，其餘改動須要前端去適應呢？我一直在想這個問題，由於鳴神組最後是經過前端的更改達到對接的目的，而其餘成功對接的組最後也都是略微修改前端而達到目的。而除了GNU_Linuxer組使用前端寫入文件，其他組都是使用後端寫入文件的。而除了kanelim使用xml傳參，其餘組也都是比較普通的傳參形式。

因此我如今還不太明白，當先後端對接較爲困難的時候，是須要設計理念略差的一方作出更多讓步呢，仍是根據便利來進行改動？這設計理念不一樣，又如何評判略差和略好呢？但願老師可以解答個人疑惑哈~

農奴翻身作主人—仍是得本身適應

那麼說完我做爲計算模塊的提供者，就再說說我做爲計算模塊的使用者的感覺吧。首先是kanelim組提供的計算核心，我我的以爲模塊自己沒有任何問題，質量很高，也寫了很多公用函數的Xml函數註釋說明。可是我親身體驗下來，仍是以爲略微繁雜。由於他們實現附加功能的函數也一塊兒被暴露，因此在挑選函數進行組合成我要的功能時常常會混淆函數的做用——即便不少函數有較爲良好的說明，但總有漏網之魚。因此對接最終勉強成功，時間花費較長。

再來就是kibbon組的核心，他們組提供了六頁的API文檔，可是都不是我想要的功能超強的God或者God's son函數...由於函數劃分太細，至關於本身須要不少的函數進行組裝以及拼合才能組成最後的功能，我我的以爲略微蛋疼。

鳴神組的核心雖說明很少，可是最後調用的時候仍是挺方便的，惟一的問題在於我以前不是在前端寫入文件，因此補充了比較多關於寫入文件的代碼，最終才能成功運行。（吐槽一下小麗叔寫代碼基本不寫註釋的壞習慣！）

本次項目對接尚未徹底作完...(還有三個小矮人須要接洽...白雪公主與七個小矮人的故事哈哈哈）。就算是這樣我也同樣感觸頗深（感受爲啥一點都沒有當主人的感受），再有新的感覺會及時更新~