還是很多人對 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 看得甚高的工程師們，在這樣現實的商業生活中，你會
怎麼做的讓我刮目相看呢？

滿實在的XD…

這你們系統架構的問題, user 跟權限在資料庫本來就應該分開,每個功能都有一個開關。或是用role based 來管理權限。

很無奈

BignoZe 顯然你沒有搞懂，系統架構只能處理能夠預知的問題，無法處理沒有預料到的問題

這問題有的時候我覺得產品經理還有老闆的觀念與堅持很重要

樓上正解，很多code會變成這樣，上面的人通常是主因

老實說，沒有人能在市場面前堅持什麼的。能夠堅持的，通常已經大到可以寡占的地步，不缺你一個客人

我同意expup,如果RD或RD head沒辦法捍衛自己的原則跟自己維護的程式,就是只能跟著沉淪或者一走了之, 二選一..

樓上，那我就要問，公司要擴大市佔，保護品牌，RD lead在那邊堅持或反抗，那RD究竟是助力還是阻力

上頭開出跟原設計牴觸的需求，就只能貼藥膏了

直接在權限系統新增一個該客戶專用的角色就好了我們公司也是 常常有這種小規則特例......

如果那個技術債留在哪裡,你會常看到,常改到,會造成維護成本

反正時間到我就跑了 懶得重構 主管要幹啥隨便他吧

那你就值得花時間幫特例重構,如果是很久都碰不到,那就隨個人重構的開發成本就跟RD head報工時,如果主事者知道不好但不想

討論還是就不要深究實作，因為我並沒有提供詳細的系統內部設計的資訊，單純只有這個scenario 是真人真事

改進,或是連壞氣味都不懂,你做的又痛苦,那還不快逃?

這個例子實在是達不到寫不出clean code 的程度

外包商根本不能反抗

任何事都有成本 只是成本誰擔而已 這個案例就是RD擔 等哪天RD不擔跑了 就看什麼時候爆炸 不是不報 時候未到罷了

XD

商業上許多妥協是必要之惡理念上我們要追求clean譴責dirty現實中只能無奈

原本產品假設被broken 這是spec問題 哪是clean code要管的

用dirty去硬解商業需求 管不了clean不clean 是這意思吧

系統架構就沒有考慮到未來的彈性呀 功能開開關關的很正常設計的人經驗不夠 導致要寫爛code來處理 都怪別人就飽了呀

Spec 只是 paper, change implement 難道不是 code?那我還真不懂 clean code 是幹嘛的BignoZe 彈性都是事後講講的幹話而已，需求永遠都會超過你預期的彈性而且你也不知道真實系統是什麼樣子，就不要秀下限了，怪「不夠彈性」大概是最無能的manager口頭禪了沒有之一

超過了不就是要重構了嗎？ 還是說重構一定要大規模才可？

事實上 clean code與敏捷開發 就是為了解決你提的那個真實

這種業務主管每天講的幹話你就不要拿來降低自己身價了

不過就我自己在一線跟客戶嘴砲的經驗來看 原文案例的客服經理問題也很大就是 沒有發揮緩衝的功用

clean code與一些設計準則當然不是銀彈 我還沒見過有誰敢說這些東西是銀彈 但真的完全沒有價值 FLAG與網路上一狗票大神也不會這麼重視這些了 是吧？要戰這些喔 煩請自己google吧 歐美已經戰好幾年了XDDHH之前也戰過TDD啊 XD

現實上不管當初怎麼設計, 永遠就是會出現目前規劃無法處理的狀況要談設計準則, 先討論設計的是應用系統還是工具軟體吧

是阿 現實就是如此 但是發生第一個例子時就開始重構似乎也不夠現實

應用軟體永遠都要考慮到完全相反的使用, 這是現實環境使然工具軟體當然可以很瀟灑地說目前不支援

沒有錯 需求永遠在變 所以才需要重構 所以才需要測試

其實工程師真正的專業是在剛好的欠債，漂亮的還債。既設計的剛好，不過度設計，又能因應變化時不傷筋動骨。架構不會好高騖遠，殺雞用牛刀，懂domain跟限制，才能剛好，剛好才是最好，但這得有clean code當基本功。不然就是只欠債，拿credit，債讓別人還，自己爽的咖。

這麼簡單的需求都能弄成這樣 我也是滿佩服 你開一個table

