寫這甚麼垃圾

我要把這包程式改成效能正常，容易看懂，還有效能外一堆奇奇怪怪的bug處理完需要的時間大概就超過他原本開發這需求的用時了

而且寫不好還不是程式熟悉問題，整包程式的架構連同資料庫table都是他建的

可以在迴圈外先整理成map一次，方便使用的東西，圖方便寫成在迴圈內每次用stream filter篩選這筆資料對應的資料有哪些

複雜度從O(N) 19萬+12萬
變成O(N^2) 19萬X12萬

這東西是怎麼測的，不如說當初完成到底有沒有測試阿(翻桌

還有一些東西不是普通的算錯bug，是功能和需求不一樣，而且從呈現資料的邏輯考慮就知道這樣不對了

一個案件分類排名列表，上面要列出24個分類的接線數量和%數
這種定義下怎麼會想要把24個分類的排序固定阿，排名是什麼意思懂不?

還有一些計算錯誤，比方說性別比，女性+男性+不詳總共有102%，這個只要有測試就該發現了吧

最糟糕的是做出的計算規則和需求規格不符，甚至是需要新增資料庫table的程度，原本做出的東西完全歪掉

查資料的方式也很糟糕，以上面12萬和19萬的情境為例子
12萬是接線通數，19萬是這12萬對應的註記，因為一通可能有多個註記所以數量不同

首先是查接線通數的時候，本表總共9個欄位，其中一個欄位是長度達數萬字的html，此情境不須使用，其他欄位則全部都是長度50以下的一般欄位
這人查資料時直接把整筆資料取出來，導致取得的資料量是實際需要的千倍

雖然不確定影響多大，但是取資料這段和程式記憶體用量會飆升到4G我覺得一定有很大的關係

再來是取得註記資料的做法，他收集接線資料ID去查對應註記資料，但是因為使用的工具限制一次只能查2000個ID，所以12萬分成六十多次對資料庫的查詢，再組合成完整的列表

恩，你知道只要join建立關聯之後，就可以用接線紀錄table的時間篩選註記table資料，不但一次就好而且還快的多嗎
顯然是不知道

關於接線資料的大欄位，還有後續影響
因為一筆資料的空間變成千倍，後面在迴圈處理的時候都會更花時間
偏偏他寫的迴圈數量還多的誇張

一種報表出現雙重迴圈12萬X19萬，另一類報表是大量的stream filter、map使用，導致複雜度O(N)但是常數很大，達到116X12萬+14X19萬這種數字

同樣是O(N)也是可以有很大效能差距的，我兩種資料各一個迴圈就結束了啦，12萬+19萬

我還是第一次看到 intellij直接跟我說函式太複雜的情況勒，一千四百行的獨立函式，除了查資料和處理字串格式之外沒有用過其他函式

(拍拍

而且這是一類報表的其中一個，依據資料年份不同總共要用四種資料設定進行計算，所以這個獨立函式出現在另外三個程式中，各是1400~1600的行數
你他媽的

Tsubaki_1988: 謝謝

剛才在跟這邊的PM釐清需求 看起來又一個不清楚規格的人(這是你談的耶
排名列表不用排序，因為客戶沒有特別要求

fine

我就等著之後客戶驗收不過來找我，到時這就不是bug是追加需求

看起來真的很氣

bevis0430: 氣炸 尤其是和預期的落差太大了
號稱開發經歷11年的人寫這什麼鬼

工程師應該放心大膽地創造技術負債. 身為軟體工程師，你應該要盡量寫出無法維護的程式碼，而且絕對不寫測試。...
想到這篇文章

aos005432: 好恐怖啊

aos005432: 太哭了 放棄專業成就事業

aos005432: 好久以前看過，歷久不衰