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

看板Soft_Job (軟體人)作者brucetu (sec)時間4小時前 (2025/09/15 12:12)推噓2(2推 0噓 0→)

留言2則, 2人參與討論串5/7 (看更多)

看到這篇原原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