我的意思是 需求一直在變不能拿來當寫爛code的理由就是了

不過現實上留債給別人的咖洨才是績效好的, 因為速度快

根據不同地方要開關的功能 select 出 user 來不就好了寫成這樣還要怪東怪西的 還怪別人秀下限 也是幽默XD

維護性跟clean code對長官來說根本無用

對長官無用 但對工程師有用的 你也不想寫出來的東西整天出bug 搞得長官不信任你的程式吧？XD事實已經證明 沒顧慮到維護性 程式寫出來出包機率高太多阿你做這些工 並不是為了公司長官 是為了你自己好吧 XD

nono~ 這些東西爆炸的時候, 當初開發的人已經不知道去哪了

還是你覺得義大利麵寫法 處處workaround 出錯率會比好好整

BignoZe你還在糾結你自己的實作和想像出來的系統，那就不奉陪了，自己玩沙吧

那你也應該修改level曾經而不是做cid== 好嗎

東西爆炸人已經不知去哪 那你就特別倒楣阿 XD這無解

先說好, 我也是基本教義派, 現實上是觀察到流債的咖洨績效好

你只能 1.好好重構 日後開心維護 2.先改再說別管了 然後之

歡迎你舉出更難的例子喔 這個太好解了 不忍噓XD

oneheat 修改level等於所有客戶都受影響，而不是只有來電的那位......

技術差靠邀技術不對，這種現象很常見啊當然是修改該用戶的層級，怎麼會牽扯到其他人？

解法太多了 但前題是 有好好寫了測試 也懂得怎麼重構 XD

那就是所有vip的功能他都能用，而不是只有某一隻...你沒看清楚情境

當然有啊，大哥，就說一種方式是修改該用戶的層級了

留債的咖績效好？那你該考慮的是換公司吧？XD

樓上, 原po的情境就是客戶層級只有一個變數代表阿樓樓上

很多案例是 掉坑》先改在說然後不管》一陣子後自然有新的衰鬼接你的坑

貴公司的問題看起來更像是設計階段考慮的就太少，開發階段擴充性又不夠

一改就可以用全部的VIP功能了, 這就不對

要看他們level是怎麼定義的啊，最差新增一個level也比cid的方式好而正常的設計，不會只有一個level去應對到所有的功能權限

先改不管 有衰鬼接 你怎麼能肯定衰鬼不會是你自己 XDDDD

應該說,在可預期的地方做到Clean，才能夠有讓非預期狀況Dirty的空間，如果全部都是一團炒麵，那我想所謂的”明天用Dirty code上線”也會是天方夜談吧，Clean好處無庸置疑，但這個詞是相對而非絕對

應該先思考一下當發生例外的時候，你們的系統的要怎麼擴充，是否具備彈性容易調整外掛上去等等一個level就要map到所有功能，又不具備分層的概念，這樣的設計然後說要設計無用，到底是無用還是不會用呢？

oneheat 設計思考的夠不夠，這是事後打高炮。需求一開始就是一個客戶只會有一個等級。這就是91大剛剛說不要過度設計的理由。但是身為推動公司營利的角色，我不會拿當初開的需求去打客服主管臉，而是想辦法做到，就這個差別

對岸BAT之一就這麼做的，誰跟你打高砲簡單一個問題啦，exception 模組你有考慮到嗎？怎麼擴充？內嵌的代碼彈性如何？這是設計階段就要想到的，打什麼高砲

要有原則 但太有原則 你就升不上去

在第二次出現例外狀況就應該要重構設計了 對著客戶清單一條一條寫if 那如果有一萬個客戶不就完蛋惹 XD

程式語言都有提供exception的概念了，何況是系統設計呢？

業務說一個客戶只有一個等級,是你的系統要滿足的最低需求,你

@Argos 一定不是一條一條加的，最爛也該有個exception rule or field去判斷是否符合該狀態，才做對應的處理

貴司已經有兩次紀錄 因為客戶吵就給糖吃 這時CTO應該就知道

的系統可以支援的更多,就是你設計的彈性,不是不能作,是看你

未來這間公司 肯定是還會在開放例外的吧？

也就是未來這位客服經理講的話 請不要當一回事

