作者查詢 / brucetu
作者 brucetu 在 PTT [ Soft_Job ] 看板的留言(推文), 共3061則
限定看板:Soft_Job
看板排序:
全部Soft_Job3061Gossiping1835DigiCurrency1729Stock484WomenTalk315CareerPlan166Storage_Zone121CodeJob93DIABLO79Boy-Girl59Broad_Band59C_Chat35NTPU-CSIE9734graduate27StarCraft23home-sale17HsinTien15Japan_Travel12Tech_Job12Finance8Option7PttLifeLaw7PC_Shopping6WOW6Aves5Bank_Service5GetMarry5Isayama5Japan_Living5L_LifeJob5e-seller4eSports4Old-Games4Salary4Grad-ProbAsk3Plant3San-Ying3toberich3WoodworkDIY3Android2Diary2iOS2joke2nCoV20192NTPU_TALK2Physics2StupidClown2Bitcoiners1CATCH1FengYuan1ForeignEX1Gemini1HANGUKMAL1Jay1Minecraft1Pisces1Visual_Basic1<< 收起看板(57)
18F→: 呃 這個如果沒辦法明顯看出是O(N) 應該是很少做演算法12/06 00:32
19F→: 也沒在刷題12/06 00:32
20F→: 就算真的第一眼沒認真看 沒看出來 原作者已經給解釋了12/06 00:34
21F→: 真的就只是一個剛愎自用的面試官12/06 00:34
22F→: 應該是拉不下臉承認看錯12/06 00:34
15F噓: 完美示範為什麼要考刷題12/06 00:29
24F→: set access 這邊因為char只有英數 跟超長字串的N比起來12/06 00:14
25F→: 當作O(1)是沒問題12/06 00:14
26F→: 那個set的大小頂多就10個數字+26個英數字大小寫12/06 00:15
27F→: 因為L不會倒退 沒錯 如果L有可能倒退 那很有可能12/06 00:19
28F→: 會是一個worst case O(N^2)的問題12/06 00:19
29F→: *上兩行是回ntpuisbest12/06 00:21
27F→: 你去產品經理的社群問吧..推文一堆奇怪想法12/03 12:48
28F→: 叫你先學UI/UX的 還是專案經理產品經理分不清楚的12/03 12:49
24F→: 讀寫比例 預估資料總筆數 峰值流量 日常流量12/03 12:35
25F→: 這些都會影響你要用哪種方式實作12/03 12:36
26F→: 但有一個很簡單的準則就是 如果你小公司 流量小12/03 12:36
27F→: 就用寫code最快的方式讓memory去扛一切的問題12/03 12:36
28F→: 你家CTO提出的辦法基本上就是寫code最快最懶的方法12/03 12:38
29F→: 也就是最省成本12/03 12:38
30F→: 建議你就做 萬一效能爆炸 增加硬體成本 責任不在你12/03 12:39
12F→: 我覺得你這個兇猛事件的簡述聽起來老闆很雷11/26 18:46
24F→: 只要請到好的工程師 設計 PM11/25 12:56
25F→: 事情都做好 上頭只要講講這種幹話即可 領導有方11/25 12:56
26F→: 大家還會說 阿高層最重要的任務本來就是用對人11/25 12:56
25F→: 你做好一版 馬上把所有可能被影響的loader/area重跑 比11/22 17:12
26F→: 對實際被影響的資料是否符合你預期 先建立這樣的系統避免11/22 17:12
27F→: 改A壞B沒發現 再來談重構11/22 17:12
28F→: 會發生改a壞b表示你有共用的code卻允許共用的其中一個需11/22 17:14
29F→: 求端任意更改 這當然不正常, 如果一種東西會被多個需求11/22 17:14
30F→: 端各自提需求修改 那這種東西不論有多相似 都應該建立單11/22 17:14
31F→: 獨的class11/22 17:14
32F→: 你的整個重構會很複雜不是你一人一兩個月就能完成 一定要11/22 17:15
33F→: 先建立確保不會改A壞B的機制11/22 17:15
34F→: 你這正常的架構就是要先定義原始資料類別有哪些, 聚合資11/22 17:16
35F→: 料的filter有哪些11/22 17:16
36F→: 你的loader程式應該要給每個最終報表有適當的命名 同時11/22 17:19
37F→: 有文件紀錄每個報表會有哪些單位查看11/22 17:19
38F→: 每一支報表由哪些資料源以及哪些filter算出中間的結果以11/22 17:25
39F→: 及最終報表 要有文件11/22 17:25
40F→: 當有人跟你說 他要增加採計AA類別 你就去查程式 採計AA11/22 17:30
41F→: 類別這個行為是哪一支filter在處理, 有其他單位用到嗎?11/22 17:30
42F→: 如果沒有 那大概就是直接修改這支filter 最終報表就會是11/22 17:30
43F→: 他要的結果 也不影響別的單位. 如果有其他單位用到 你可11/22 17:30
44F→: 能需要拆分成兩支filter給兩個單位使用 或是你的這個filt11/22 17:30
45F→: er可以吃參數 那就是兩個area吃不同config即可. 最重要是11/22 17:30
46F→: 不管你的架構如何 改完就是要測試確保沒有動到不該動的11/22 17:30
47F→: 東西 這就是測試的覆蓋率的重要性11/22 17:30
48F→: 最後建議 直接換工作11/22 17:31
3F→: 是也不用這樣審啦XD 光是他的履歷加上年輕就退休11/13 21:52
4F→: 已經可以算強者了吧 原串也不是要問世上最強的開發者是誰11/13 21:53
16F→: 我覺得他說的救火不是跳進去寫code 一年兩百多個是要11/12 23:21
17F→: 每天都開不一樣的project出來改code commit喔 不可能11/12 23:21
18F→: 你們的問題只是對救火的定義不同11/12 23:21
19F→: 可能是看一看 直接給個解決方案 底下人去做就好11/12 23:23
20F→: 但他不去救 原本的團隊就想不出適合的解 這樣算不算救火11/12 23:24
21F→: 更正 三年兩百 不是一年兩百 但還是一樣11/12 23:25
22F→: 三年對兩百份專案commit這個管理就不合理了11/12 23:26