作者accessdenied (存取違規)
看板Soft_Job
標題Re: [請益] 工作四年多開始迷惘
時間Sun Apr 15 20:02:05 2018
還是很多人對 clean code 的烏托邦有著不切實際的夢想....
醒醒看看 real world 的例子吧......
下面都是真人真事
有一天，客服接到客訴，客人發現我們用戶條款有模糊不清的地方，導致客人使用我們的
服務權益受損。因為某個功能，原本設定為VIP方案才能使用，但用戶權益沒有釐清，導
致這個初階用戶認為自己應該也享有這個功能。
在解說無效下（通常都是無效的），客戶要求退費並且威脅要 消保官和發文抹黑，客服
經理當然為了公司品牌、保全用戶，決定個案處理讓這位客戶能特別使用這個VIP功能...
.，並且承諾明天就生效。
回到 RD 場景，這種 Member.Level 1 的客人要能夠使用 某特定 Level 3 的功能，而且
不是所有 Level 3 都能用，只有某一隻 Level 3 的功能....
幹，明天就要生效？RD 默默地下 SQL 查出這位客戶的 ID, 在那隻 Level 3的功能的 au
thorize code 寫下一行非常骯髒的
if (cid == 65432) return true;
上版。
事情過後，客戶不吵了，RD 內部安排要不要 重購 這個 hotfix, 在 Db 內設定一個exce
ptional member 的資料表，讓客服可以有 UI 設定這種 Level 不到位的特殊顧客？
客服經理說：不用，這種情況不會再發生！我們已經更新的客戶權益說明，排除這種誤解
！不會再有下一人！
RD 面面相覷，客服經理說不會再發生，那我們還需要投入資源做一個例外模組嗎？還是
就讓那個帶著 magic number 的怪異 if 停留在程式碼中？
真實世界的選項是什麼，相信大家猜得到。
過幾天，又發生公司因為系統上版過久，超過官網公告的 downtime 維護時間。等著使用
公司系統的用戶逐一抗議自己的權益受損，支付吃到飽的費用卻超過公告時間無法使用..
..
接下來談的補償辦法，又是目前系統根本沒有設計過的方式，跟上面提到超越Level限制
又是不同的作法。RD 們又開始那著這些客戶清單，一條條地輸入
If (cid == .....
回頭來看，當初沒有開發那個 Level 例外的模組是對的，因為後面發生的例外處理，解
決方案是什麼根本無法預料！
但是，這就是「營運」啊！這些處理真的就讓公司能在市場上繼續發光發熱！
就連 MS 也做過類似的事情，這未來有空再說。
這些dirty code有沒有影響未來系統的修改？
有的！像是這些寫死的邏輯，那些客戶現在還在使用嗎？還是早就解約離開了？還在使用
的，我們更新功能要怎麼維持當初客服保證的補償不會受影響？
這些都變成修改系統的干擾。
但是，這些頂多增加修改的成本和難度，卻沒有害當初公司業務根本做不起來。
這就是一種技術債槓桿。
我想問那些把 clean code 和 DP 看得甚高的工程師們，在這樣現實的商業生活中，你會
怎麼做的讓我刮目相看呢？
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.135.20.48
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1523793727.A.CA1.html
1F：推 Vendy: 滿實在的XD… 04/15 20:08
2F：推 BignoZe: 這你們系統架構的問題, user 跟權限在資料庫本來就應該分 04/15 20:09
3F：→ BignoZe: 開,每個功能都有一個開關。或是用role based 來管理權限 04/15 20:09
4F：→ BignoZe: 。 04/15 20:09
5F：推 jack1218: 很無奈 04/15 20:09
6F：→ accessdenied: BignoZe 顯然你沒有搞懂，系統架構只能處理能夠預 04/15 20:13
7F：→ accessdenied: 知的問題，無法處理沒有預料到的問題 04/15 20:13
8F：推 expup: 這問題有的時候我覺得產品經理還有老闆的觀念與堅持很重要 04/15 20:14
9F：推 abccbaandy: 樓上正解，很多code會變成這樣，上面的人通常是主因 04/15 20:17
10F：→ accessdenied: 老實說，沒有人能在市場面前堅持什麼的。能夠堅持 04/15 20:17
11F：→ accessdenied: 的，通常已經大到可以寡占的地步，不缺你一個客人 04/15 20:17
12F：推 xam: 我同意expup,如果RD或RD head沒辦法捍衛自己的原則跟自己維護 04/15 20:17
13F：→ xam: 的程式,就是只能跟著沉淪或者一走了之, 二選一.. 04/15 20:18
14F：→ accessdenied: 樓上，那我就要問，公司要擴大市佔，保護品牌，RD l 04/15 20:21
15F：→ accessdenied: ead在那邊堅持或反抗，那RD究竟是助力還是阻力 04/15 20:21
16F：推 peter9s3b: 上頭開出跟原設計牴觸的需求，就只能貼藥膏了 04/15 20:22
17F：推 vi000246: 直接在權限系統新增一個該客戶專用的角色就好了 04/15 20:23
18F：→ vi000246: 我們公司也是 常常有這種小規則特例...... 04/15 20:24
19F：推 xam: 如果那個技術債留在哪裡,你會常看到,常改到,會造成維護成本 04/15 20:24
20F：→ vi000246: 反正時間到我就跑了 懶得重構 主管要幹啥隨便他吧 04/15 20:25
21F：→ xam: 那你就值得花時間幫特例重構,如果是很久都碰不到,那就隨個人 04/15 20:26
22F：→ xam: 重構的開發成本就跟RD head報工時,如果主事者知道不好但不想 04/15 20:28
23F：→ accessdenied: 討論還是就不要深究實作，因為我並沒有提供詳細的系 04/15 20:28
24F：→ accessdenied: 統內部設計的資訊，單純只有這個scenario 是真人真 04/15 20:28
25F：→ accessdenied: 事 04/15 20:28
26F：→ xam: 改進,或是連壞氣味都不懂,你做的又痛苦,那還不快逃? 04/15 20:28
27F：推 superpai: 這個例子實在是達不到寫不出clean code 的程度 04/15 20:46
28F：→ pttworld: 外包商根本不能反抗 04/15 20:46
29F：推 codehard: 任何事都有成本 只是成本誰擔而已 這個案例就是RD擔 等 04/15 20:49
30F：→ codehard: 哪天RD不擔跑了 就看什麼時候爆炸 不是不報 時候未到罷 04/15 20:49
31F：→ codehard: 了 04/15 20:49
32F：推 XXXXLAY: XD 04/15 20:50
33F：推 PUTOUCHANG: 商業上許多妥協是必要之惡 04/15 20:56
34F：→ PUTOUCHANG: 理念上我們要追求clean譴責dirty現實中只能無奈 04/15 20:58
35F：推 rodion: 原本產品假設被broken 這是spec問題 哪是clean code要管的 04/15 21:01
36F：推 del680202: 用dirty去硬解商業需求 管不了clean不clean 是這意思吧 04/15 21:05
37F：推 BignoZe: 系統架構就沒有考慮到未來的彈性呀 功能開開關關的很正常 04/15 21:07
38F：→ BignoZe: 設計的人經驗不夠 導致要寫爛code來處理 都怪別人就飽了 04/15 21:07
39F：→ BignoZe: 呀 04/15 21:07
40F：→ accessdenied: Spec 只是 paper, change implement 難道不是 code? 04/15 21:09
41F：→ accessdenied: 那我還真不懂 clean code 是幹嘛的 04/15 21:09
42F：→ accessdenied: BignoZe 彈性都是事後講講的幹話而已，需求永遠都會 04/15 21:10
43F：→ accessdenied: 超過你預期的彈性 04/15 21:10
44F：→ accessdenied: 而且你也不知道真實系統是什麼樣子，就不要秀下限了 04/15 21:12
45F：→ accessdenied: ，怪「不夠彈性」大概是最無能的manager口頭禪了沒 04/15 21:12
46F：→ accessdenied: 有之一 04/15 21:12
47F：推 art1: 超過了不就是要重構了嗎？ 還是說重構一定要大規模才可？ 04/15 21:12
48F：→ Argos: 事實上 clean code與敏捷開發 就是為了解決你提的那個真實 04/15 21:12
49F：→ accessdenied: 這種業務主管每天講的幹話你就不要拿來降低自己身 04/15 21:12
50F：→ accessdenied: 價了 04/15 21:12
51F：→ Argos: 案例 但你顯然完全不懂該技術的眉角在哪裡 解釋也是對牛彈 04/15 21:12
52F：→ Argos: 琴吧？XD 不如自己去書店翻翻書如何？ 04/15 21:13
53F：→ Argos: 一堆書裡比你這案例更誇張的都有 也有提出一些準則 04/15 21:13
54F：→ Argos: 當然啦 如果你從頭到尾還是對這個沒概念 那就繼續打高空 04/15 21:14
55F：推 del680202: 不過就我自己在一線跟客戶嘴砲的經驗來看 原文案例的 04/15 21:15
56F：→ del680202: 客服經理問題也很大就是 沒有發揮緩衝的功用 04/15 21:15
57F：→ Argos: clean code與一些設計準則當然不是銀彈 我還沒見過有誰敢說 04/15 21:16
58F：→ Argos: 這些東西是銀彈 但真的完全沒有價值 FLAG與網路上一狗票大 04/15 21:16
59F：→ Argos: 神也不會這麼重視這些了 是吧？ 04/15 21:16
60F：→ Argos: 要戰這些喔 煩請自己google吧 歐美已經戰好幾年了XD 04/15 21:18
61F：→ Argos: DHH之前也戰過TDD啊 XD 04/15 21:18
62F：推 atpx: 現實上不管當初怎麼設計, 永遠就是會出現目前規劃無法處理的 04/15 21:18
63F：→ atpx: 狀況 04/15 21:18
64F：→ atpx: 要談設計準則, 先討論設計的是應用系統還是工具軟體吧 04/15 21:19
65F：推 Sunal: 是阿 現實就是如此 但是發生第一個例子時就開始重構 04/15 21:19
66F：→ Sunal: 似乎也不夠現實 04/15 21:19
67F：→ atpx: 應用軟體永遠都要考慮到完全相反的使用, 這是現實環境使然 04/15 21:20
68F：→ atpx: 工具軟體當然可以很瀟灑地說目前不支援 04/15 21:20
69F：→ Argos: 沒有錯 需求永遠在變 所以才需要重構 所以才需要測試 04/15 21:20
70F：→ landlord: 其實工程師真正的專業是在剛好的欠債，漂亮的還債。既 04/15 21:20
71F：→ landlord: 設計的剛好，不過度設計，又能因應變化時不傷筋動骨。 04/15 21:20
72F：→ landlord: 架構不會好高騖遠，殺雞用牛刀，懂domain跟限制，才能 04/15 21:20
73F：→ landlord: 剛好，剛好才是最好，但這得有clean code當基本功。不 04/15 21:20
74F：→ landlord: 然就是只欠債，拿credit，債讓別人還，自己爽的咖。 04/15 21:20
75F：推 BignoZe: 這麼簡單的需求都能弄成這樣 我也是滿佩服 你開一個table 04/15 21:21
76F：→ Argos: 我的意思是 需求一直在變不能拿來當寫爛code的理由就是了 04/15 21:21
77F：→ atpx: 不過現實上留債給別人的咖洨才是績效好的, 因為速度快 04/15 21:22
78F：→ BignoZe: 根據不同地方要開關的功能 select 出 user 來不就好了 04/15 21:22
79F：→ BignoZe: 寫成這樣還要怪東怪西的 還怪別人秀下限 也是幽默XD 04/15 21:22
80F：→ atpx: 維護性跟clean code對長官來說根本無用 04/15 21:23
81F：→ Argos: 對長官無用 但對工程師有用的 你也不想寫出來的東西整天出 04/15 21:23
82F：→ Argos: bug 搞得長官不信任你的程式吧？XD 04/15 21:24
83F：→ Argos: 事實已經證明 沒顧慮到維護性 程式寫出來出包機率高太多阿 04/15 21:24
84F：→ Argos: 你做這些工 並不是為了公司長官 是為了你自己好吧 XD 04/15 21:25
85F：推 atpx: nono~ 這些東西爆炸的時候, 當初開發的人已經不知道去哪了 04/15 21:25
86F：→ Argos: 還是你覺得義大利麵寫法 處處workaround 出錯率會比好好整 04/15 21:25
87F：→ accessdenied: BignoZe你還在糾結你自己的實作和想像出來的系統， 04/15 21:25
88F：→ accessdenied: 那就不奉陪了，自己玩沙吧 04/15 21:25
89F：→ Argos: 裡過的code來得低？呵呵 那當我的話耳邊風囉 04/15 21:25
90F：推 oneheat: 那你也應該修改level曾經而不是做cid== 好嗎 04/15 21:26
91F：→ Argos: 東西爆炸人已經不知去哪 那你就特別倒楣阿 XD這無解 04/15 21:26
92F：→ atpx: 先說好, 我也是基本教義派, 現實上是觀察到流債的咖洨績效好 04/15 21:26
93F：→ Argos: 你只能 1.好好重構 日後開心維護 2.先改再說別管了 然後之 04/15 21:27
94F：推 BignoZe: 歡迎你舉出更難的例子喔 這個太好解了 不忍噓XD 04/15 21:27
95F：→ Argos: 後又出包 你還是要回去痛苦加班 3.離職 XD 04/15 21:27
96F：→ accessdenied: oneheat 修改level等於所有客戶都受影響，而不是只 04/15 21:27
97F：→ accessdenied: 有來電的那位...... 04/15 21:27
98F：推 oneheat: 技術差靠邀技術不對，這種現象很常見啊 04/15 21:27
99F：→ oneheat: 當然是修改該用戶的層級，怎麼會牽扯到其他人？ 04/15 21:28
100F：→ Argos: 解法太多了 但前題是 有好好寫了測試 也懂得怎麼重構 XD 04/15 21:29
101F：→ accessdenied: 那就是所有vip的功能他都能用，而不是只有某一隻... 04/15 21:29
102F：→ accessdenied: 你沒看清楚情境 04/15 21:29
103F：→ Argos: 顯然 很多人完全不懂 也不想懂 然後就拋問題 覺得無解 XD 04/15 21:29
104F：→ Argos: 把爛code都歸咎於這個喔 嗯 很棒的藉口囉 04/15 21:29
105F：→ oneheat: 當然有啊，大哥，就說一種方式是修改該用戶的層級了 04/15 21:29
106F：→ Argos: 留債的咖績效好？那你該考慮的是換公司吧？XD 04/15 21:31
107F：推 atpx: 樓上, 原po的情境就是客戶層級只有一個變數代表阿 04/15 21:31
108F：→ atpx: 樓樓上 04/15 21:31
109F：推 del680202: 很多案例是 掉坑》先改在說然後不管》一陣子後自然有新 04/15 21:31
110F：→ del680202: 的衰鬼接你的坑 04/15 21:31
111F：推 oneheat: 貴公司的問題看起來更像是設計階段考慮的就太少，開發階 04/15 21:32
112F：→ oneheat: 段擴充性又不夠 04/15 21:32
113F：→ atpx: 一改就可以用全部的VIP功能了, 這就不對 04/15 21:32
114F：推 oneheat: 要看他們level是怎麼定義的啊，最差新增一個level也比cid 04/15 21:33
115F：→ oneheat: 的方式好 04/15 21:33
116F：→ oneheat: 而正常的設計，不會只有一個level去應對到所有的功能權 04/15 21:34
117F：→ oneheat: 限 04/15 21:34
118F：→ Argos: 先改不管 有衰鬼接 你怎麼能肯定衰鬼不會是你自己 XDDDD 04/15 21:36
119F：噓 smallchocho: 應該說,在可預期的地方做到Clean， 04/15 21:36
120F：→ smallchocho: 才能夠有讓非預期狀況Dirty的空間， 04/15 21:36
121F：→ smallchocho: 如果全部都是一團炒麵，那我想所謂的 04/15 21:36
122F：→ smallchocho: ”明天用Dirty code上線”也會是天方夜談吧， 04/15 21:36
123F：→ smallchocho: Clean好處無庸置疑，但這個詞是相對而非絕對 04/15 21:36
124F：→ Argos: 那剛好是你自己不就作死了 04/15 21:36
125F：推 oneheat: 應該先思考一下當發生例外的時候，你們的系統的要怎麼擴 04/15 21:37
126F：→ oneheat: 充，是否具備彈性容易調整外掛上去等等 04/15 21:37
127F：→ oneheat: 一個level就要map到所有功能，又不具備分層的概念，這樣 04/15 21:38
128F：→ oneheat: 的設計然後說要設計無用，到底是無用還是不會用呢？ 04/15 21:38
129F：→ accessdenied: oneheat 設計思考的夠不夠，這是事後打高炮。需求一 04/15 21:40
130F：→ accessdenied: 開始就是一個客戶只會有一個等級。這就是91大剛剛 04/15 21:40
131F：→ accessdenied: 說不要過度設計的理由。但是身為推動公司營利的角 04/15 21:40
132F：→ accessdenied: 色，我不會拿當初開的需求去打客服主管臉，而是想 04/15 21:40
133F：→ accessdenied: 辦法做到，就這個差別 04/15 21:40
134F：推 oneheat: 對岸BAT之一就這麼做的，誰跟你打高砲 04/15 21:41
135F：推 oneheat: 簡單一個問題啦，exception 模組你有考慮到嗎？怎麼擴充 04/15 21:42
136F：→ oneheat: ？內嵌的代碼彈性如何？這是設計階段就要想到的，打什麼 04/15 21:42
137F：→ oneheat: 高砲 04/15 21:42
138F：→ MOONY135: 要有原則 但太有原則 你就升不上去 04/15 21:43
139F：→ Argos: 在第二次出現例外狀況就應該要重構設計了 對著客戶清單一條 04/15 21:43
140F：→ Argos: 一條寫if 那如果有一萬個客戶不就完蛋惹 XD 04/15 21:44
141F：→ oneheat: 程式語言都有提供exception的概念了，何況是系統設計呢？ 04/15 21:44
142F：→ xam: 業務說一個客戶只有一個等級,是你的系統要滿足的最低需求,你 04/15 21:45
143F：→ oneheat: @Argos 一定不是一條一條加的，最爛也該有個exception ru 04/15 21:45
144F：→ oneheat: le or field去判斷是否符合該狀態，才做對應的處理 04/15 21:45
145F：→ Argos: 貴司已經有兩次紀錄 因為客戶吵就給糖吃 這時CTO應該就知道 04/15 21:45
146F：→ xam: 的系統可以支援的更多,就是你設計的彈性,不是不能作,是看你 04/15 21:46
147F：→ Argos: 未來這間公司 肯定是還會在開放例外的吧？ 04/15 21:46
148F：→ xam: 會不會作跟要不要作而已. 04/15 21:46
149F：→ Argos: 也就是未來這位客服經理講的話 請不要當一回事 04/15 21:47
150F：推 oneheat: 就經驗不夠設計不足或者是看過的東西太少，先怪這東西無 04/15 21:47
151F：→ oneheat: 用再說，這種是很常見沒錯 04/15 21:47
152F：→ oneheat: 有例外真的不是重點，java也有例外處理啊，重點是當例外 04/15 21:48
153F：→ oneheat: 發生的時候，系統要怎樣去外掛上這樣的例外處理才是重點 04/15 21:48
154F：推 Timba: 淦 笑死 .... 不過自己遇到 以前遇到都笑不出來 04/15 21:50
155F：→ Argos: 如何建構可以任意開放例外權限的功能 現在就應該納入時程裡 04/15 21:52
156F：→ Argos: 還是一個準則 遇到容易改變或預期會改變的 就盡量抽象化 04/15 21:53
157F：推 oneheat: 初期設計就沒考慮exception的話，真的只能套句版上愛說 04/15 21:54
158F：→ oneheat: 的，快逃啊！這樣的公司期待學到什麼@@ 04/15 21:54
159F：→ Argos: 但最常遇到的就是這邊根本不太可能改變卻改變了 那就是重構 04/15 21:54
160F：→ Argos: 之時 把這塊修成可以適應變化的 系統設計本來就慢慢在演化 04/15 21:55
161F：→ Argos: 這個策略也不是我講的 事實上各大企業開發多半都是這策略吧 04/15 21:56
162F：→ MOONY135: 通常是哪來的時間重構 有洞補洞 04/15 21:56
163F：→ Argos: 時程問題又是另一個戰場囉XD 這牽涉到的東西又更多了 04/15 21:58
164F：推 xam: 重構派總是會擠出時間重構,反重構派總是會擠出藉口不重構 04/15 21:58
165F：→ Argos: 強的可以一週就重構好 弱的可能三個月 那怎麼解？XD 04/15 21:58
166F：→ PUTOUCHANG: 理想是豐腴的, 現實是骨感的 04/15 21:58
167F：推 oneheat: Refactoring也有bottom up的，沒人說一定要top down吧 04/15 21:59
168F：→ Argos: 理想通常當然只是理想 這也是為何沒有銀彈的原因 04/15 21:59
169F：→ Argos: 但不能因為達不到100% 就連1%都不做 這不是拿來當藉口的吧 04/15 21:59
170F：推 askacis: 開一個黑名單/白名單模組處理這個鳥事,linux driver很多 04/15 22:00
171F：→ Argos: 說真的 這些方法準則 通通基於在一個前題之下 04/15 22:00
172F：→ askacis: 時候為了相容各家chip也大多都是這樣處理的 04/15 22:00
173F：→ Argos: 也就是有一批人是積極態度想解決一定程度的問題 04/15 22:01
174F：→ Argos: 但有一批人 就認為這太理想化 連動手都不肯動手就放棄了 04/15 22:01
175F：→ Argos: 但事實是 有做就是有改善 今天有改善10% 那也是改善 04/15 22:02
176F：→ MOONY135: 反正時程通通*2 就有時間重構了 04/15 22:02
177F：推 oneheat: 這也不是理不理想的問題而是後續疊加代碼需要付出多少資 04/15 22:03
178F：→ oneheat: 源的問題吧 04/15 22:03
179F：→ oneheat: 重構的目的是為了讓將來的開發更有效率，如果重構的時間* 04/15 22:04
180F：→ oneheat: 2 將來開發也沒比較省，那的確沒有重構的意義 04/15 22:04
181F：→ testPtt: 看來像趕時間的手法 客戶少我可能也會這麼做吧 04/15 22:04
182F：→ Argos: 其實變因太多了 原文案例 也沒寫這是新創 還是大公司 系統 04/15 22:05
183F：→ Argos: 整體複雜度 人員組成 公司風氣 這全是變因啊 XD 04/15 22:05
184F：→ Argos: 同樣問題 出在三人公司與出在Google裡 完全不一樣解法啊 XD 04/15 22:06
185F：→ Argos: 所以說 不如說 打從一開始這完全就在打高空 XD 04/15 22:07
186F：推 oneheat: 這家公司沒記錯的話一年付300萬給樓主，是三人公司也太.. 04/15 22:08
187F：→ oneheat: . 04/15 22:08
188F：→ pttworld: 文中的level是群組概念，怎麼有人不懂 04/15 22:10
189F：→ Argos: 說不定這他朋友新創企業嘛XD 前不著村後不著店的 就當聊聊 04/15 22:10
190F：→ xam: 查了之前的紀錄,看來跟他解釋重構是對牛彈琴.. QQ 04/15 22:14
191F：→ yyc1217: 如果是role based 就可以新增一個"奧客"權限了 04/15 22:24
192F：推 y3k: 是我的話這種判斷就算要下 也是要擠到同一個class裡面處理 04/15 22:30
193F：→ y3k: 想不到這種做法的人我不認為他程式設計專業到哪裡去 04/15 22:30
194F：→ y3k: 你這篇文章實在是有為這種無能找藉口開脫的嫌疑 04/15 22:32
195F：→ landlord: 線上incident牽扯到商譽跟重要命脈的，緊急程度一定遠 04/15 22:38
196F：→ landlord: 高於乾淨程度。先用最快有效的方法解決線上問題絕對合 04/15 22:38
197F：→ landlord: 理。但工程師專業在於怎麼讓重複、類似的問題不會發生 04/15 22:38
198F：→ landlord: 第二次，或是未來怎麼在設計上避免這問題再發生，怎麼 04/15 22:38
199F：→ landlord: 用最小成本埋下擴充彈性，不重複自己犯的錯，也是成長 04/15 22:39
200F：→ landlord: 的一環。解決問題跟滿足需求仍然是價值的最高權重，但 04/15 22:39
201F：→ landlord: 技術如果捨棄，就會降低自己解決問題跟滿足需求的可能 04/15 22:39
202F：→ landlord: 性跟可行性。一味只追求高大上的技術、名詞或潮流，當 04/15 22:39
203F：→ landlord: 然也不容易在限制內用最剛好的解決方案，就像太空梭上 04/15 22:39
204F：→ landlord: 用鉛筆的例子一樣。 04/15 22:39
205F：→ y3k: Code在某些情況下是會變得髒 這很無奈 而且很多時候不是RD的 04/15 22:39
206F：→ landlord: 線上緊急問題用最快方式解，既然這問題影響程度這麼大 04/15 22:40
207F：→ landlord: ，就該想辦法根本解，除非無解。 04/15 22:40
208F：→ y3k: 問題 但是RD要有本事讓這個髒污不要滲到根處 在合理的cost下 04/15 22:40
209F：噓 Masakiad: 各位都很客氣我只好第一噓了，營運服務的系統會沒預先 04/15 22:41
210F：→ Masakiad: 考慮這麼基本的例外客戶我也是笑笑。就算當下不做也早 04/15 22:41
211F：→ Masakiad: 該架構上開出擴充的彈性。啊，我忘了樓主只會商業模式 04/15 22:41
212F：→ Masakiad: 不會設計模式啦。沒關係你就用商業導向解吧，反正最後 04/15 22:41
213F：→ Masakiad: 還是要花錢請高手回來重構。 04/15 22:41
214F：→ ku399999: 技術債槓桿就是你認為系統能承受多少技術債?不是不能做 04/15 22:42
215F：→ ku399999: 而是你有沒有打算還?何時?事實是大多公司都不打算還啊 04/15 22:42
216F：→ ku399999: 不還債的工程師在市場上是什麼價位?還是不當工程師? 04/15 22:44
217F：→ Masakiad: 這種心態就是覺得技術債利息少直接忽視，久了就一次痛 04/15 22:45
218F：→ Masakiad: 還大筆的到時候會不會賺還不知道，有的還還不出債咧！ 04/15 22:45
219F：→ ku399999: 反正到時候幹這些事的工程師離職給後面的人去死 做到功 04/15 22:49
220F：→ ku399999: 能自己都覺得加不上去擺爛 主管只好請新進人員重寫一個 04/15 22:50
221F：→ ku399999: 的例子也不是沒有啊 最後人家還不是不續約 04/15 22:50
222F：推 takingblue: 推這篇，理想的lean code只能在open source project 04/15 22:53
223F：→ takingblue: ，商業世界一切以營運為主 04/15 22:53
224F：→ Argos: 同意緊急事態當然先修再說 但你終究還是得要回來面對的 04/15 22:54
225F：→ Argos: 大家完全忽視髒code所帶來的風險 其實完全不小於客戶在吵 04/15 22:54
226F：→ Argos: 寫髒東西沒事時都沒事 等到哪天某工程師失手 權限給錯了給 04/15 22:55
227F：→ vi000246: 即使資料庫沒做角色資料表 程式面也是能補足的 04/15 22:55
228F：→ vi000246: 就像landlord大說的 用class把權限判斷包起來 04/15 22:56
229F：→ Argos: 到admin等級的 或是把VIP不小心降級成停權的 那就.....XD 04/15 22:56
230F：→ vi000246: 再怎麼改也不會到處都是if判斷 04/15 22:56
231F：→ Argos: 啊不要以為不會發生這種事 哪個不熟的新人進來 髒code看沒 04/15 22:56
232F：→ ku399999: 一個公司如果行銷跟財務都想著錢砸越多效果越好 不計成 04/15 22:57
233F：→ Argos: 很懂就改了 一下就出事了啊 XDDDD 04/15 22:57
234F：→ vi000246: 說錯 是y3k大 04/15 22:57
235F：→ pttworld: 專案外包的技術債還不出來就約滿不續，錢有賺就好 04/15 22:57
236F：→ ku399999: 本的花錢行銷 沒人踩煞車這樣真的有比較好嗎 04/15 22:57
237F：推 oneheat: 而且，一般coding也會儘量寫65432 == cid 啦 04/15 23:01
238F：推 oneheat: 滿種程度蠻羨慕這樣的公司能發300萬給樓主的，應該是某 04/15 23:02
239F：→ oneheat: 寡占企業吧 04/15 23:02
240F：推 kimkao: 緊急到立刻要有解的，當然先能解就先上! 04/15 23:05
241F：→ kimkao: 但接著要考慮的是你持續的穩定與可維護性的問題 04/15 23:06
242F：→ Argos: 其實後來想到 應該是該公司客戶權限並不是很重要才會這樣 04/15 23:06
243F：→ kimkao: 技術債不是個非0則1的問題，除了你知道可以晚一點還債 04/15 23:06
244F：→ Argos: 你試試看銀行系統權限這樣玩玩看 XD 04/15 23:07
245F：→ kimkao: 更要考慮你是否還具備這樣的能力還債!如果一直都是跳過 04/15 23:07
246F：→ kimkao: 會越來越沒能力~ 04/15 23:07
247F：→ Argos: 完全不在乎髒code帶來的bug風險 大概內部也沒有code review 04/15 23:08
248F：→ Argos: 測試也是簡單人工測幾次就先上線再說 心臟放大顆福利自然來 04/15 23:08
249F：→ ku399999: 就是覺得新人進入難度不是成本 誰來都可以做不差你一個 04/15 23:09
250F：→ ku399999: 難維護你家的事 加班做就好了 死都死別人當然沒差 04/15 23:09
251F：→ Argos: 死別人當然是沒什麼關係啦XD 工程師出大包火掉就好 但客戶 04/15 23:10
252F：→ ku399999: 工程師就消耗品 04/15 23:10
253F：→ Argos: 那邊是你公司自行承擔 這樣run公司也蠻強大的 富貴險中求XD 04/15 23:10
254F：→ Argos: 反正到時如果有工程師開錯權限 客戶經理再道歉開更多權限吧 04/15 23:12
255F：→ ku399999: 我上面有舉例了 需求致上最後客戶也是會不續約啊 04/15 23:14
256F：推 Csongs: 這就是產業sa的價值 04/15 23:17
257F：→ ku399999: 因公司營運叫工程師不要注重程式品質無助工程師職涯發展 04/15 23:17
258F：推 justben: const magic numbers 在開頭 而且一開始就要註解 04/15 23:44
259F：→ justben: 抽一個檔案 define if xxx version do 0000 things 04/15 23:45
260F：→ justben: 大概也只能這樣了 04/15 23:45
261F：推 deray: 要用3個=== 04/15 23:47
262F：噓 dfgh012316: 同意Masakiad大見解 04/16 00:01
263F：→ lovdkkkk: 同 superpai, 這例子... 04/16 00:03
264F：推 god145145: 多少pay出多少code 很明顯是不想多花錢 04/16 00:25
265F：推 asleisureto: 問下為何寫成65432 == cid會比較好@@? 04/16 01:14
266F：→ sorryla: 內文的例子就看得出工程師的水準，這種基本的例外處理還 04/16 01:16
267F：→ sorryla: 需要花時間去寫一堆if？ 04/16 01:16
268F：推 ckp4131025: 65432擺前面不會有null而crash的問題 04/16 01:33
269F：→ accessdenied: 常數值放作罷只是 equal 避免寫成 assign 的防呆而 04/16 01:47
270F：→ accessdenied: 已，這種 lvalue rvalue 左右值的拿來判斷工程師素 04/16 01:47
271F：→ accessdenied: 質也太腦補了吧 04/16 01:47
272F：→ accessdenied: *常數值放左邊 04/16 01:47
273F：推 twin2: 可以看的出很多人會繼續堅持要clean code然後修復太慢最後 04/16 01:51
274F：→ twin2: 商譽受損怪到當初出設計的人身上,你要帶著技術信仰的純工程 04/16 01:51
275F：→ twin2: 師了解管理中為結果負責的概念太難 04/16 01:51
276F：→ konkonchou: 不好好作SA, 換來就是 quick and dirty code 04/16 02:42
277F：推 bibo9901: 從沒聽過礦工會變煤老闆的 04/16 04:47
278F：推 mathrew: 很實在啊 04/16 07:26
279F：→ mathrew: 不是很同意M大，這篇寫的只是比較讓大家容易看得懂 04/16 07:27
280F：→ mathrew: 實務上，並不會只有遇到這幾種狀況，很難全部都想到 04/16 07:28
281F：推 cookie1115: 推Masakiad 04/16 07:36
282F：推 zzshcool: 滿貼切的xddd 04/16 07:59
283F：→ ku399999: 認真回覆的不回 回那種東西...唉 04/16 08:51
284F：→ ku399999: 商譽受損? 沒看人家工程師還不是照辦 哪裡受損? 04/16 08:53
285F：推 GoalBased: 這個東西向不是很簡單嗎。。能討論成這樣 04/16 08:54
286F：→ ku399999: 可能這就是他能舉出最嚴重的技術債了 04/16 08:57
287F：推 clarkman: 老實說按照以前的工作經驗，跑好好的城程式不太可能讓人 04/16 09:21
288F：→ clarkman: 重構，除非撇除重新開發的成本，更主要的是如果導致新的 04/16 09:21
289F：→ clarkman: bug出來怎麼辦 04/16 09:21
290F：→ clarkman: 通常長官不太會讓人動這個，除非你已經贏得主管的新任而 04/16 09:23
291F：→ clarkman: 且不影響其他案子的進度，更重要的是出現bug被自己扛責 04/16 09:23
292F：→ clarkman: 任 04/16 09:23
293F：推 steve1012: 看公司吧 我改東西 manager 都挺支持的 04/16 09:24
294F：→ clarkman: 我以前重構過幾次而且也運轉的不錯，但結果是累死自己 04/16 09:24
295F：推 Argos: 真奇怪 我怎麼沒看到有人堅持一定要先重構？XD 04/16 09:43
296F：→ Argos: 支持要好好修改的 不都幾乎同意先用OK蹦止血 但事後有時間 04/16 09:44
297F：→ Argos: 還是得好好整理傷口嗎？我覺得最後重點都在有沒有心而已啦 04/16 09:45
298F：→ Argos: 什麼時程太緊人力不夠需求太多 都是藉口 就算你拖了一年 難 04/16 09:45
299F：→ Argos: 保哪天出事了 還是總得要有人來收爛攤子 04/16 09:46
300F：推 clarkman: 我自己也是重構派的，但我只是講事實，當突發狀況出現， 04/16 09:47
301F：→ clarkman: 用一些方法解決，通常主管不是讓你慢慢重構，而是給你下 04/16 09:47
302F：→ clarkman: 一個任務了 04/16 09:47
303F：→ Argos: 不然就是完全不管 那諸如此類的workaround就會一直發生 04/16 09:47
304F：→ Argos: 然後到最後系統處處充滿了可怕的地雷 工程師整天出包 新需 04/16 09:49
305F：→ Argos: 求加上去時間也更慢 更痛苦 然後有自知之名的工程師就會走 04/16 09:50
306F：推 clarkman: 通常主管原因給你時間和信任慢慢重構是很幸福的 04/16 09:50
307F：→ Argos: 人 後面也徵不到厲害的人來因為該公司名聲就是爛code+不願 04/16 09:50
308F：→ Argos: 意有時間讓人重構 XD 04/16 09:51
309F：→ Argos: 這些問題也不是什麼新題目了 30年前出版的人月神話就講過了 04/16 09:54
310F：→ Argos: 他講的是40年前的軟體工程 看來40年來完全沒啥進步 哈哈 04/16 09:54
311F：推 abccbaandy: 人的問題無解阿...什麼開發流程碰到老闆一句明天要就 04/16 09:57
312F：→ abccbaandy: GG 04/16 09:57
313F：→ hakama99: 這個案例不是加個level就完事了嗎 04/16 09:59
314F：→ hakama99: 有空再重構成用table開關各功能阿 04/16 10:00
315F：→ Argos: 而且很多人都講沒有時間 沒有時間 嗯 時間真的緊到這樣 那 04/16 10:05
316F：→ Argos: 估計也是沒時間code review 也是沒時間做太多測試 也是沒 04/16 10:05
317F：→ Argos: 時間寫系統文件 大概技術部門也沒時間開會討論架構了 XDDDD 04/16 10:06
318F：→ Argos: 然後這麼沒時間 這麼的忙 爛code簡單測測 資深也不用看過先 04/16 10:06
319F：→ Argos: 上線吧 哇喔 好棒 04/16 10:07
320F：→ Argos: 你說這風險會比客戶跑來鬧 威脅要上網黑公司來得小多少 我 04/16 10:08
321F：推 dylan29341: 非常中肯 特地登入上來推 04/16 10:08
322F：→ Argos: 也是笑笑 瞻前也要顧後啊 很多事是一體兩面的 04/16 10:08
323F：→ dylan29341: 尤其對新創更是如此 且戰且走是很重要的概念 04/16 10:09
324F：→ dylan29341: 與其花時間寫無懈可擊的架構 不如先確定你產品有人用 04/16 10:09
325F：→ dylan29341: 未來對於重構需求增加了 公司有錢有閒有人力再來解決 04/16 10:09
326F：→ dylan29341: 在商言商 投入成本與公司獲利要取得最佳解 04/16 10:10
327F：→ Argos: 也是啦 如果今天該公司新創半年 使用者不到萬人 出事也不會 04/16 10:10
328F：→ dylan29341: 有時候是不得已的 04/16 10:10
329F：推 Masakiad: clarkman 有沒有時間重構這不是問題，以本篇案例來說是 04/16 10:10
330F：→ Masakiad: 沒打算重構，只打算workaround 方式走一輩子 04/16 10:10
331F：→ Argos: 有太大的損害 至少老闆不會因此被判刑 那的確隨便即可囉 04/16 10:10
332F：→ Argos: 所以討論這個 還是要看時空背景各個條件阿 不然就打高空阿 04/16 10:11
333F：噓 Masakiad: 說到底對程式碼品質有要求的團隊都會找時間插下去重構， 04/16 10:20
334F：→ Masakiad: 先不管本篇難度太低的問題，該案例可以發現系統架構彈 04/16 10:20
335F：→ Masakiad: 性不足，這根本就是排入重構時程的好時機。你可以當下 04/16 10:20
336F：→ Masakiad: 不重構然後開發處理例外事件的模組，但技術部門應該排 04/16 10:20
337F：→ Masakiad: 時間治標（系統架構彈性不足）才對。 04/16 10:20
338F：→ Masakiad: 正常team: workaround => refactoring (維持原有功能但 04/16 10:23
339F：→ Masakiad: 讓架構有可擴充空間）=> 將workaround 的邏輯轉成模組 04/16 10:24
340F：→ Masakiad: 掛進去 04/16 10:24
341F：→ Masakiad: 本篇：workaround => 再發生 workaround2 => 得到還好沒 04/16 10:25
342F：→ Masakiad: 花時間重構的結論 04/16 10:25
343F：噓 SmallpTsai: 反正A大有一百萬的理由告訴你重構無法面對客戶的下一 04/16 10:39
344F：→ SmallpTsai: 個無理要求 04/16 10:39
345F：推 abc0922001: 因為5%的例外情況，放棄95%XDD 04/16 10:53
346F：推 BignoZe: 因為商業需求需要dirty code的情況很常見 但是當情況一再 04/16 12:50
347F：→ BignoZe: 重複就可以重構成好管理的架構了 原po就是沒能力改又愛抱 04/16 12:50
348F：→ BignoZe: 怨 04/16 12:51
349F：→ lovdkkkk: 論他其實在收集工作時用的嘴砲材料的可能性 04/16 14:15
350F：→ lovdkkkk: 一堆人免費提供各種看法/意見, 在公司遇到類似議題就可 04/16 14:16
351F：→ lovdkkkk: 以輕鬆的藉花獻佛, 潮爽der科科 04/16 14:17
352F：→ Argos: 大概英文不好？這種討論隨便google就一堆耶 XD 04/16 14:30
353F：→ Argos: 本篇吵過的所有論點 歐美論檀那邊早己吵過幾百遍了吧 XD 04/16 14:32
356F：→ Argos: 要收集這些 國外那些文章比較精彩啦 04/16 14:39
357F：→ lovdkkkk: 真der, 只是要自己看, 不像這樣眾人合力幫他重點摘要 XD 04/16 14:46
358F：→ accessdenied: 而且都在地中文化了，讀起來很輕鬆啊。我英文不好也 04/16 15:02
359F：→ accessdenied: 是大家都知道的 04/16 15:02
360F：推 lovdkkkk: 誠實推 XDrz 04/16 15:10
361F：→ vi000246: 能每篇都讓推文戰翻也算是奇耙了 04/16 16:49
362F：→ accessdenied: 這等成就，Argos網友貢獻了一半以上吧 04/16 17:30
363F：推 expup: 我的經驗是公司產品上一定會有Clean dirty code 04/16 19:14
364F：→ expup: 這也沒有什麼吧 只是有些債要不要還 有的時候根本不用還 04/16 19:16
365F：→ konkonchou: clean code前也要人員具更佳解，很多能力就只到那 04/17 00:02
366F：推 gundamdx: 做的事跟大學剛畢業的菜鳥工程師一樣還可以領三百萬？是 04/17 00:55
367F：→ gundamdx: 靠爸嗎 笑死 04/17 00:55
368F：推 SuperCry: 拋磚引玉，就像模擬聯合國、模擬法庭一樣，樓主用心良苦 04/17 01:19
369F：→ SuperCry: ，是真正的架構大師 04/17 01:19
370F：推 impotent: 閱 04/17 08:15
371F：→ Argos: 好說好說 偶爾聊聊這個也不錯 當然最後還是在個人選擇 04/17 09:57
372F：→ Argos: 看你還要待在焦油坑裡幾年 慢慢沉沒 還是有心想要找尋解決 04/17 10:01
373F：→ Argos: 方案 減輕一些痛苦和負擔 04/17 10:02
374F：推 penril0326: 公司營運就是這樣 clean code講的只是理想狀態 不可能 04/21 18:49
375F：→ penril0326: 完全達到 04/21 18:49
376F：→ m13m13m: cid可以改成一個檔案了... 每次load進來if cid in xxx: 05/09 19:18
377F：→ m13m13m: 這樣比較不醜一點xd... 05/09 19:18