就經驗不夠設計不足或者是看過的東西太少，先怪這東西無用再說，這種是很常見沒錯有例外真的不是重點，java也有例外處理啊，重點是當例外發生的時候，系統要怎樣去外掛上這樣的例外處理才是重點

淦 笑死 .... 不過自己遇到 以前遇到都笑不出來

如何建構可以任意開放例外權限的功能 現在就應該納入時程裡還是一個準則 遇到容易改變或預期會改變的 就盡量抽象化

初期設計就沒考慮exception的話，真的只能套句版上愛說的，快逃啊！這樣的公司期待學到什麼@@

但最常遇到的就是這邊根本不太可能改變卻改變了 那就是重構之時 把這塊修成可以適應變化的 系統設計本來就慢慢在演化這個策略也不是我講的 事實上各大企業開發多半都是這策略吧

通常是哪來的時間重構 有洞補洞

時程問題又是另一個戰場囉XD 這牽涉到的東西又更多了

重構派總是會擠出時間重構,反重構派總是會擠出藉口不重構

理想是豐腴的, 現實是骨感的

Refactoring也有bottom up的，沒人說一定要top down吧

理想通常當然只是理想 這也是為何沒有銀彈的原因但不能因為達不到100% 就連1%都不做 這不是拿來當藉口的吧

開一個黑名單/白名單模組處理這個鳥事,linux driver很多

說真的 這些方法準則 通通基於在一個前題之下

也就是有一批人是積極態度想解決一定程度的問題但有一批人 就認為這太理想化 連動手都不肯動手就放棄了但事實是 有做就是有改善 今天有改善10% 那也是改善

反正時程通通*2 就有時間重構了

這也不是理不理想的問題而是後續疊加代碼需要付出多少資源的問題吧重構的目的是為了讓將來的開發更有效率，如果重構的時間*2 將來開發也沒比較省，那的確沒有重構的意義

看來像趕時間的手法 客戶少我可能也會這麼做吧

其實變因太多了 原文案例 也沒寫這是新創 還是大公司 系統整體複雜度 人員組成 公司風氣 這全是變因啊 XD同樣問題 出在三人公司與出在Google裡 完全不一樣解法啊 XD所以說 不如說 打從一開始這完全就在打高空 XD

這家公司沒記錯的話一年付300萬給樓主，是三人公司也太...

文中的level是群組概念，怎麼有人不懂

說不定這他朋友新創企業嘛XD 前不著村後不著店的 就當聊聊

查了之前的紀錄,看來跟他解釋重構是對牛彈琴.. QQ

如果是role based 就可以新增一個"奧客"權限了

是我的話這種判斷就算要下 也是要擠到同一個class裡面處理想不到這種做法的人我不認為他程式設計專業到哪裡去你這篇文章實在是有為這種無能找藉口開脫的嫌疑

線上incident牽扯到商譽跟重要命脈的，緊急程度一定遠高於乾淨程度。先用最快有效的方法解決線上問題絕對合理。但工程師專業在於怎麼讓重複、類似的問題不會發生第二次，或是未來怎麼在設計上避免這問題再發生，怎麼用最小成本埋下擴充彈性，不重複自己犯的錯，也是成長的一環。解決問題跟滿足需求仍然是價值的最高權重，但技術如果捨棄，就會降低自己解決問題跟滿足需求的可能性跟可行性。一味只追求高大上的技術、名詞或潮流，當然也不容易在限制內用最剛好的解決方案，就像太空梭上用鉛筆的例子一樣。

Code在某些情況下是會變得髒 這很無奈 而且很多時候不是RD的

線上緊急問題用最快方式解，既然這問題影響程度這麼大，就該想辦法根本解，除非無解。

問題 但是RD要有本事讓這個髒污不要滲到根處 在合理的cost下

各位都很客氣我只好第一噓了，營運服務的系統會沒預先考慮這麼基本的例外客戶我也是笑笑。就算當下不做也早該架構上開出擴充的彈性。啊，我忘了樓主只會商業模式不會設計模式啦。沒關係你就用商業導向解吧，反正最後還是要花錢請高手回來重構。

技術債槓桿就是你認為系統能承受多少技術債?不是不能做而是你有沒有打算還?何時?事實是大多公司都不打算還啊不還債的工程師在市場上是什麼價位?還是不當工程師?

這種心態就是覺得技術債利息少直接忽視，久了就一次痛還大筆的到時候會不會賺還不知道，有的還還不出債咧！

