[轉貼] 工程師應該放心大膽地創造技術負債

看板Soft_Job作者 (zrae)時間6年前 (2017/11/12 15:39), 6年前編輯推噓41(52推 11噓 54→)
留言117則, 76人參與, 6年前最新討論串1/8 (看更多)
覺得好貼切...分享給各位 轉貼於 https://goo.gl/dEpoJQ <--medium 好讀版 身為軟體工程師，你應該要盡量寫出無法維護的程式碼，而且絕對不寫測試。 你應該要知道：在績效管理下，你愈是認真負責，愈是做到符合專業倫理的要求，你反而 看起來績效愈差。而你大概會有 87% 的比例，會遇到這種績效管理。 舉個例子，假如你是警察，你決定要認真抓小偷，於是上個月在你的管區破獲了五十起竊 盜案，這個月因為你的努力，破獲的案件增長到一百件Xo代表什麼呢？這代表看起 來你的管區治安變差了，而你應該要為治安變差負責，你才是應該被檢討的對象。於是你 知道，警察好像應該要想辦法破案，但實際上，你的績效並不是來自破案，而是吃案。 如果你花了半年時間，抽絲剝繭理清了複雜的商業邏輯，建立了清爽明確的抽象層，並且 預先額外設想了其他的使用情境，最後開發了一套易於擴充的軟體架構，讓一個大學剛畢 業的新人，都可以在你的架構上不到一個星期就可以開發出新功能。這代表什麼呢？這代 表你的績效很差XA的管理者只會看到，你花了半年才做了一件事清，一個新人剛來 ，卻只需要花上一個星期就可以完成一件事，那還要你來做什麼呢？ 至於可以輕鬆開發出新功能的新人，他會怎麼看呢？可以這麼快開發出新功能，當然是因 為他自己的功勞啊！跟你有什麼關係呢？真的要了解你到底做了什麼，其實只有一個辦法 ，就是要閱讀你的程式碼，但，放心好了，不會有人會去讀的。 你要做的事情就是：管理者設定了什麼績效，你就想辦法達成什麼績效。如果管理者設定 的指標是你修好了多少 bug，那麼你就要想辦法一開始就在你的程式中製造許多 bug，免 得日後需要修 bug 的時候沒有 bug 可以修。如果管理者的目標是加速開發，你就應該要 不計後果加速開發新功能，明知道是加速邁向毀滅，你也要加速開發。 事實上，身為軟體工程師，你也根本不用考慮後續維護的問題。如果你在一家公司寫了一 大堆完全不考慮耦合關係、程式邏輯糾纏不清、命名混亂、使用大量 anti-pattern、到 處都是怪氣味、效能極差而且宛若天書的程式碼，而你開始為了繼續維護這樣的技術負債 感到痛苦的時候，其實只代表一件事情：你已經在這家公司呆得太久，而且還沒有升上去 當主管。 這個時候你就會知道加速開發的好。你完成了這麼多項功能，於是在你想要換工作得時候 ，你可以寫出洋洋灑灑的履歷表。反之，你會把你寫了幾條單元測試、達成多高的覆 蓋率這種數字放進履歷表裡頭嗎？把力氣放在測試這種無助於發展事業的事情上，完全就 是在浪費你的時間。 你也同時應該感謝是誰想出來軟體產業園區這種德政，原本製造業的產業園 區是讓上中下游供應鏈可以集中在一起，降低運輸成本，但軟體這一行又沒有供應鏈這種 事情，成立園區只是讓相互競爭的軟體公司其中在一起，唯一降低的就是人員流動的成本 ，換工作都不用搬家。多好啊你看。 如果你有機會高升，開始擔任主管，你就會知道，當初寫下的那些無法維護的 legacy code，其實更有助於你擔任主管的管理工作。 擔任主管最重要的工作，不是別的，就是一邊把持住自己的位子一邊想辦法繼續往上爬， 所以主管絕對不可以讓部屬表現得比自己更優秀，而你當初寫的程式碼，就是部屬事業道 路上最好的絆腳石。你除了可以一邊抱怨為什麼新功能開發愈來愈慢，一邊說嘴當年你只 花了多短的時間就寫了多少程式碼，果然只有你有資格擔任大家的主管。 當然，總有一天技術負債會大到你的部門什麼東西都做不出來，你的公司什麼服務都拿不 出來賣，但是這一點都不會影響你找新工作，你瞧，現在，你的履歷表上面，可寫著你當 過主管呢！拿著這份履歷表，你更有機會去別的地方，空降擔任更高階的主管。 技術負債從來就不是什麼問題。誰說你製造了技術負債之後，你就得要自己還債？ 在你的人生中，你不需要要為其他人而活，也不是為了程式碼這種死物而活，你真正應該 要負責的對象只有你自己；而你知道人是經濟而自私的動物，既然你的本性就是貪婪，你 就應該成就貪婪。你要捨棄專業才能成就事業，你應該要把握當下的績效，而不要為了可 能不存在的悲劇結果恓恓惶惶。凱因斯不就曾經說過：「In the long run, we are all dead」？ 身為軟體工程師，你應該放心大膽地創造技術負債。這麼做唯一的風險，就只有在你換工 作的時候，也會接手一大筆前人留下來的技術負債。不過，這種事情反正也早就已經發生 了。 ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.169.172.125 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1510472387.A.D33.html
推
11/12 15:45, 6年前 , 1F
不知道為什麼 覺得好中肯
11/12 15:45, 1F
推
11/12 15:53, 6年前 , 2F
怎麼覺得很現實，卻又無奈
11/12 15:53, 2F
推
11/12 15:55, 6年前 , 3F
現在還沒工作沒辦法認同… 但也許工作後想法就會改 有
11/12 15:55, 3F
→
11/12 15:55, 6年前 , 4F
前輩可以分享嗎
11/12 15:55, 4F
→
11/12 15:57, 6年前 , 5F
創造技術負債怎麼升主管沒講清楚。直接跳當主管誰不會講
11/12 15:57, 5F
推
11/12 15:59, 6年前 , 6F
這種趕專案沒時間規劃架構的公司 本身就是雷
11/12 15:59, 6F
噓
11/12 16:02, 6年前 , 7F
你的心態很垃圾！
11/12 16:02, 7F
推
11/12 16:03, 6年前 , 8F
但是其實這個時代還能靠這個爬上主管的機會不多了
11/12 16:03, 8F
推
11/12 16:08, 6年前 , 9F
然後就被主管約談了xdd
11/12 16:08, 9F
推
11/12 16:09, 6年前 , 10F
原文的帳號叫做"工程師幹話" XD
11/12 16:09, 10F
推
11/12 16:09, 6年前 , 11F
寫的不錯 這就是現實阿
11/12 16:09, 11F
噓
11/12 16:13, 6年前 , 12F
警察的舉例就很爛了 後面略過沒看
11/12 16:13, 12F
推
11/12 16:19, 6年前 , 13F
寫的很好阿，很現實
11/12 16:19, 13F
→
11/12 16:20, 6年前 , 14F
很多主管都會喊著 快速開發 那就快給他看阿 反正以後爆了
11/12 16:20, 14F
→
11/12 16:20, 6年前 , 15F
我不在了他也不在了 大家都開心~
11/12 16:20, 15F
→
11/12 16:22, 6年前 , 16F
想到之前看一篇文，工程師在程式裡加了迴圈，老闆要
11/12 16:22, 16F
→
11/12 16:22, 6年前 , 17F
求提升速度就拿掉一個迴圈並要求加薪
11/12 16:22, 17F
推
11/12 16:30, 6年前 , 18F
警察不是這樣算的 破案越多績效越好才對
11/12 16:30, 18F
推
11/12 16:32, 6年前 , 19F
中肯到不行，快速產生績效然後升職加薪跳槽，親眼
11/12 16:32, 19F
→
11/12 16:32, 6年前 , 20F
見證同事升職加薪，然後程式碼別人維護
11/12 16:32, 20F
推
11/12 16:40, 6年前 , 21F
就不要遇到技術主管跟技術下屬 你是我上屬 一定檢舉
11/12 16:40, 21F
推
11/12 16:43, 6年前 , 22F
不好的程式創造多個工作機會,此言不假
11/12 16:43, 22F
→
11/12 17:14, 6年前 , 23F
是滿多公司這樣 但也看過不少公司有在執行code review
11/12 17:14, 23F
→
11/12 17:15, 6年前 , 24F
反過來想 一直在寫爛code的人 換了工作技術還是沒提升
11/12 17:15, 24F
→
11/12 17:15, 6年前 , 25F
一樣待在那種不要求技術品質的環境 惡性循環
11/12 17:15, 25F
推
11/12 17:15, 6年前 , 26F
工作很久了，這篇是事實沒錯。
11/12 17:15, 26F
→
11/12 17:17, 6年前 , 27F
只有技術主管有話語權時才有用，但是大部分專案一
11/12 17:17, 27F
→
11/12 17:17, 6年前 , 28F
趕，技術職往往不敵業務
11/12 17:17, 28F
噓
11/12 17:24, 6年前 , 29F
如果心態這樣寫程式永遠不會變強
11/12 17:24, 29F
推
11/12 17:26, 6年前 , 30F
技術是不會強，因為這是公司政治問題
11/12 17:26, 30F
推
11/12 17:27, 6年前 , 31F
很中肯阿，老闆根本不在乎你的code，驗收能過就好
11/12 17:27, 31F
噓
11/12 17:29, 6年前 , 32F
其實有小主管有兼開發就避免了
11/12 17:29, 32F
噓
11/12 17:29, 6年前 , 33F
以為亂寫又埋bug 要解的時候只會有你當初埋的那些?
11/12 17:29, 33F
推
11/12 17:30, 6年前 , 34F
中肯文章收錄XDD
11/12 17:30, 34F
→
11/12 17:32, 6年前 , 35F
不是不想寫好，而是大環境和公司政治問題
11/12 17:32, 35F
推
11/12 17:35, 6年前 , 36F
太中肯了!! 台灣環境是如此沒錯
11/12 17:35, 36F
→
11/12 17:41, 6年前 , 37F
用這些招最多就是在後段的公司裡跳來跳去。想要進到前段的公司
11/12 17:41, 37F
→
11/12 17:42, 6年前 , 38F
(薪水也前段)，好好精進自己、展現實力，比較實際
11/12 17:42, 38F
推
11/12 17:51, 6年前 , 39F
夠酸 我連續兩個工作都在收爛攤 覺得酸的好
11/12 17:51, 39F
還有 38 則推文
還有 1 段內文
→
11/13 03:42, 6年前 , 78F
通常做得到這種境界的人都是渾然天成的就成功了 XDDD
11/13 03:42, 78F
推
11/13 08:00, 6年前 , 79F
新人表示...面過的 50k/m 以上 entrance level 外商工作
11/13 08:00, 79F
→
11/13 08:00, 6年前 , 80F
主管都會 coding, 單位都會unit test 跟 code review...
11/13 08:00, 80F
→
11/13 08:00, 6年前 , 81F
.還有這種老人思維只能一輩子卡外包公司
11/13 08:00, 81F
→
11/13 08:04, 6年前 , 82F
面試主管直接看實作包含 unit test, 以及 code 可讀性，
11/13 08:04, 82F
→
11/13 08:04, 6年前 , 83F
O(n)反而是其次
11/13 08:04, 83F
噓
11/13 09:51, 6年前 , 84F
狗咬狗 一嘴毛
11/13 09:51, 84F
推
11/13 10:29, 6年前 , 85F
推 我也是不斷refactor然後考績被打很差的人 哈哈哈哈哈
11/13 10:29, 85F
推
11/13 11:46, 6年前 , 86F
這是作官的思維，真的要寫好軟體不要學這些奧步
11/13 11:46, 86F
→
11/13 11:46, 6年前 , 87F
不過... 必要時還是可以小用一下啦，有時候要看時勢
11/13 11:46, 87F
→
11/13 12:39, 6年前 , 88F
噓的到底是...看不懂反諷嗎
11/13 12:39, 88F
推
11/13 13:15, 6年前 , 89F
覺得相當中肯
11/13 13:15, 89F
推
11/13 13:17, 6年前 , 90F
中肯
11/13 13:17, 90F
推
11/13 16:36, 6年前 , 91F
中肯 只能找有code review的公司了
11/13 16:36, 91F
噓
11/13 17:23, 6年前 , 92F
這種廢文竟然可以賺稿費，台灣真的要沉了(我是說原文)
11/13 17:23, 92F
→
11/13 17:23, 6年前 , 93F
國之將亡百鬼夜行
11/13 17:23, 93F
噓
11/13 19:01, 6年前 , 94F
低能思想，code review 叫你翻掉重寫
11/13 19:01, 94F
→
11/13 19:02, 6年前 , 95F
沒 code review 就是會有這種妖魔鬼怪
11/13 19:02, 95F
推
11/13 21:49, 6年前 , 96F
中肯推，啥code review能吃嗎？老闆就只要快
11/13 21:49, 96F
推
11/13 22:29, 6年前 , 97F
老實說...中肯 XDDD
11/13 22:29, 97F
推
11/13 23:52, 6年前 , 98F
code review是啥XD 號稱了1年繼續期許XD
11/13 23:52, 98F
推
11/14 08:33, 6年前 , 99F
有點現實，但是很反對，因為這樣也對自己也是很麻煩
11/14 08:33, 99F
推
11/14 15:49, 6年前 , 100F
我開始相信你了！準備進行人工程式碼混淆作業
11/14 15:49, 100F
→
11/14 16:47, 6年前 , 101F
所以有些公司股價只剩幾元不是沒道理的
11/14 16:47, 101F
→
11/14 22:42, 6年前 , 102F
心態不對+1
11/14 22:42, 102F
噓
11/15 02:22, 6年前 , 103F
可憐 沒遇過國際等級駭客寫這啥文章
11/15 02:22, 103F
推
11/15 10:45, 6年前 , 104F
雖然一看就是錯的，但是在現實生活是對的
11/15 10:45, 104F
推
11/15 19:43, 6年前 , 105F
如果覺得是對的，該思考究竟自己待在什麼環境了吧
11/15 19:43, 105F
推
11/15 21:41, 6年前 , 106F
Unit test 是沒辦法阻止種做法的，code review 完要
11/15 21:41, 106F
→
11/15 21:41, 6年前 , 107F
改架構也很為難，就變這樣子了，一天到晚review跟
11/15 21:41, 107F
→
11/15 21:41, 6年前 , 108F
自己寫沒什麼兩樣...
11/15 21:41, 108F
推
11/17 17:09, 6年前 , 109F
台肯!
11/17 17:09, 109F
推
11/25 10:08, 6年前 , 110F
年輕的時候的我一定不認同
11/25 10:08, 110F
→
11/25 10:08, 6年前 , 111F
但是現在的我大概可以理解你為什麼這麼做
11/25 10:08, 111F
推
11/26 13:45, 6年前 , 112F
覺得有點中肯 我都想一堆後續維護 把開發時間弄長 結果另一
11/26 13:45, 112F
→
11/26 13:45, 6年前 , 113F
位寫一堆鬼命名超長function 快速做出來 在外人眼中我就是
11/26 13:45, 113F
→
11/26 13:45, 6年前 , 114F
效率差他就速度快
11/26 13:45, 114F
→
11/26 13:46, 6年前 , 115F
然後我就是接受他legacy code維護的人 他老兄去跑去新專案
11/26 13:46, 115F
→
11/26 13:47, 6年前 , 116F
寫新的害人code XDDD 想必後來也都是我來維護 嗚嗚
11/26 13:47, 116F
推
11/30 21:21, 6年前 , 117F
沒錯，尤其在共同開發的時候，同事想要把你搞慢就醬幹
11/30 21:21, 117F
‣ 更多 keke0421 的文章
文章代碼(AID): #1Q1_h3qp (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 8 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共8篇)
‣ 更多 keke0421 的文章
文章代碼(AID): #1Q1_h3qp (Soft_Job)