如題
目前做的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
--