PTT職涯區 / Soft_Job (軟體人)

Re: [心得] 花了很多時間重構卻被打槍用舊code

看板Soft_Job (軟體人)作者 (sec)時間1月前 (2025/09/15 12:12), 編輯推噓32(32推 0噓 13→)
留言45則, 33人參與, 1周前最新討論串5/12 (看更多)
看到這篇原原PO在其他篇底下聲稱 「可讀性+100%」 忍不住來回一篇 軟體開發裡面有一件很重要的事情是知識轉移 又稱 knowledge transfer 印度仔會簡稱 KT 你也可以拿這個詞去搜尋 看看印度仔對這東西的看法 有一個很直白的解釋是：在你的腦袋上按複製，在我的腦袋按貼上。 簡單說 每當 A 完成了一個東西要併入主線 或者 B 要參與一個他本來不熟悉的模組 大家都需要 KT 一下 這件事情成本高到靠北 假如你手上有 3 張票 分給三個人做 用了一週做完 你以為接下來再給他們 3 張票 隔週還可以保持一樣的生產力嗎？ 錯 隔週他們需要互相 KT，大家都對系統的更動有相當程度的共識之後，才能繼續進行開發 所以隔週大概做不了什麼事情 否則你的系統很快就會東倒西歪 這也是為什麼大型的專案最好有嚴格的框架跟守則 我們希望盡量減少每個人重新學習的時間 當所有人遵循相同的框架在開發 就能更容易理解別人寫的程式在做什麼 這也是模組解藕的好處之一，它可以縮小需要參與KT的人數，你不會希望每個commit都耗 費20個人的學習成本 所以回到最前面那句 「可讀性+100%」 其實根本只有對重寫的那個人而言可讀性 ++ 你讀了原本的程式，你寫了新的程式，新的程式你熟到不行，當然可讀性很高 對我來說這就是一份全新的程式碼 整包程式要拿來重新分析測試，才會知道裡面到底在幹麻 我要猜測你每個類別甚至每個函數的意圖 可讀性可能是 「-80%」 為什麼有些程式一開始看很屎 多看幾次之後你覺得還滿順的 因為我們的腦子就是這樣運作的啊 你瘋狂加班重寫了一整套系統 你當然覺得每個函數都一看就知道在做啥 -- 要重構同時增加可讀性 唯一的方法是一次改動一部分，並且確保每個人都有跟上你的改動 否則只是把知識的鴻溝從小水溝 變成大峽谷 你這樣的改動方式 就好像我叫 AI 加個小功能 然後他給我一包 zip 說我重寫了整套專案 測試過沒問題了 你可以放心取代原本的專案 只有一種情況你這個做法會被接受：你同事跟老闆完全不管程式 把你當 vibe coding 的 工具 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.137.128.194 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1757909562.A.E51.html
推
09/15 12:43, 1月前 , 1F
我推這個觀點
09/15 12:43, 1F
推
09/15 12:53, 1月前 , 2F
推
09/15 12:53, 2F
推
09/15 12:55, 1月前 , 3F
就算是自己今天可讀性100% 難保下周同一個時間變50%
09/15 12:55, 3F
→
09/15 13:31, 1月前 , 4F
熬夜到天亮 加上 AI 幫忙寫 隔天連自己的扣都只剩 50% XD
09/15 13:31, 4F
→
09/15 13:37, 1月前 , 5F
推推
09/15 13:37, 5F
推
09/15 13:38, 1月前 , 6F
自己寫的code兩週回來看都要看老半天
09/15 13:38, 6F
推
09/15 13:48, 1月前 , 7F
推
09/15 13:48, 7F
推
09/15 14:10, 1月前 , 8F
昨天也想吐槽他推文這句 但你講的比我有脈絡多了
09/15 14:10, 8F
推
09/15 14:26, 1月前 , 9F
推
09/15 14:26, 9F
推
09/15 16:07, 1月前 , 10F
推這篇講的好
09/15 16:07, 10F
推
09/15 16:23, 1月前 , 11F
推
09/15 16:23, 11F
推
09/15 17:00, 1月前 , 12F
推
09/15 17:00, 12F
推
09/15 17:49, 1月前 , 13F
自己的code過一個月回來 就會想問問當初自己在寫啥
09/15 17:49, 13F
推
09/15 17:51, 1月前 , 14F
最可怕的是都不討論 然後最後丟出一坨大便
09/15 17:51, 14F
推
09/15 18:52, 1月前 , 15F
推
09/15 18:52, 15F
推
09/15 19:31, 1月前 , 16F
推
09/15 19:31, 16F
推
09/15 20:47, 1月前 , 17F
推，我連我自己一年前寫的程式都看不懂了說
09/15 20:47, 17F
推
09/15 21:06, 1月前 , 18F
大推
09/15 21:06, 18F
推
09/15 22:28, 1月前 , 19F
半年前寫的code我都會看git blame看是不是真的我改的
09/15 22:28, 19F
推
09/15 22:31, 1月前 , 20F
這2年已經覺得甚麼SOLID 重構 抽象 真的有意義嗎
09/15 22:31, 20F
→
09/15 22:31, 1月前 , 21F
不管誰看誰的code都覺得難懂難改
09/15 22:31, 21F
→
09/15 23:10, 1月前 , 22F
真的常常 git blame 到自己 XD
09/15 23:10, 22F
→
09/15 23:16, 1月前 , 23F
軟體工程的各種pattern都是看情況用啦 有些原則比如說DRY
09/15 23:16, 23F
→
09/15 23:16, 1月前 , 24F
，有時候當你能預估到不久後的將來，你正在做的這功能會
09/15 23:16, 24F
→
09/15 23:16, 1月前 , 25F
客製化成某個很難跟別人相處的東西，那就直接複製過來改
09/15 23:16, 25F
→
09/15 23:16, 1月前 , 26F
一改先用啊，有時候重複程式碼看似髒，其實比較好。還有
09/15 23:16, 26F
→
09/15 23:17, 1月前 , 27F
很多時候抱怨扣太屎的人，只是因為他扣看的還不夠熟，等
09/15 23:17, 27F
→
09/15 23:17, 1月前 , 28F
他上手兩個月以上再來討論要不要改
09/15 23:17, 28F
推
09/15 23:50, 1月前 , 29F
推
09/15 23:50, 29F
推
09/16 01:08, 1月前 , 30F
推樓樓上
09/16 01:08, 30F
推
09/16 09:38, 1月前 , 31F
推
09/16 09:38, 31F
推
09/16 09:40, 1月前 , 32F
推
09/16 09:40, 32F
推
09/16 11:38, 1月前 , 33F
推這篇
09/16 11:38, 33F
推
09/16 21:40, 1月前 , 34F
XDD
09/16 21:40, 34F
推
09/18 00:35, 1月前 , 35F
推
09/18 00:35, 35F
推
09/18 18:40, 1月前 , 36F
謝分享
09/18 18:40, 36F
→
09/19 13:28, 1月前 , 37F
推 這觀點才合理
09/19 13:28, 37F
推
09/20 23:56, 1月前 , 38F
推
09/20 23:56, 38F
推
09/21 14:20, 1月前 , 39F
推
09/21 14:20, 39F
推
09/23 08:19, 1月前 , 40F
不要特別拉出一個時段或任務說要做重構，合格的工程師應
09/23 08:19, 40F
→
09/23 08:19, 1月前 , 41F
該要讓重構隨時發生，小範圍小範圍的處理
09/23 08:19, 41F
推
09/23 16:59, 1月前 , 42F
推樓上
09/23 16:59, 42F
推
09/24 22:03, 1月前 , 43F
確實 之前問隔壁部門一個問題 那個人看了一眼code說 這
09/24 22:03, 43F
→
09/24 22:03, 1月前 , 44F
段那個誰重寫過了要問他。
09/24 22:03, 44F
推
10/20 20:56, 1周前 , 45F
推
10/20 20:56, 45F
‣ 更多 brucetu 的文章
文章代碼(AID): #1env8wvH (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 5 之 12 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共12篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 brucetu 的文章
文章代碼(AID): #1env8wvH (Soft_Job)