作者scottshai (打字猴)
看板Soft_Job
標題[討論] 如何工作？開發不同系統間交換資料的程式
時間Thu Sep 21 22:59:41 2017
最近在軟體開發上遇到一些狀況，
這狀況最後的結局是導致測試及撰寫文件的人要加班把東西弄好。
但細想整個流程，感覺我同事這加班是可以避免的，
所以想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 也有資料交換，如果以後要增加資料交換的功能，
程式開發時間勢必會因為電話及郵件來往間耗掉很多時間。
不知道大家聽到上述狀況，有沒有甚麼想法呢？
是不是有更好的作法，能夠花更少的力氣，做到一樣、甚至更多的事？
--
1F：→ nightfly1984:為追一個女孩認真讀書，最後考上交大，把春青的故事08/15 15:23
2F：→ nightfly1984:寫成小說，最後拍成電影，這還不夠熱血嗎?08/15 15:23
3F：→ nightfly1984:我不敢說九把刀現在有多成功，但他的確是一步一步在08/15 15:25
4F：→ Bonescythe: 賺錢08/15 15:26
5F：→ nightfly1984:實現他的熱血，以及他說出來的夢想..08/15 15:26
6F：→ Bonescythe: 定價25008/15 15:27
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 49.217.118.161
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1506005985.A.7B6.html
※ 編輯: scottshai (49.217.118.161), 09/21/2017 23:03:12
7F：推 Clain66: 不就PG-A跟PG-X在一開始就定義好資料溝通介面，兩邊各自 09/22 01:17
8F：→ Clain66: 開發這樣嗎？寫程式的人也要負責寫文件給測試人員才對， 09/22 01:17
9F：→ Clain66: 沒文件也要講清楚流程 09/22 01:17
10F：推 alog: 我的直覺在於 你們開了一個根本自己做不到的時間 09/22 02:31
11F：→ alog: 從一開始的時間就是錯的 也就是你們對於自己在做什麼事情 09/22 02:32
12F：→ alog: 都不太清楚 09/22 02:32
13F：→ alog: 然後給客戶一個根本做不完的時間 09/22 02:33
14F：→ alog: 跟承諾 09/22 02:33
15F：→ alog: 修改維護案每當增加一系列的項目更改或新增功能時 09/22 02:34
16F：→ alog: 每一項下會動到哪些在準備執行前就會初估時間 09/22 02:35
17F：→ alog: 等到時間估出來 才會擬新案合約開始執行 09/22 02:36
18F：→ alog: 你們寫到會發現測試過不了或是有持續性問題 我的感覺就是你 09/22 02:37
19F：→ alog: 們在評估階段時可能連測試都沒初步測試能不能整合或調整都 09/22 02:37
20F：→ alog: 不知道就貿然開案 09/22 02:37
21F：→ alog: 還有連緩衝時間都沒有 09/22 02:37
22F：→ alog: 客戶越急 你們上面的人就必須要有能力跟對方談 09/22 02:38
23F：→ alog: 這項悲劇我只能說 你們要自己檢討流程 而不是程式的問題而已 09/22 02:38
24F：→ alog: 幫不了你們 09/22 02:38
25F：推 ripple0129: 看來看去都是介面沒先溝通好產生的問題 09/22 05:13
26F：→ doranako: 兩邊規格書打開一看就知道，沒寫表示一開始沒定好(pm問 09/22 08:34
27F：→ doranako: 題)，交換資料格式一定要寫在規格書 09/22 08:34
28F：推 chuegou: 結論是當初A-Y之間的傳遞說明文件亂寫對吧？ 09/22 09:09
29F：→ chuegou: 你照著說明實作 發現有問題對吧？ 09/22 09:09
30F：→ chuegou: 那就無解 若文件不保證正確 那這件案子就一定會撞進去 09/22 09:09
31F：→ chuegou: 而且是撞進去才有辦法知道錯誤 09/22 09:10
32F：→ enthos: 系統A,B,C,D,E都有它們自己的export/import成json格式的 09/22 09:41
33F：推 maxqq: 輔導 xd 為啥不叫 QA or SQA 09/22 09:41
34F：→ enthos: 界面,只認自己版號的格式.專用的系統Z負責轉換格式。 09/22 09:41
35F：→ maxqq: 我想有兩個 .. 1. flow chart 2. swagger hub api test 09/22 09:44
36F：→ maxqq: 你們要加強流程圖與測試工具，而非系統整合後，的完整測試 09/22 09:45
37F：→ maxqq: 最後，再用 jenkin 的部署，進行上線單元測試即可 09/22 09:45
38F：→ maxqq: 先把 flow 圖搞定，交給各方人馬資料交換的結構方式 09/22 09:46
39F：→ maxqq: 再把測試工具/api交給對方，自行驗證 09/22 09:47
40F：→ maxqq: 基本上除非沒想到的例外狀態，再加入到 flow / api 中即可 09/22 09:47
41F：→ bobju: 要磨合 沒有絕對答案 09/22 11:54
42F：推 shietsd: 這個例子應該是你們五個人為一個team的概念去做才對，依 09/23 00:06
43F：→ shietsd: 照project 組隊就沒什麼問題 09/23 00:06
44F：→ shietsd: 各自單獨的A，X系統的問題也要處理，所以A,X間的問題優 09/23 00:07
45F：→ shietsd: 先權就是PM-A/PM-X來決定 09/23 00:07
46F：推 zased: 沒有API的觀念就是這下場 很新手的問題...... 09/24 10:51