[討論] 如何工作？開發不同系統間交換資料的程式

看板Soft_Job作者 (打字猴)時間6年前 (2017/09/21 22:59), 6年前編輯推噓7(7推 0噓 33→)
留言40則, 10人參與, 最新討論串1/2 (看更多)
最近在軟體開發上遇到一些狀況， 這狀況最後的結局是導致測試及撰寫文件的人要加班把東西弄好。 但細想整個流程，感覺我同事這加班是可以避免的， 所以想Po來詢問大家，如何用最少的時間，做到一樣的事情。 有三個系統 A、X、Y， 角色有 PM-A、PM-X、PG-A(我)、PG-X、輔導， 公司都稱測試及撰寫文件的人叫輔導 (雖然我查網路好像沒特別這樣說) X 跟 Y 系統兩者之間的功能只有些微不一樣； A 與 Y 之間資料交換的程式已經上機有好一陣子， 整個傳送的過程也都很順利； 今年8月底的時候客戶要求 A 跟 X 也要有一樣資料交換的程式， 同時因為 X 跟 Y 有些不一樣，來自 X 的資料在 A 前端顯示會有些微不同， 程式要求9月底交付； PM-A 了解需求後告訴我怎麼做， 因為知道有時間壓力，所以把 A系統 這邊的程式在9月初完成後發測， 結果測試一直出現錯誤，大部分的原因是 X系統 要與 A 交換的程式有缺漏， 使得傳過來給 A系統 的資料不完全， A系統因此一直報錯。 來回幾次之後在今天 PM-X 跟我說 A 前端的顯示 跟當初 PM-A 說有些不一樣，以及今天要將文件完成先交給客戶， 今天下班前 輔導問我說這個要改好要多久， 我想了一下大概要一個小時，由於前端顯示並沒有差很多， 輔導決定用修圖的方式先把文件做出來， 想到我可以明天一早上班就先處理掉，就準時下班了。 過去我劃分職責的方式是照程式是寫在哪個系統上的， 但依照這分法，A 與 X 個系統間的資料交換，程式寫在 X 系統， 所以不是我負責的， 但那隻程式的 domain know-how 比較多是跟 A系統有關。 所以我應該要在開發過程中去主動了解那隻程式的狀況， 來避免我的同事加班嗎？ 更進一步的來說，A、X、Y 三個系統都是同一家公司負責的， 所以有問題只要走到彼此辦公位置討論就好，很方便； 但 A 跟 其他公司的系統 I 也有資料交換，如果以後要增加資料交換的功能， 程式開發時間勢必會因為電話及郵件來往間耗掉很多時間。 不知道大家聽到上述狀況，有沒有甚麼想法呢？ 是不是有更好的作法，能夠花更少的力氣，做到一樣、甚至更多的事？ --
→
08/15 15:23,
為追一個女孩認真讀書，最後考上交大，把春青的故事
08/15 15:23
→
08/15 15:23,
寫成小說，最後拍成電影，這還不夠熱血嗎?
08/15 15:23
→
08/15 15:25,
我不敢說九把刀現在有多成功，但他的確是一步一步在
08/15 15:25
→
08/15 15:26,
賺錢
08/15 15:26
→
08/15 15:26,
實現他的熱血，以及他說出來的夢想..
08/15 15:26
→
08/15 15:27,
定價250
08/15 15:27
-- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 49.217.118.161 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1506005985.A.7B6.html ※ 編輯: scottshai (49.217.118.161), 09/21/2017 23:03:12
推
09/22 01:17, , 1F
不就PG-A跟PG-X在一開始就定義好資料溝通介面，兩邊各自
09/22 01:17, 1F
→
09/22 01:17, , 2F
開發這樣嗎？寫程式的人也要負責寫文件給測試人員才對，
09/22 01:17, 2F
→
09/22 01:17, , 3F
沒文件也要講清楚流程
09/22 01:17, 3F
推
09/22 02:31, , 4F
我的直覺在於 你們開了一個根本自己做不到的時間
09/22 02:31, 4F
→
09/22 02:32, , 5F
從一開始的時間就是錯的 也就是你們對於自己在做什麼事情
09/22 02:32, 5F
→
09/22 02:32, , 6F
都不太清楚
09/22 02:32, 6F
→
09/22 02:33, , 7F
然後給客戶一個根本做不完的時間
09/22 02:33, 7F
→
09/22 02:33, , 8F
跟承諾
09/22 02:33, 8F
→
09/22 02:34, , 9F
修改維護案每當增加一系列的項目更改或新增功能時
09/22 02:34, 9F
→
09/22 02:35, , 10F
每一項下會動到哪些在準備執行前就會初估時間
09/22 02:35, 10F
→
09/22 02:36, , 11F
等到時間估出來 才會擬新案合約開始執行
09/22 02:36, 11F
→
09/22 02:37, , 12F
你們寫到會發現測試過不了或是有持續性問題 我的感覺就是你
09/22 02:37, 12F
→
09/22 02:37, , 13F
們在評估階段時可能連測試都沒初步測試能不能整合或調整都
09/22 02:37, 13F
→
09/22 02:37, , 14F
不知道就貿然開案
09/22 02:37, 14F
→
09/22 02:37, , 15F
還有連緩衝時間都沒有
09/22 02:37, 15F
→
09/22 02:38, , 16F
客戶越急 你們上面的人就必須要有能力跟對方談
09/22 02:38, 16F
→
09/22 02:38, , 17F
這項悲劇我只能說 你們要自己檢討流程 而不是程式的問題而已
09/22 02:38, 17F
→
09/22 02:38, , 18F
幫不了你們
09/22 02:38, 18F
推
09/22 05:13, , 19F
看來看去都是介面沒先溝通好產生的問題
09/22 05:13, 19F
→
09/22 08:34, , 20F
兩邊規格書打開一看就知道，沒寫表示一開始沒定好(pm問
09/22 08:34, 20F
→
09/22 08:34, , 21F
題)，交換資料格式一定要寫在規格書
09/22 08:34, 21F
推
09/22 09:09, , 22F
結論是當初A-Y之間的傳遞說明文件亂寫對吧？
09/22 09:09, 22F
→
09/22 09:09, , 23F
你照著說明實作 發現有問題對吧？
09/22 09:09, 23F
→
09/22 09:09, , 24F
那就無解 若文件不保證正確 那這件案子就一定會撞進去
09/22 09:09, 24F
→
09/22 09:10, , 25F
而且是撞進去才有辦法知道錯誤
09/22 09:10, 25F
→
09/22 09:41, , 26F
系統A,B,C,D,E都有它們自己的export/import成json格式的
09/22 09:41, 26F
推
09/22 09:41, , 27F
輔導 xd 為啥不叫 QA or SQA
09/22 09:41, 27F
→
09/22 09:41, , 28F
界面,只認自己版號的格式.專用的系統Z負責轉換格式。
09/22 09:41, 28F
→
09/22 09:44, , 29F
我想有兩個 .. 1. flow chart 2. swagger hub api test
09/22 09:44, 29F
→
09/22 09:45, , 30F
你們要加強流程圖與測試工具，而非系統整合後，的完整測試
09/22 09:45, 30F
→
09/22 09:45, , 31F
最後，再用 jenkin 的部署，進行上線單元測試即可
09/22 09:45, 31F
→
09/22 09:46, , 32F
先把 flow 圖搞定，交給各方人馬資料交換的結構方式
09/22 09:46, 32F
→
09/22 09:47, , 33F
再把測試工具/api交給對方，自行驗證
09/22 09:47, 33F
→
09/22 09:47, , 34F
基本上除非沒想到的例外狀態，再加入到 flow / api 中即可
09/22 09:47, 34F
→
09/22 11:54, , 35F
要磨合 沒有絕對答案
09/22 11:54, 35F
推
09/23 00:06, , 36F
這個例子應該是你們五個人為一個team的概念去做才對，依
09/23 00:06, 36F
→
09/23 00:06, , 37F
照project 組隊就沒什麼問題
09/23 00:06, 37F
→
09/23 00:07, , 38F
各自單獨的A，X系統的問題也要處理，所以A,X間的問題優
09/23 00:07, 38F
→
09/23 00:07, , 39F
先權就是PM-A/PM-X來決定
09/23 00:07, 39F
推
09/24 10:51, , 40F
沒有API的觀念就是這下場 很新手的問題......
09/24 10:51, 40F
‣ 更多 scottshai 的文章
文章代碼(AID): #1PmzFXUs (Soft_Job)
‣ 更多 scottshai 的文章
文章代碼(AID): #1PmzFXUs (Soft_Job)