反正到時候幹這些事的工程師離職給後面的人去死 做到功能自己都覺得加不上去擺爛 主管只好請新進人員重寫一個的例子也不是沒有啊 最後人家還不是不續約

推這篇，理想的lean code只能在open source project，商業世界一切以營運為主

同意緊急事態當然先修再說 但你終究還是得要回來面對的大家完全忽視髒code所帶來的風險 其實完全不小於客戶在吵寫髒東西沒事時都沒事 等到哪天某工程師失手 權限給錯了給

即使資料庫沒做角色資料表 程式面也是能補足的就像landlord大說的 用class把權限判斷包起來

到admin等級的 或是把VIP不小心降級成停權的 那就.....XD

再怎麼改也不會到處都是if判斷

一個公司如果行銷跟財務都想著錢砸越多效果越好 不計成

很懂就改了 一下就出事了啊 XDDDD

說錯 是y3k大

專案外包的技術債還不出來就約滿不續，錢有賺就好

而且，一般coding也會儘量寫65432 == cid 啦滿種程度蠻羨慕這樣的公司能發300萬給樓主的，應該是某寡占企業吧

緊急到立刻要有解的，當然先能解就先上!但接著要考慮的是你持續的穩定與可維護性的問題

其實後來想到 應該是該公司客戶權限並不是很重要才會這樣

技術債不是個非0則1的問題，除了你知道可以晚一點還債

你試試看銀行系統權限這樣玩玩看 XD

更要考慮你是否還具備這樣的能力還債!如果一直都是跳過會越來越沒能力~

完全不在乎髒code帶來的bug風險 大概內部也沒有code review測試也是簡單人工測幾次就先上線再說 心臟放大顆福利自然來

就是覺得新人進入難度不是成本 誰來都可以做不差你一個難維護你家的事 加班做就好了 死都死別人當然沒差

死別人當然是沒什麼關係啦XD 工程師出大包火掉就好 但客戶

工程師就消耗品

我上面有舉例了 需求致上最後客戶也是會不續約啊

這就是產業sa的價值

因公司營運叫工程師不要注重程式品質無助工程師職涯發展

const magic numbers 在開頭 而且一開始就要註解抽一個檔案 define if xxx version do 0000 things大概也只能這樣了

要用3個===

同意Masakiad大見解

同 superpai, 這例子...

多少pay出多少code 很明顯是不想多花錢

問下為何寫成65432 == cid會比較好@@?

內文的例子就看得出工程師的水準，這種基本的例外處理還需要花時間去寫一堆if？

65432擺前面不會有null而crash的問題

常數值放作罷只是 equal 避免寫成 assign 的防呆而已，這種 lvalue rvalue 左右值的拿來判斷工程師素質也太腦補了吧*常數值放左邊

可以看的出很多人會繼續堅持要clean code然後修復太慢最後商譽受損怪到當初出設計的人身上,你要帶著技術信仰的純工程師了解管理中為結果負責的概念太難

不好好作SA, 換來就是 quick and dirty code

從沒聽過礦工會變煤老闆的

很實在啊不是很同意M大，這篇寫的只是比較讓大家容易看得懂實務上，並不會只有遇到這幾種狀況，很難全部都想到

推Masakiad

滿貼切的xddd

認真回覆的不回 回那種東西...唉商譽受損? 沒看人家工程師還不是照辦 哪裡受損?

這個東西向不是很簡單嗎。。能討論成這樣

可能這就是他能舉出最嚴重的技術債了

老實說按照以前的工作經驗，跑好好的城程式不太可能讓人重構，除非撇除重新開發的成本，更主要的是如果導致新的bug出來怎麼辦通常長官不太會讓人動這個，除非你已經贏得主管的新任而且不影響其他案子的進度，更重要的是出現bug被自己扛責任

看公司吧 我改東西 manager 都挺支持的

我以前重構過幾次而且也運轉的不錯，但結果是累死自己

真奇怪 我怎麼沒看到有人堅持一定要先重構？XD支持要好好修改的 不都幾乎同意先用OK蹦止血 但事後有時間還是得好好整理傷口嗎？我覺得最後重點都在有沒有心而已啦什麼時程太緊人力不夠需求太多 都是藉口 就算你拖了一年 難保哪天出事了 還是總得要有人來收爛攤子

