如題 目前做的project架構長這樣 Loader1 Loader2 Loader3 ........... Loader30 Area 1 Area 2 Area 3 .... .... Area 10 就是同一個Loader 會算出結果給不同Area的人 有分成前端跟後端，前後端都是我維護 (前端 .Net Framework java script MVC,會 用到一點 jquery，其他大多套套件用現成的物件再加工，後端就純C# query DB用的工具是公版的不用自己寫，就負責input 要打的SQL跟DB，然 後output datatable或是對DB做insert/delete/update....) Loader每支老闆認知都不算很大所以也是一人包辦XD Loader每支的邏輯也類似: Start--->會記錄log表示loader開始 Initial setting----> query一些接下來SQL會用到的config QueryRawData---->把上一個initial function的config帶下來在這裡組成SQL string 並且query進data table ProcessData--->對上一步的data 做運算然後轉換成可能只有一個kpi值的結果 或是pre-sum過後的結果 (舉例來說query hourly的資料轉換成daily的資料) End---->只是記錄log表示上面的function都執行完了 看似很穩定 但loader卻需要不斷的更版 原因是因為SQL全部都是寫死的，接水其他系統的資料 https://imgur.com/a/xjTfPfG 以這個圖為例，USER只看的到最終的TABLE，沒有太多空間可以彈性修改query的條件 也沒有像左上角有彈性調整query資料的方法 (有config但是很少) 所以需求常常長得像這樣: "tinasfishs 啊你幫我改一下，我發現今天的KPI有錯，因為 今天開始要加採計'AA' 這種類別，麻煩再幫我改" 原始SQL通常長這樣 SELECT COUNT(1) CNT FROM STORE_SALES WHERE 1=1 SELECT * FROM STOR_SALES WHERE 1=1 ( AND TYPE IN ('A','AB','BC',....'DZ','AA') AND SALE_DATE BETWEEN SYSDATE-3/24 AND SYSDATE-1/24 AND MT_CODE IN ('2','5') AND...... CASE WHEN .... )A, ( SELECT EMPLOYEE_DEG,EMPLOYEE_NAME FROM EMPLOYE_L WHERE AREA='AREA1' AND RES_PRODUCT NOT LIKE '%AAZc' .... .... ... )B, ( SELECT EMPLOYE_ID,EMPLOYEE_SHIFT FROM SHIFT_ARRANGE_LIST WHERE RECTIME>SYSDATE-5 AND AREA='AREA1' if (AREA=='AREA1' or AREA=='AREA2') { RECTIME<SYSDATE-1 } )C WHERE A.SALE_EMPLOYEE=B.EMPLOYEE_NAME AND B.EMPLOYEE_ID=C. EMPLOYEE_ID SQL通常都很長而且用sub-query，會把商業邏輯埋在hard-code的SQL裡面 不能用SQL處理的邏輯則是在ProcessData那步處理 假設綠色的地方是config，黃色的地方則是這次修改的部分 重點是改後端的SQL都需要重新上code，雖然有提供公版的工具把SQL另外儲存 只要呼叫那個外部工具就可以把SQL取得 但前人為了開發方便 當然全部都把SQL直接擺在程式裡 然後複雜的是，同樣算這個KPI，各個AREA 的條件是不盡相同的 用藍色字的地方就是舉例，沒有使用config而是用C# 的code 直接hard code 這兩個 area 需要加此條件 所以也會衍生像是 "我們是AREA3，AREA1 跟 AREA2 看的那個條件我們從下禮拜開始也想跟著採計 ，你們可以重新上code嗎" 有爬文像是Stored procedure 之類的做法，歹勢對於這個架構完全不適用 理論上像這樣各個area的條件有不少差異的情況下，應該是個別維護各area的loader 但這整套是寫在一起的...，每次上code為了維護版控也會在各area同步上同一套 也就會發生改A壞B，假設area1跟area2 共用同一段SQL條件，答應area1刪掉 其中一句之後，area2 就跑來說他們的KPI異常 這個專案負責接水30幾支上游的TABLE，就有30幾支LOADER..而且還在逐漸增加中 所以談需求跟開發的時候，根本也不是從 "為什麼要新增AA這個條件，除了改SQL有什麼更好的方式" 去切入 因為那要去詢問上游以及user為什麼要新增這個條件太花時間 而是 "幫我改SQL吧比較快"---> 所以從來都只在做改SQL這種很末端的工作 一個禮拜大概有4-5個這樣的"假需求"---->我定義為只是改SQL，請user驗驗看是否 符合他們期望 user有時候也不確定改了條件是否就會對，改了也不能上code 總是改了再測測了再改 這樣的需求都做完了，才有時間去處理可能真的是loader本身的問題 ----->效能的問題啊、要新增一支新loader 與user談規格之類的....orz 談規格也是我一人，頂多再加0.5個PM PM也跟我想像會把規格談到不會讓日後充滿這些維護 剛好相反 最後規格談一談還是常常訴諸短解 能夠hard code SQL就hard code，理想性的應該要跟上游負責系統的人看資料 怎麼接軌的溝通過程完全沒有= = 我有堅持過想先看清資料流再做新需求也因為求時效性被打槍 有被訓練得比較有警覺性，但一個SQL 至少20行，下面又有條件讓user高興改就改 實在很難用很大的框架去處理這樣的事，SQL有記得拔出來放在另外存的地方 不用重新上code就很不錯了 BTW SQL邏輯跟要接水什麼報表通常都是由USER提供 ----------- 有跟老闆溝通過像這樣接水別人資料的匯總型AP 應該要重構，或者是一支一支 拿出來看有什麼可以enhance的 但user常常會認知KPI錯誤就來說是系統問題，久而久之老闆也好像覺得是我的問題 而沒有深究之所以KPI會錯誤，就是因為SQL在上code流程的不彈性，還有讓user在 不能彈性重上CODE的情況下還是一再想修改SQL (不能彈性的原因是要重上code老闆都會看，跟他解釋這個是要改SQL就會被 question，但老闆也不看CODE也不會負責建議有建設性的方法，只會打高空問 說可不可以不要改SQL--->問我的格局只能做到這樣...整個黑人問號) 私以為想修改SQL或是想改變KPI的算法，都應該是大家坐下來看data flow是什麼 是不是只是加了一句SQL就可以改變 但文化上大家也不太有耐心這樣梳理問題 不太清楚老闆是否了解目前系統的設計是長這樣，總之在溝通上也覺得不太有救 想問問有沒有維護或是開發過這種DATA LOADER的前輩 可以分享一下心得的QQ -- ※ 發信站: 批踢踢實業坊(pttsite.org.tw), 來自: 114.25.93.94 (臺灣) ※ 文章網址: https://pttsite.org.tw/Soft_Job/M.1669050189.A.15C