Re: [請益] 工作四年多開始迷惘

看板Soft_Job作者 (存取違規)時間6年前 (2018/04/15 20:02), 編輯推噓68(73推 5噓 299→)
留言377則, 60人參與, 6年前最新討論串6/12 (看更多)
還是很多人對 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://www.ptt.cc/bbs/Soft_Job/M.1523793727.A.CA1.html
推
04/15 20:08, 6年前 , 1F
滿實在的XD…
04/15 20:08, 1F
推
04/15 20:09, 6年前 , 2F
這你們系統架構的問題, user 跟權限在資料庫本來就應該分
04/15 20:09, 2F
→
04/15 20:09, 6年前 , 3F
開,每個功能都有一個開關。或是用role based 來管理權限
04/15 20:09, 3F
→
04/15 20:09, 6年前 , 4F
。
04/15 20:09, 4F
推
04/15 20:09, 6年前 , 5F
很無奈
04/15 20:09, 5F
→
04/15 20:13, 6年前 , 6F
BignoZe 顯然你沒有搞懂，系統架構只能處理能夠預
04/15 20:13, 6F
→
04/15 20:13, 6年前 , 7F
知的問題，無法處理沒有預料到的問題
04/15 20:13, 7F
推
04/15 20:14, 6年前 , 8F
這問題有的時候我覺得產品經理還有老闆的觀念與堅持很重要
04/15 20:14, 8F
推
04/15 20:17, 6年前 , 9F
樓上正解，很多code會變成這樣，上面的人通常是主因
04/15 20:17, 9F
→
04/15 20:17, 6年前 , 10F
老實說，沒有人能在市場面前堅持什麼的。能夠堅持
04/15 20:17, 10F
→
04/15 20:17, 6年前 , 11F
的，通常已經大到可以寡占的地步，不缺你一個客人
04/15 20:17, 11F
推
04/15 20:17, 6年前 , 12F
我同意expup,如果RD或RD head沒辦法捍衛自己的原則跟自己維護
04/15 20:17, 12F
→
04/15 20:18, 6年前 , 13F
的程式,就是只能跟著沉淪或者一走了之, 二選一..
04/15 20:18, 13F
→
04/15 20:21, 6年前 , 14F
樓上，那我就要問，公司要擴大市佔，保護品牌，RD l
04/15 20:21, 14F
→
04/15 20:21, 6年前 , 15F
ead在那邊堅持或反抗，那RD究竟是助力還是阻力
04/15 20:21, 15F
推
04/15 20:22, 6年前 , 16F
上頭開出跟原設計牴觸的需求，就只能貼藥膏了
04/15 20:22, 16F
推
04/15 20:23, 6年前 , 17F
直接在權限系統新增一個該客戶專用的角色就好了
04/15 20:23, 17F
→
04/15 20:24, 6年前 , 18F
我們公司也是 常常有這種小規則特例......
04/15 20:24, 18F
推
04/15 20:24, 6年前 , 19F
如果那個技術債留在哪裡,你會常看到,常改到,會造成維護成本
04/15 20:24, 19F
→
04/15 20:25, 6年前 , 20F
反正時間到我就跑了 懶得重構 主管要幹啥隨便他吧
04/15 20:25, 20F
→
04/15 20:26, 6年前 , 21F
那你就值得花時間幫特例重構,如果是很久都碰不到,那就隨個人
04/15 20:26, 21F
→
04/15 20:28, 6年前 , 22F
重構的開發成本就跟RD head報工時,如果主事者知道不好但不想
04/15 20:28, 22F
→
04/15 20:28, 6年前 , 23F
討論還是就不要深究實作，因為我並沒有提供詳細的系
04/15 20:28, 23F
→
04/15 20:28, 6年前 , 24F
統內部設計的資訊，單純只有這個scenario 是真人真
04/15 20:28, 24F
→
04/15 20:28, 6年前 , 25F
事
04/15 20:28, 25F
→
04/15 20:28, 6年前 , 26F
改進,或是連壞氣味都不懂,你做的又痛苦,那還不快逃?
04/15 20:28, 26F
推
04/15 20:46, 6年前 , 27F
這個例子實在是達不到寫不出clean code 的程度
04/15 20:46, 27F
→
04/15 20:46, 6年前 , 28F
外包商根本不能反抗
04/15 20:46, 28F
推
04/15 20:49, 6年前 , 29F
任何事都有成本 只是成本誰擔而已 這個案例就是RD擔 等
04/15 20:49, 29F
→
04/15 20:49, 6年前 , 30F
哪天RD不擔跑了 就看什麼時候爆炸 不是不報 時候未到罷
04/15 20:49, 30F
→
04/15 20:49, 6年前 , 31F
了
04/15 20:49, 31F
推
04/15 20:50, 6年前 , 32F
XD
04/15 20:50, 32F
推
04/15 20:56, 6年前 , 33F
商業上許多妥協是必要之惡
04/15 20:56, 33F
→
04/15 20:58, 6年前 , 34F
理念上我們要追求clean譴責dirty現實中只能無奈
04/15 20:58, 34F
推
04/15 21:01, 6年前 , 35F
原本產品假設被broken 這是spec問題 哪是clean code要管的
04/15 21:01, 35F
推
04/15 21:05, 6年前 , 36F
用dirty去硬解商業需求 管不了clean不clean 是這意思吧
04/15 21:05, 36F
推
04/15 21:07, 6年前 , 37F
系統架構就沒有考慮到未來的彈性呀 功能開開關關的很正常
04/15 21:07, 37F
→
04/15 21:07, 6年前 , 38F
設計的人經驗不夠 導致要寫爛code來處理 都怪別人就飽了
04/15 21:07, 38F
→
04/15 21:07, 6年前 , 39F
呀
04/15 21:07, 39F
還有 298 則推文
→
04/16 10:23, 6年前 , 338F
正常team: workaround => refactoring (維持原有功能但
04/16 10:23, 338F
→
04/16 10:24, 6年前 , 339F
讓架構有可擴充空間）=> 將workaround 的邏輯轉成模組
04/16 10:24, 339F
→
04/16 10:24, 6年前 , 340F
掛進去
04/16 10:24, 340F
→
04/16 10:25, 6年前 , 341F
本篇：workaround => 再發生 workaround2 => 得到還好沒
04/16 10:25, 341F
→
04/16 10:25, 6年前 , 342F
花時間重構的結論
04/16 10:25, 342F
噓
04/16 10:39, 6年前 , 343F
反正A大有一百萬的理由告訴你重構無法面對客戶的下一
04/16 10:39, 343F
→
04/16 10:39, 6年前 , 344F
個無理要求
04/16 10:39, 344F
推
04/16 10:53, 6年前 , 345F
因為5%的例外情況，放棄95%XDD
04/16 10:53, 345F
推
04/16 12:50, 6年前 , 346F
因為商業需求需要dirty code的情況很常見 但是當情況一再
04/16 12:50, 346F
→
04/16 12:50, 6年前 , 347F
重複就可以重構成好管理的架構了 原po就是沒能力改又愛抱
04/16 12:50, 347F
→
04/16 12:51, 6年前 , 348F
怨
04/16 12:51, 348F
→
04/16 14:15, 6年前 , 349F
論他其實在收集工作時用的嘴砲材料的可能性
04/16 14:15, 349F
→
04/16 14:16, 6年前 , 350F
一堆人免費提供各種看法/意見, 在公司遇到類似議題就可
04/16 14:16, 350F
→
04/16 14:17, 6年前 , 351F
以輕鬆的藉花獻佛, 潮爽der科科
04/16 14:17, 351F
→
04/16 14:30, 6年前 , 352F
大概英文不好？這種討論隨便google就一堆耶 XD
04/16 14:30, 352F
→
04/16 14:32, 6年前 , 353F
本篇吵過的所有論點 歐美論檀那邊早己吵過幾百遍了吧 XD
04/16 14:32, 353F
→
04/16 14:33, 6年前 , 354F
04/16 14:33, 354F
→
04/16 14:35, 6年前 , 355F
04/16 14:35, 355F
→
04/16 14:39, 6年前 , 356F
要收集這些 國外那些文章比較精彩啦
04/16 14:39, 356F
→
04/16 14:46, 6年前 , 357F
真der, 只是要自己看, 不像這樣眾人合力幫他重點摘要 XD
04/16 14:46, 357F
→
04/16 15:02, 6年前 , 358F
而且都在地中文化了，讀起來很輕鬆啊。我英文不好也
04/16 15:02, 358F
→
04/16 15:02, 6年前 , 359F
是大家都知道的
04/16 15:02, 359F
推
04/16 15:10, 6年前 , 360F
誠實推 XDrz
04/16 15:10, 360F
→
04/16 16:49, 6年前 , 361F
能每篇都讓推文戰翻也算是奇耙了
04/16 16:49, 361F
→
04/16 17:30, 6年前 , 362F
這等成就，Argos網友貢獻了一半以上吧
04/16 17:30, 362F
推
04/16 19:14, 6年前 , 363F
我的經驗是公司產品上一定會有Clean dirty code
04/16 19:14, 363F
→
04/16 19:16, 6年前 , 364F
這也沒有什麼吧 只是有些債要不要還 有的時候根本不用還
04/16 19:16, 364F
→
04/17 00:02, 6年前 , 365F
clean code前也要人員具更佳解，很多能力就只到那
04/17 00:02, 365F
推
04/17 00:55, 6年前 , 366F
做的事跟大學剛畢業的菜鳥工程師一樣還可以領三百萬？是
04/17 00:55, 366F
→
04/17 00:55, 6年前 , 367F
靠爸嗎 笑死
04/17 00:55, 367F
推
04/17 01:19, 6年前 , 368F
拋磚引玉，就像模擬聯合國、模擬法庭一樣，樓主用心良苦
04/17 01:19, 368F
→
04/17 01:19, 6年前 , 369F
，是真正的架構大師
04/17 01:19, 369F
推
04/17 08:15, 6年前 , 370F
閱
04/17 08:15, 370F
→
04/17 09:57, 6年前 , 371F
好說好說 偶爾聊聊這個也不錯 當然最後還是在個人選擇
04/17 09:57, 371F
→
04/17 10:01, 6年前 , 372F
看你還要待在焦油坑裡幾年 慢慢沉沒 還是有心想要找尋解決
04/17 10:01, 372F
→
04/17 10:02, 6年前 , 373F
方案 減輕一些痛苦和負擔
04/17 10:02, 373F
推
04/21 18:49, 6年前 , 374F
公司營運就是這樣 clean code講的只是理想狀態 不可能
04/21 18:49, 374F
→
04/21 18:49, 6年前 , 375F
完全達到
04/21 18:49, 375F
→
05/09 19:18, 6年前 , 376F
cid可以改成一個檔案了... 每次load進來if cid in xxx:
05/09 19:18, 376F
→
05/09 19:18, 6年前 , 377F
這樣比較不醜一點xd...
05/09 19:18, 377F
‣ 更多 accessdenied 的文章
文章代碼(AID): #1Qqpy_oX (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 6 之 12 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共12篇)
‣ 更多 accessdenied 的文章
文章代碼(AID): #1Qqpy_oX (Soft_Job)