我自己也是重構派的，但我只是講事實，當突發狀況出現，用一些方法解決，通常主管不是讓你慢慢重構，而是給你下一個任務了

不然就是完全不管 那諸如此類的workaround就會一直發生然後到最後系統處處充滿了可怕的地雷 工程師整天出包 新需求加上去時間也更慢 更痛苦 然後有自知之名的工程師就會走

通常主管原因給你時間和信任慢慢重構是很幸福的

人 後面也徵不到厲害的人來因為該公司名聲就是爛code+不願意有時間讓人重構 XD這些問題也不是什麼新題目了 30年前出版的人月神話就講過了他講的是40年前的軟體工程 看來40年來完全沒啥進步 哈哈

人的問題無解阿...什麼開發流程碰到老闆一句明天要就GG

這個案例不是加個level就完事了嗎有空再重構成用table開關各功能阿

而且很多人都講沒有時間 沒有時間 嗯 時間真的緊到這樣 那估計也是沒時間code review 也是沒時間做太多測試 也是沒時間寫系統文件 大概技術部門也沒時間開會討論架構了 XDDDD然後這麼沒時間 這麼的忙 爛code簡單測測 資深也不用看過先上線吧 哇喔 好棒你說這風險會比客戶跑來鬧 威脅要上網黑公司來得小多少 我

非常中肯 特地登入上來推

也是笑笑 瞻前也要顧後啊 很多事是一體兩面的

尤其對新創更是如此 且戰且走是很重要的概念與其花時間寫無懈可擊的架構 不如先確定你產品有人用未來對於重構需求增加了 公司有錢有閒有人力再來解決在商言商 投入成本與公司獲利要取得最佳解

也是啦 如果今天該公司新創半年 使用者不到萬人 出事也不會

有時候是不得已的

clarkman 有沒有時間重構這不是問題，以本篇案例來說是沒打算重構，只打算workaround 方式走一輩子

說到底對程式碼品質有要求的團隊都會找時間插下去重構，先不管本篇難度太低的問題，該案例可以發現系統架構彈性不足，這根本就是排入重構時程的好時機。你可以當下不重構然後開發處理例外事件的模組，但技術部門應該排時間治標（系統架構彈性不足）才對。正常team: workaround => refactoring (維持原有功能但讓架構有可擴充空間）=> 將workaround 的邏輯轉成模組掛進去本篇：workaround => 再發生 workaround2 => 得到還好沒花時間重構的結論

反正A大有一百萬的理由告訴你重構無法面對客戶的下一個無理要求

因為5%的例外情況，放棄95%XDD

因為商業需求需要dirty code的情況很常見 但是當情況一再重複就可以重構成好管理的架構了 原po就是沒能力改又愛抱怨

論他其實在收集工作時用的嘴砲材料的可能性一堆人免費提供各種看法/意見, 在公司遇到類似議題就可以輕鬆的藉花獻佛, 潮爽der科科

大概英文不好？這種討論隨便google就一堆耶 XD本篇吵過的所有論點 歐美論檀那邊早己吵過幾百遍了吧 XDhttp://lmgtfy.com/?q=agile+is+deadhttp://lmgtfy.com/?q=clean+code+bullshit要收集這些 國外那些文章比較精彩啦

真der, 只是要自己看, 不像這樣眾人合力幫他重點摘要 XD

而且都在地中文化了，讀起來很輕鬆啊。我英文不好也是大家都知道的

誠實推 XDrz

能每篇都讓推文戰翻也算是奇耙了

這等成就，Argos網友貢獻了一半以上吧

我的經驗是公司產品上一定會有Clean dirty code這也沒有什麼吧 只是有些債要不要還 有的時候根本不用還

clean code前也要人員具更佳解，很多能力就只到那

做的事跟大學剛畢業的菜鳥工程師一樣還可以領三百萬？是靠爸嗎 笑死

拋磚引玉，就像模擬聯合國、模擬法庭一樣，樓主用心良苦，是真正的架構大師

閱

好說好說 偶爾聊聊這個也不錯 當然最後還是在個人選擇看你還要待在焦油坑裡幾年 慢慢沉沒 還是有心想要找尋解決方案 減輕一些痛苦和負擔

公司營運就是這樣 clean code講的只是理想狀態 不可能完全達到