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

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.25.93.94 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1669050189.A.15C.html