推 Vendy: 滿實在的XD… 04/15 20:08
推 BignoZe: 這你們系統架構的問題, user 跟權限在資料庫本來就應該分 04/15 20:09
→ BignoZe: 開,每個功能都有一個開關。或是用role based 來管理權限 04/15 20:09
→ BignoZe: 。 04/15 20:09
推 jack1218: 很無奈 04/15 20:09
→ accessdenied: BignoZe 顯然你沒有搞懂，系統架構只能處理能夠預 04/15 20:13
→ accessdenied: 知的問題，無法處理沒有預料到的問題 04/15 20:13
推 expup: 這問題有的時候我覺得產品經理還有老闆的觀念與堅持很重要 04/15 20:14
推 abccbaandy: 樓上正解，很多code會變成這樣，上面的人通常是主因 04/15 20:17
→ accessdenied: 老實說，沒有人能在市場面前堅持什麼的。能夠堅持 04/15 20:17
→ accessdenied: 的，通常已經大到可以寡占的地步，不缺你一個客人 04/15 20:17
推 xam: 我同意expup,如果RD或RD head沒辦法捍衛自己的原則跟自己維護 04/15 20:17
→ xam: 的程式,就是只能跟著沉淪或者一走了之, 二選一.. 04/15 20:18
→ accessdenied: 樓上，那我就要問，公司要擴大市佔，保護品牌，RD l 04/15 20:21
→ accessdenied: ead在那邊堅持或反抗，那RD究竟是助力還是阻力 04/15 20:21
推 peter9s3b: 上頭開出跟原設計牴觸的需求，就只能貼藥膏了 04/15 20:22
推 vi000246: 直接在權限系統新增一個該客戶專用的角色就好了 04/15 20:23
→ vi000246: 我們公司也是 常常有這種小規則特例...... 04/15 20:24
推 xam: 如果那個技術債留在哪裡,你會常看到,常改到,會造成維護成本 04/15 20:24
→ vi000246: 反正時間到我就跑了 懶得重構 主管要幹啥隨便他吧 04/15 20:25
→ xam: 那你就值得花時間幫特例重構,如果是很久都碰不到,那就隨個人 04/15 20:26
→ xam: 重構的開發成本就跟RD head報工時,如果主事者知道不好但不想 04/15 20:28
→ accessdenied: 討論還是就不要深究實作，因為我並沒有提供詳細的系 04/15 20:28
→ accessdenied: 統內部設計的資訊，單純只有這個scenario 是真人真 04/15 20:28
→ accessdenied: 事 04/15 20:28
→ xam: 改進,或是連壞氣味都不懂,你做的又痛苦,那還不快逃? 04/15 20:28
推 superpai: 這個例子實在是達不到寫不出clean code 的程度 04/15 20:46
→ pttworld: 外包商根本不能反抗 04/15 20:46
推 codehard: 任何事都有成本 只是成本誰擔而已 這個案例就是RD擔 等 04/15 20:49
→ codehard: 哪天RD不擔跑了 就看什麼時候爆炸 不是不報 時候未到罷 04/15 20:49
→ codehard: 了 04/15 20:49
推 XXXXLAY: XD 04/15 20:50
推 PUTOUCHANG: 商業上許多妥協是必要之惡 04/15 20:56
→ PUTOUCHANG: 理念上我們要追求clean譴責dirty現實中只能無奈 04/15 20:58
推 rodion: 原本產品假設被broken 這是spec問題 哪是clean code要管的 04/15 21:01
推 del680202: 用dirty去硬解商業需求 管不了clean不clean 是這意思吧 04/15 21:05
推 BignoZe: 系統架構就沒有考慮到未來的彈性呀 功能開開關關的很正常 04/15 21:07
→ BignoZe: 設計的人經驗不夠 導致要寫爛code來處理 都怪別人就飽了 04/15 21:07
→ BignoZe: 呀 04/15 21:07
→ accessdenied: Spec 只是 paper, change implement 難道不是 code? 04/15 21:09
→ accessdenied: 那我還真不懂 clean code 是幹嘛的 04/15 21:09
→ accessdenied: BignoZe 彈性都是事後講講的幹話而已，需求永遠都會 04/15 21:10
→ accessdenied: 超過你預期的彈性 04/15 21:10
→ accessdenied: 而且你也不知道真實系統是什麼樣子，就不要秀下限了 04/15 21:12
→ accessdenied: ，怪「不夠彈性」大概是最無能的manager口頭禪了沒 04/15 21:12
→ accessdenied: 有之一 04/15 21:12
推 art1: 超過了不就是要重構了嗎？ 還是說重構一定要大規模才可？ 04/15 21:12
→ Argos: 事實上 clean code與敏捷開發 就是為了解決你提的那個真實 04/15 21:12
→ accessdenied: 這種業務主管每天講的幹話你就不要拿來降低自己身 04/15 21:12
→ accessdenied: 價了 04/15 21:12
→ Argos: 案例 但你顯然完全不懂該技術的眉角在哪裡 解釋也是對牛彈 04/15 21:12
→ Argos: 琴吧？XD 不如自己去書店翻翻書如何？ 04/15 21:13
→ Argos: 一堆書裡比你這案例更誇張的都有 也有提出一些準則 04/15 21:13
→ Argos: 當然啦 如果你從頭到尾還是對這個沒概念 那就繼續打高空 04/15 21:14
推 del680202: 不過就我自己在一線跟客戶嘴砲的經驗來看 原文案例的 04/15 21:15
→ del680202: 客服經理問題也很大就是 沒有發揮緩衝的功用 04/15 21:15
→ Argos: clean code與一些設計準則當然不是銀彈 我還沒見過有誰敢說 04/15 21:16
→ Argos: 這些東西是銀彈 但真的完全沒有價值 FLAG與網路上一狗票大 04/15 21:16
→ Argos: 神也不會這麼重視這些了 是吧？ 04/15 21:16
→ Argos: 要戰這些喔 煩請自己google吧 歐美已經戰好幾年了XD 04/15 21:18
→ Argos: DHH之前也戰過TDD啊 XD 04/15 21:18
推 atpx: 現實上不管當初怎麼設計, 永遠就是會出現目前規劃無法處理的 04/15 21:18
→ atpx: 狀況 04/15 21:18
→ atpx: 要談設計準則, 先討論設計的是應用系統還是工具軟體吧 04/15 21:19
推 Sunal: 是阿 現實就是如此 但是發生第一個例子時就開始重構 04/15 21:19
→ Sunal: 似乎也不夠現實 04/15 21:19
→ atpx: 應用軟體永遠都要考慮到完全相反的使用, 這是現實環境使然 04/15 21:20
→ atpx: 工具軟體當然可以很瀟灑地說目前不支援 04/15 21:20
→ Argos: 沒有錯 需求永遠在變 所以才需要重構 所以才需要測試 04/15 21:20
→ landlord: 其實工程師真正的專業是在剛好的欠債，漂亮的還債。既 04/15 21:20
→ landlord: 設計的剛好，不過度設計，又能因應變化時不傷筋動骨。 04/15 21:20
→ landlord: 架構不會好高騖遠，殺雞用牛刀，懂domain跟限制，才能 04/15 21:20
→ landlord: 剛好，剛好才是最好，但這得有clean code當基本功。不 04/15 21:20
→ landlord: 然就是只欠債，拿credit，債讓別人還，自己爽的咖。 04/15 21:20
推 BignoZe: 這麼簡單的需求都能弄成這樣 我也是滿佩服 你開一個table 04/15 21:21
→ Argos: 我的意思是 需求一直在變不能拿來當寫爛code的理由就是了 04/15 21:21
→ atpx: 不過現實上留債給別人的咖洨才是績效好的, 因為速度快 04/15 21:22
→ BignoZe: 根據不同地方要開關的功能 select 出 user 來不就好了 04/15 21:22
→ BignoZe: 寫成這樣還要怪東怪西的 還怪別人秀下限 也是幽默XD 04/15 21:22
→ atpx: 維護性跟clean code對長官來說根本無用 04/15 21:23
→ Argos: 對長官無用 但對工程師有用的 你也不想寫出來的東西整天出 04/15 21:23
→ Argos: bug 搞得長官不信任你的程式吧？XD 04/15 21:24
→ Argos: 事實已經證明 沒顧慮到維護性 程式寫出來出包機率高太多阿 04/15 21:24
→ Argos: 你做這些工 並不是為了公司長官 是為了你自己好吧 XD 04/15 21:25
推 atpx: nono~ 這些東西爆炸的時候, 當初開發的人已經不知道去哪了 04/15 21:25
→ Argos: 還是你覺得義大利麵寫法 處處workaround 出錯率會比好好整 04/15 21:25
→ accessdenied: BignoZe你還在糾結你自己的實作和想像出來的系統， 04/15 21:25
→ accessdenied: 那就不奉陪了，自己玩沙吧 04/15 21:25
→ Argos: 裡過的code來得低？呵呵 那當我的話耳邊風囉 04/15 21:25
推 oneheat: 那你也應該修改level曾經而不是做cid== 好嗎 04/15 21:26
→ Argos: 東西爆炸人已經不知去哪 那你就特別倒楣阿 XD這無解 04/15 21:26
→ atpx: 先說好, 我也是基本教義派, 現實上是觀察到流債的咖洨績效好 04/15 21:26
→ Argos: 你只能 1.好好重構 日後開心維護 2.先改再說別管了 然後之 04/15 21:27
推 BignoZe: 歡迎你舉出更難的例子喔 這個太好解了 不忍噓XD 04/15 21:27
→ Argos: 後又出包 你還是要回去痛苦加班 3.離職 XD 04/15 21:27
→ accessdenied: oneheat 修改level等於所有客戶都受影響，而不是只 04/15 21:27
→ accessdenied: 有來電的那位...... 04/15 21:27
推 oneheat: 技術差靠邀技術不對，這種現象很常見啊 04/15 21:27
→ oneheat: 當然是修改該用戶的層級，怎麼會牽扯到其他人？ 04/15 21:28
→ Argos: 解法太多了 但前題是 有好好寫了測試 也懂得怎麼重構 XD 04/15 21:29
→ accessdenied: 那就是所有vip的功能他都能用，而不是只有某一隻... 04/15 21:29
→ accessdenied: 你沒看清楚情境 04/15 21:29
→ Argos: 顯然 很多人完全不懂 也不想懂 然後就拋問題 覺得無解 XD 04/15 21:29
→ Argos: 把爛code都歸咎於這個喔 嗯 很棒的藉口囉 04/15 21:29
→ oneheat: 當然有啊，大哥，就說一種方式是修改該用戶的層級了 04/15 21:29
→ Argos: 留債的咖績效好？那你該考慮的是換公司吧？XD 04/15 21:31
推 atpx: 樓上, 原po的情境就是客戶層級只有一個變數代表阿 04/15 21:31
→ atpx: 樓樓上 04/15 21:31
推 del680202: 很多案例是 掉坑》先改在說然後不管》一陣子後自然有新 04/15 21:31
→ del680202: 的衰鬼接你的坑 04/15 21:31
推 oneheat: 貴公司的問題看起來更像是設計階段考慮的就太少，開發階 04/15 21:32
→ oneheat: 段擴充性又不夠 04/15 21:32
→ atpx: 一改就可以用全部的VIP功能了, 這就不對 04/15 21:32
推 oneheat: 要看他們level是怎麼定義的啊，最差新增一個level也比cid 04/15 21:33
→ oneheat: 的方式好 04/15 21:33
→ oneheat: 而正常的設計，不會只有一個level去應對到所有的功能權 04/15 21:34
→ oneheat: 限 04/15 21:34
→ Argos: 先改不管 有衰鬼接 你怎麼能肯定衰鬼不會是你自己 XDDDD 04/15 21:36
噓 smallchocho: 應該說,在可預期的地方做到Clean， 04/15 21:36
→ smallchocho: 才能夠有讓非預期狀況Dirty的空間， 04/15 21:36
→ smallchocho: 如果全部都是一團炒麵，那我想所謂的 04/15 21:36
→ smallchocho: ”明天用Dirty code上線”也會是天方夜談吧， 04/15 21:36
→ smallchocho: Clean好處無庸置疑，但這個詞是相對而非絕對 04/15 21:36
→ Argos: 那剛好是你自己不就作死了 04/15 21:36
推 oneheat: 應該先思考一下當發生例外的時候，你們的系統的要怎麼擴 04/15 21:37
→ oneheat: 充，是否具備彈性容易調整外掛上去等等 04/15 21:37
→ oneheat: 一個level就要map到所有功能，又不具備分層的概念，這樣 04/15 21:38
→ oneheat: 的設計然後說要設計無用，到底是無用還是不會用呢？ 04/15 21:38
→ accessdenied: oneheat 設計思考的夠不夠，這是事後打高炮。需求一 04/15 21:40
→ accessdenied: 開始就是一個客戶只會有一個等級。這就是91大剛剛 04/15 21:40
→ accessdenied: 說不要過度設計的理由。但是身為推動公司營利的角 04/15 21:40
→ accessdenied: 色，我不會拿當初開的需求去打客服主管臉，而是想 04/15 21:40
→ accessdenied: 辦法做到，就這個差別 04/15 21:40
推 oneheat: 對岸BAT之一就這麼做的，誰跟你打高砲 04/15 21:41
推 oneheat: 簡單一個問題啦，exception 模組你有考慮到嗎？怎麼擴充 04/15 21:42
→ oneheat: ？內嵌的代碼彈性如何？這是設計階段就要想到的，打什麼 04/15 21:42
→ oneheat: 高砲 04/15 21:42
→ MOONY135: 要有原則 但太有原則 你就升不上去 04/15 21:43
→ Argos: 在第二次出現例外狀況就應該要重構設計了 對著客戶清單一條 04/15 21:43
→ Argos: 一條寫if 那如果有一萬個客戶不就完蛋惹 XD 04/15 21:44
→ oneheat: 程式語言都有提供exception的概念了，何況是系統設計呢？ 04/15 21:44
→ xam: 業務說一個客戶只有一個等級,是你的系統要滿足的最低需求,你 04/15 21:45
→ oneheat: @Argos 一定不是一條一條加的，最爛也該有個exception ru 04/15 21:45
→ oneheat: le or field去判斷是否符合該狀態，才做對應的處理 04/15 21:45
→ Argos: 貴司已經有兩次紀錄 因為客戶吵就給糖吃 這時CTO應該就知道 04/15 21:45
→ xam: 的系統可以支援的更多,就是你設計的彈性,不是不能作,是看你 04/15 21:46
→ Argos: 未來這間公司 肯定是還會在開放例外的吧？ 04/15 21:46
→ xam: 會不會作跟要不要作而已. 04/15 21:46
→ Argos: 也就是未來這位客服經理講的話 請不要當一回事 04/15 21:47
推 oneheat: 就經驗不夠設計不足或者是看過的東西太少，先怪這東西無 04/15 21:47
→ oneheat: 用再說，這種是很常見沒錯 04/15 21:47
→ oneheat: 有例外真的不是重點，java也有例外處理啊，重點是當例外 04/15 21:48
→ oneheat: 發生的時候，系統要怎樣去外掛上這樣的例外處理才是重點 04/15 21:48
推 Timba: 淦 笑死 .... 不過自己遇到 以前遇到都笑不出來 04/15 21:50
→ Argos: 如何建構可以任意開放例外權限的功能 現在就應該納入時程裡 04/15 21:52
→ Argos: 還是一個準則 遇到容易改變或預期會改變的 就盡量抽象化 04/15 21:53
推 oneheat: 初期設計就沒考慮exception的話，真的只能套句版上愛說 04/15 21:54
→ oneheat: 的，快逃啊！這樣的公司期待學到什麼@@ 04/15 21:54
→ Argos: 但最常遇到的就是這邊根本不太可能改變卻改變了 那就是重構 04/15 21:54
→ Argos: 之時 把這塊修成可以適應變化的 系統設計本來就慢慢在演化 04/15 21:55
→ Argos: 這個策略也不是我講的 事實上各大企業開發多半都是這策略吧 04/15 21:56
→ MOONY135: 通常是哪來的時間重構 有洞補洞 04/15 21:56
→ Argos: 時程問題又是另一個戰場囉XD 這牽涉到的東西又更多了 04/15 21:58
推 xam: 重構派總是會擠出時間重構,反重構派總是會擠出藉口不重構 04/15 21:58
→ Argos: 強的可以一週就重構好 弱的可能三個月 那怎麼解？XD 04/15 21:58
→ PUTOUCHANG: 理想是豐腴的, 現實是骨感的 04/15 21:58
推 oneheat: Refactoring也有bottom up的，沒人說一定要top down吧 04/15 21:59
→ Argos: 理想通常當然只是理想 這也是為何沒有銀彈的原因 04/15 21:59
→ Argos: 但不能因為達不到100% 就連1%都不做 這不是拿來當藉口的吧 04/15 21:59
推 askacis: 開一個黑名單/白名單模組處理這個鳥事,linux driver很多 04/15 22:00
→ Argos: 說真的 這些方法準則 通通基於在一個前題之下 04/15 22:00
→ askacis: 時候為了相容各家chip也大多都是這樣處理的 04/15 22:00
→ Argos: 也就是有一批人是積極態度想解決一定程度的問題 04/15 22:01
→ Argos: 但有一批人 就認為這太理想化 連動手都不肯動手就放棄了 04/15 22:01
→ Argos: 但事實是 有做就是有改善 今天有改善10% 那也是改善 04/15 22:02
→ MOONY135: 反正時程通通*2 就有時間重構了 04/15 22:02
推 oneheat: 這也不是理不理想的問題而是後續疊加代碼需要付出多少資 04/15 22:03
→ oneheat: 源的問題吧 04/15 22:03
→ oneheat: 重構的目的是為了讓將來的開發更有效率，如果重構的時間* 04/15 22:04
→ oneheat: 2 將來開發也沒比較省，那的確沒有重構的意義 04/15 22:04
→ testPtt: 看來像趕時間的手法 客戶少我可能也會這麼做吧 04/15 22:04
→ Argos: 其實變因太多了 原文案例 也沒寫這是新創 還是大公司 系統 04/15 22:05
→ Argos: 整體複雜度 人員組成 公司風氣 這全是變因啊 XD 04/15 22:05
→ Argos: 同樣問題 出在三人公司與出在Google裡 完全不一樣解法啊 XD 04/15 22:06
→ Argos: 所以說 不如說 打從一開始這完全就在打高空 XD 04/15 22:07
推 oneheat: 這家公司沒記錯的話一年付300萬給樓主，是三人公司也太.. 04/15 22:08
→ oneheat: . 04/15 22:08
→ pttworld: 文中的level是群組概念，怎麼有人不懂 04/15 22:10
→ Argos: 說不定這他朋友新創企業嘛XD 前不著村後不著店的 就當聊聊 04/15 22:10
→ xam: 查了之前的紀錄,看來跟他解釋重構是對牛彈琴.. QQ 04/15 22:14
→ yyc1217: 如果是role based 就可以新增一個"奧客"權限了 04/15 22:24
推 y3k: 是我的話這種判斷就算要下 也是要擠到同一個class裡面處理 04/15 22:30
→ y3k: 想不到這種做法的人我不認為他程式設計專業到哪裡去 04/15 22:30
→ y3k: 你這篇文章實在是有為這種無能找藉口開脫的嫌疑 04/15 22:32
→ landlord: 線上incident牽扯到商譽跟重要命脈的，緊急程度一定遠 04/15 22:38
→ landlord: 高於乾淨程度。先用最快有效的方法解決線上問題絕對合 04/15 22:38
→ landlord: 理。但工程師專業在於怎麼讓重複、類似的問題不會發生 04/15 22:38
→ landlord: 第二次，或是未來怎麼在設計上避免這問題再發生，怎麼 04/15 22:38
→ landlord: 用最小成本埋下擴充彈性，不重複自己犯的錯，也是成長 04/15 22:39
→ landlord: 的一環。解決問題跟滿足需求仍然是價值的最高權重，但 04/15 22:39
→ landlord: 技術如果捨棄，就會降低自己解決問題跟滿足需求的可能 04/15 22:39
→ landlord: 性跟可行性。一味只追求高大上的技術、名詞或潮流，當 04/15 22:39
→ landlord: 然也不容易在限制內用最剛好的解決方案，就像太空梭上 04/15 22:39
→ landlord: 用鉛筆的例子一樣。 04/15 22:39
→ y3k: Code在某些情況下是會變得髒 這很無奈 而且很多時候不是RD的 04/15 22:39
→ landlord: 線上緊急問題用最快方式解，既然這問題影響程度這麼大 04/15 22:40
→ landlord: ，就該想辦法根本解，除非無解。 04/15 22:40
→ y3k: 問題 但是RD要有本事讓這個髒污不要滲到根處 在合理的cost下 04/15 22:40
噓 Masakiad: 各位都很客氣我只好第一噓了，營運服務的系統會沒預先 04/15 22:41
→ Masakiad: 考慮這麼基本的例外客戶我也是笑笑。就算當下不做也早 04/15 22:41
→ Masakiad: 該架構上開出擴充的彈性。啊，我忘了樓主只會商業模式 04/15 22:41
→ Masakiad: 不會設計模式啦。沒關係你就用商業導向解吧，反正最後 04/15 22:41
→ Masakiad: 還是要花錢請高手回來重構。 04/15 22:41
→ ku399999: 技術債槓桿就是你認為系統能承受多少技術債?不是不能做 04/15 22:42
→ ku399999: 而是你有沒有打算還?何時?事實是大多公司都不打算還啊 04/15 22:42
→ ku399999: 不還債的工程師在市場上是什麼價位?還是不當工程師? 04/15 22:44
→ Masakiad: 這種心態就是覺得技術債利息少直接忽視，久了就一次痛 04/15 22:45
→ Masakiad: 還大筆的到時候會不會賺還不知道，有的還還不出債咧！ 04/15 22:45
→ ku399999: 反正到時候幹這些事的工程師離職給後面的人去死 做到功 04/15 22:49
→ ku399999: 能自己都覺得加不上去擺爛 主管只好請新進人員重寫一個 04/15 22:50
→ ku399999: 的例子也不是沒有啊 最後人家還不是不續約 04/15 22:50
推 takingblue: 推這篇，理想的lean code只能在open source project 04/15 22:53
→ takingblue: ，商業世界一切以營運為主 04/15 22:53
→ Argos: 同意緊急事態當然先修再說 但你終究還是得要回來面對的 04/15 22:54
→ Argos: 大家完全忽視髒code所帶來的風險 其實完全不小於客戶在吵 04/15 22:54
→ Argos: 寫髒東西沒事時都沒事 等到哪天某工程師失手 權限給錯了給 04/15 22:55
→ vi000246: 即使資料庫沒做角色資料表 程式面也是能補足的 04/15 22:55
→ vi000246: 就像landlord大說的 用class把權限判斷包起來 04/15 22:56
→ Argos: 到admin等級的 或是把VIP不小心降級成停權的 那就.....XD 04/15 22:56
→ vi000246: 再怎麼改也不會到處都是if判斷 04/15 22:56
→ Argos: 啊不要以為不會發生這種事 哪個不熟的新人進來 髒code看沒 04/15 22:56
→ ku399999: 一個公司如果行銷跟財務都想著錢砸越多效果越好 不計成 04/15 22:57
→ Argos: 很懂就改了 一下就出事了啊 XDDDD 04/15 22:57
→ vi000246: 說錯 是y3k大 04/15 22:57
→ pttworld: 專案外包的技術債還不出來就約滿不續，錢有賺就好 04/15 22:57
→ ku399999: 本的花錢行銷 沒人踩煞車這樣真的有比較好嗎 04/15 22:57
推 oneheat: 而且，一般coding也會儘量寫65432 == cid 啦 04/15 23:01
推 oneheat: 滿種程度蠻羨慕這樣的公司能發300萬給樓主的，應該是某 04/15 23:02
→ oneheat: 寡占企業吧 04/15 23:02
推 kimkao: 緊急到立刻要有解的，當然先能解就先上! 04/15 23:05
→ kimkao: 但接著要考慮的是你持續的穩定與可維護性的問題 04/15 23:06
→ Argos: 其實後來想到 應該是該公司客戶權限並不是很重要才會這樣 04/15 23:06
→ kimkao: 技術債不是個非0則1的問題，除了你知道可以晚一點還債 04/15 23:06
→ Argos: 你試試看銀行系統權限這樣玩玩看 XD 04/15 23:07
→ kimkao: 更要考慮你是否還具備這樣的能力還債!如果一直都是跳過 04/15 23:07
→ kimkao: 會越來越沒能力~ 04/15 23:07
→ Argos: 完全不在乎髒code帶來的bug風險 大概內部也沒有code review 04/15 23:08
→ Argos: 測試也是簡單人工測幾次就先上線再說 心臟放大顆福利自然來 04/15 23:08
→ ku399999: 就是覺得新人進入難度不是成本 誰來都可以做不差你一個 04/15 23:09
→ ku399999: 難維護你家的事 加班做就好了 死都死別人當然沒差 04/15 23:09
→ Argos: 死別人當然是沒什麼關係啦XD 工程師出大包火掉就好 但客戶 04/15 23:10
→ ku399999: 工程師就消耗品 04/15 23:10
→ Argos: 那邊是你公司自行承擔 這樣run公司也蠻強大的 富貴險中求XD 04/15 23:10
→ Argos: 反正到時如果有工程師開錯權限 客戶經理再道歉開更多權限吧 04/15 23:12
→ ku399999: 我上面有舉例了 需求致上最後客戶也是會不續約啊 04/15 23:14
推 Csongs: 這就是產業sa的價值 04/15 23:17
→ ku399999: 因公司營運叫工程師不要注重程式品質無助工程師職涯發展 04/15 23:17
推 justben: const magic numbers 在開頭 而且一開始就要註解 04/15 23:44
→ justben: 抽一個檔案 define if xxx version do 0000 things 04/15 23:45
→ justben: 大概也只能這樣了 04/15 23:45
推 deray: 要用3個=== 04/15 23:47
噓 dfgh012316: 同意Masakiad大見解 04/16 00:01
→ lovdkkkk: 同 superpai, 這例子... 04/16 00:03
推 god145145: 多少pay出多少code 很明顯是不想多花錢 04/16 00:25
推 asleisureto: 問下為何寫成65432 == cid會比較好@@? 04/16 01:14
→ sorryla: 內文的例子就看得出工程師的水準，這種基本的例外處理還 04/16 01:16
→ sorryla: 需要花時間去寫一堆if？ 04/16 01:16
推 ckp4131025: 65432擺前面不會有null而crash的問題 04/16 01:33
→ accessdenied: 常數值放作罷只是 equal 避免寫成 assign 的防呆而 04/16 01:47
→ accessdenied: 已，這種 lvalue rvalue 左右值的拿來判斷工程師素 04/16 01:47
→ accessdenied: 質也太腦補了吧 04/16 01:47
→ accessdenied: *常數值放左邊 04/16 01:47
推 twin2: 可以看的出很多人會繼續堅持要clean code然後修復太慢最後 04/16 01:51
→ twin2: 商譽受損怪到當初出設計的人身上,你要帶著技術信仰的純工程 04/16 01:51
→ twin2: 師了解管理中為結果負責的概念太難 04/16 01:51
→ konkonchou: 不好好作SA, 換來就是 quick and dirty code 04/16 02:42
推 bibo9901: 從沒聽過礦工會變煤老闆的 04/16 04:47
推 mathrew: 很實在啊 04/16 07:26
→ mathrew: 不是很同意M大，這篇寫的只是比較讓大家容易看得懂 04/16 07:27
→ mathrew: 實務上，並不會只有遇到這幾種狀況，很難全部都想到 04/16 07:28
推 cookie1115: 推Masakiad 04/16 07:36
推 zzshcool: 滿貼切的xddd 04/16 07:59
→ ku399999: 認真回覆的不回 回那種東西...唉 04/16 08:51
→ ku399999: 商譽受損? 沒看人家工程師還不是照辦 哪裡受損? 04/16 08:53
推 GoalBased: 這個東西向不是很簡單嗎。。能討論成這樣 04/16 08:54
→ ku399999: 可能這就是他能舉出最嚴重的技術債了 04/16 08:57
推 clarkman: 老實說按照以前的工作經驗，跑好好的城程式不太可能讓人 04/16 09:21
→ clarkman: 重構，除非撇除重新開發的成本，更主要的是如果導致新的 04/16 09:21
→ clarkman: bug出來怎麼辦 04/16 09:21
→ clarkman: 通常長官不太會讓人動這個，除非你已經贏得主管的新任而 04/16 09:23
→ clarkman: 且不影響其他案子的進度，更重要的是出現bug被自己扛責 04/16 09:23
→ clarkman: 任 04/16 09:23
推 steve1012: 看公司吧 我改東西 manager 都挺支持的 04/16 09:24
→ clarkman: 我以前重構過幾次而且也運轉的不錯，但結果是累死自己 04/16 09:24
推 Argos: 真奇怪 我怎麼沒看到有人堅持一定要先重構？XD 04/16 09:43
→ Argos: 支持要好好修改的 不都幾乎同意先用OK蹦止血 但事後有時間 04/16 09:44
→ Argos: 還是得好好整理傷口嗎？我覺得最後重點都在有沒有心而已啦 04/16 09:45
→ Argos: 什麼時程太緊人力不夠需求太多 都是藉口 就算你拖了一年 難 04/16 09:45
→ Argos: 保哪天出事了 還是總得要有人來收爛攤子 04/16 09:46
推 clarkman: 我自己也是重構派的，但我只是講事實，當突發狀況出現， 04/16 09:47
→ clarkman: 用一些方法解決，通常主管不是讓你慢慢重構，而是給你下 04/16 09:47
→ clarkman: 一個任務了 04/16 09:47
→ Argos: 不然就是完全不管 那諸如此類的workaround就會一直發生 04/16 09:47
→ Argos: 然後到最後系統處處充滿了可怕的地雷 工程師整天出包 新需 04/16 09:49
→ Argos: 求加上去時間也更慢 更痛苦 然後有自知之名的工程師就會走 04/16 09:50
推 clarkman: 通常主管原因給你時間和信任慢慢重構是很幸福的 04/16 09:50
→ Argos: 人 後面也徵不到厲害的人來因為該公司名聲就是爛code+不願 04/16 09:50
→ Argos: 意有時間讓人重構 XD 04/16 09:51
→ Argos: 這些問題也不是什麼新題目了 30年前出版的人月神話就講過了 04/16 09:54
→ Argos: 他講的是40年前的軟體工程 看來40年來完全沒啥進步 哈哈 04/16 09:54
推 abccbaandy: 人的問題無解阿...什麼開發流程碰到老闆一句明天要就 04/16 09:57
→ abccbaandy: GG 04/16 09:57
→ hakama99: 這個案例不是加個level就完事了嗎 04/16 09:59
→ hakama99: 有空再重構成用table開關各功能阿 04/16 10:00
→ Argos: 而且很多人都講沒有時間 沒有時間 嗯 時間真的緊到這樣 那 04/16 10:05
→ Argos: 估計也是沒時間code review 也是沒時間做太多測試 也是沒 04/16 10:05
→ Argos: 時間寫系統文件 大概技術部門也沒時間開會討論架構了 XDDDD 04/16 10:06
→ Argos: 然後這麼沒時間 這麼的忙 爛code簡單測測 資深也不用看過先 04/16 10:06
→ Argos: 上線吧 哇喔 好棒 04/16 10:07
→ Argos: 你說這風險會比客戶跑來鬧 威脅要上網黑公司來得小多少 我 04/16 10:08
推 dylan29341: 非常中肯 特地登入上來推 04/16 10:08
→ Argos: 也是笑笑 瞻前也要顧後啊 很多事是一體兩面的 04/16 10:08
→ dylan29341: 尤其對新創更是如此 且戰且走是很重要的概念 04/16 10:09
→ dylan29341: 與其花時間寫無懈可擊的架構 不如先確定你產品有人用 04/16 10:09
→ dylan29341: 未來對於重構需求增加了 公司有錢有閒有人力再來解決 04/16 10:09
→ dylan29341: 在商言商 投入成本與公司獲利要取得最佳解 04/16 10:10
→ Argos: 也是啦 如果今天該公司新創半年 使用者不到萬人 出事也不會 04/16 10:10
→ dylan29341: 有時候是不得已的 04/16 10:10
推 Masakiad: clarkman 有沒有時間重構這不是問題，以本篇案例來說是 04/16 10:10
→ Masakiad: 沒打算重構，只打算workaround 方式走一輩子 04/16 10:10
→ Argos: 有太大的損害 至少老闆不會因此被判刑 那的確隨便即可囉 04/16 10:10
→ Argos: 所以討論這個 還是要看時空背景各個條件阿 不然就打高空阿 04/16 10:11
噓 Masakiad: 說到底對程式碼品質有要求的團隊都會找時間插下去重構， 04/16 10:20
→ Masakiad: 先不管本篇難度太低的問題，該案例可以發現系統架構彈 04/16 10:20
→ Masakiad: 性不足，這根本就是排入重構時程的好時機。你可以當下 04/16 10:20
→ Masakiad: 不重構然後開發處理例外事件的模組，但技術部門應該排 04/16 10:20
→ Masakiad: 時間治標（系統架構彈性不足）才對。 04/16 10:20
→ Masakiad: 正常team: workaround => refactoring (維持原有功能但 04/16 10:23
→ Masakiad: 讓架構有可擴充空間）=> 將workaround 的邏輯轉成模組 04/16 10:24
→ Masakiad: 掛進去 04/16 10:24
→ Masakiad: 本篇：workaround => 再發生 workaround2 => 得到還好沒 04/16 10:25
→ Masakiad: 花時間重構的結論 04/16 10:25
噓 SmallpTsai: 反正A大有一百萬的理由告訴你重構無法面對客戶的下一 04/16 10:39
→ SmallpTsai: 個無理要求 04/16 10:39
推 abc0922001: 因為5%的例外情況，放棄95%XDD 04/16 10:53
推 BignoZe: 因為商業需求需要dirty code的情況很常見 但是當情況一再 04/16 12:50
→ BignoZe: 重複就可以重構成好管理的架構了 原po就是沒能力改又愛抱 04/16 12:50
→ BignoZe: 怨 04/16 12:51
→ lovdkkkk: 論他其實在收集工作時用的嘴砲材料的可能性 04/16 14:15
→ lovdkkkk: 一堆人免費提供各種看法/意見, 在公司遇到類似議題就可 04/16 14:16
→ lovdkkkk: 以輕鬆的藉花獻佛, 潮爽der科科 04/16 14:17
→ Argos: 大概英文不好？這種討論隨便google就一堆耶 XD 04/16 14:30
→ Argos: 本篇吵過的所有論點 歐美論檀那邊早己吵過幾百遍了吧 XD 04/16 14:32
→ Argos: 要收集這些 國外那些文章比較精彩啦 04/16 14:39
→ lovdkkkk: 真der, 只是要自己看, 不像這樣眾人合力幫他重點摘要 XD 04/16 14:46
→ accessdenied: 而且都在地中文化了，讀起來很輕鬆啊。我英文不好也 04/16 15:02
→ accessdenied: 是大家都知道的 04/16 15:02
推 lovdkkkk: 誠實推 XDrz 04/16 15:10
→ vi000246: 能每篇都讓推文戰翻也算是奇耙了 04/16 16:49
→ accessdenied: 這等成就，Argos網友貢獻了一半以上吧 04/16 17:30
推 expup: 我的經驗是公司產品上一定會有Clean dirty code 04/16 19:14
→ expup: 這也沒有什麼吧 只是有些債要不要還 有的時候根本不用還 04/16 19:16
→ konkonchou: clean code前也要人員具更佳解，很多能力就只到那 04/17 00:02
推 gundamdx: 做的事跟大學剛畢業的菜鳥工程師一樣還可以領三百萬？是 04/17 00:55
→ gundamdx: 靠爸嗎 笑死 04/17 00:55
推 SuperCry: 拋磚引玉，就像模擬聯合國、模擬法庭一樣，樓主用心良苦 04/17 01:19
→ SuperCry: ，是真正的架構大師 04/17 01:19
推 impotent: 閱 04/17 08:15
→ Argos: 好說好說 偶爾聊聊這個也不錯 當然最後還是在個人選擇 04/17 09:57
→ Argos: 看你還要待在焦油坑裡幾年 慢慢沉沒 還是有心想要找尋解決 04/17 10:01
→ Argos: 方案 減輕一些痛苦和負擔 04/17 10:02
推 penril0326: 公司營運就是這樣 clean code講的只是理想狀態 不可能 04/21 18:49
→ penril0326: 完全達到 04/21 18:49
→ m13m13m: cid可以改成一個檔案了... 每次load進來if cid in xxx: 05/09 19:18
→ m13m13m: 這樣比較不醜一點xd... 05/09 19:18