[討論] 重構跟kpi的考量

labbat02/24 01:17一堆重複程式碼以及註解，真的好髒

acgotaku02/24 01:21要我一定改,既然改就不要單純抽離,用clean code層面思考

devilkool02/24 01:23為了預防DEFG也用到一樣的東西，至少這次寫乾淨點

acgotaku02/24 01:24會這樣就代表中間業務邏輯更動了,無法遵循open-closed

f496328mm02/24 01:32考績只是一時的，繼續寫爛 code，對職涯發展不好，長期

f496328mm02/24 01:32來看就是自廢武功

yyc121702/24 01:44看你的份量 跟要不要對三個月後的自己好一點

wadechen02/24 01:46If it ain’t brake , don’t fix it

yyc121702/24 01:46至少C要寫的話一定會加上unit test

wadechen02/24 01:47先把C邏輯的泛用性處理好 之後讓A,B可以簡單引用又方便

wadechen02/24 01:47測試

wadechen02/24 01:51大家寫久了多少會有潔癖 但出來工作有時候要克制這種潔

wadechen02/24 01:51癖 尤其負責的專案越大 協同作戰的人又多時 重構的成本

wadechen02/24 01:51可能超乎想像

wadechen02/24 01:53我是覺得未來自己寫的扣 盡量保持乾淨易擴充易讀即可

neo527702/24 01:55有錢嗎？有就切沒有就算了老闆不會在意

angusyu02/24 01:58沒時間就到沒看到，又不是你的問題。有時間也要看公司文

angusyu02/24 01:58化跟趴數夠不夠，改了很容易產生副作用，還要不怕被幹譙

MoonCode02/24 02:01重複跟髒有什麼關係？

asadman152302/24 02:12先看看A、B壞掉你能負責嗎...

MoonCode02/24 02:20

CoNsTaR02/24 03:13先讓 C 再重複一次，等確認 C 沒問題了再來討論要怎麼重

CoNsTaR02/24 03:13構啊

ctrlbreak02/24 03:58政治問題 如果出事情你能不能負責

airtsubasa02/24 05:40寫的乾淨沒人感激你 前人挖洞 你也一起玩啊 反正專案

airtsubasa02/24 05:40也是會輪流的 顆顆

peter9802/24 05:49工程師搞KPI? 哪間公司啦 說來笑笑

CoNsTaR02/24 05:55樓上，Amazon 和 Facebook 平時都是你嘲笑的對象嗎？

james73202/24 06:07如果有足夠的時間與把握讓A B C都正常再說吧

james73202/24 06:08原本好好的改壞這個問題有時會非常嚴重

james73202/24 06:09我應該會新增C但預留了日後整合A/B的彈性

james73202/24 06:10或者一口氣改好但先驗證C是OK的再把AB切換過去

james73202/24 06:13如果時間不夠的話就不要碰AB了把C做好驗好就好

peter9802/24 06:16C大很懂?在哪高就?

RINPE02/24 06:43看薪水吧 薪水到位 一切好談

Solinarymoon02/24 07:13先把重複邏輯的地方獨立出來給C用並預備給A、B用，

Solinarymoon02/24 07:13後續有動到A、B的時候再修改？

del68020202/24 07:39會問這種問題 就是你的不專業了

ericthree02/24 08:42歷史包袱啊

foreverk02/24 08:43過去遇到這情況，我先把共用抽出來給C使用，後面有空再

foreverk02/24 08:43陸續套上A和B以及各自的unit test，這個邏輯可以套用所

foreverk02/24 08:43有你想重構的場景，視情況變化一下而已

ericthree02/24 08:43如果團隊不想解決 就大家一起放著爛

foreverk02/24 08:45多做這件事不一定有錢啦，但是熟練以後時間成本會越來

foreverk02/24 08:45越低，久了你就不會再把KPI和clean code放在天秤上衡量

foreverk02/24 08:45半天

foreverk02/24 08:53這個風險跟相信我能反殺差不多高，最好別吧

bheegrl02/24 09:20你可以考慮做C的時候先把和A、B重複的邏輯各別提出來

bheegrl02/24 09:21也就寫成C + A~C共用邏輯(假定是兩隻method)

bheegrl02/24 09:22你實際上只用寫了C，等以後有人要改A、B時再順便重構就好

bheegrl02/24 09:23這樣你概做出彈性來又不用一次性擔太多風險

bheegrl02/24 09:27*既

LeoSW02/24 09:30想想看怎麼把重構變成KPI啊

t6414102/24 09:39共用部分抽吃來，只有C套用，接著開單做AB重構

t6414102/24 09:39*抽出來

ssccg02/24 09:56你可以把C寫成以後DEFG可以用，但先別動AB

ssccg02/24 09:57以後真要改AB時也能引用C，是說很可能以後改AB又另一個故事

l8th02/24 10:49為什麼在這裡跟局外人糾結？go talk to your mgr and call a

l8th02/24 10:49 design session. present pros and cons to your team. thi

l8th02/24 10:49s is a team decision, not yours.

LIN81011602/24 11:23有版本跟分支控制不用怕改壞啊

CoNsTaR02/24 12:00@peter98 敝司某 fortune 20，沒有 kpi 不用為我擔心

knives02/24 14:52現在沒有壞的東西，不要沒事找事做，有空看ptt不好嗎

lazarus112102/24 15:39我之前是用類似藍綠部屬，用一個if控制新舊版本

lazarus112102/24 15:40然後用設定檔控制切換，如果發現有錯就立刻切回舊版

sniper282402/24 16:06理論上是跟你同事討論才對

sniper282402/24 16:07但你重構的夠好 注解就不用寫得像之前那樣了不是嗎？

asleisureto02/24 16:10等C穩定後再逐漸把AB功能加進去，這期間還是繼續用A

asleisureto02/24 16:10B，穩點來不要一口氣直接改AB

asleisureto02/24 16:12重構很多時候看你年資跟老闆主管挺不挺就是

somefatguy02/24 16:19A B不動但rename加上deprecated，並加註解說明請改用

somefatguy02/24 16:19重構過的A’ B’。然後抽出共用模組給A’ B’ C用。這

somefatguy02/24 16:20樣以後的人也知道新功能不要再呼叫舊的A B改用A’ B’

somefatguy02/24 16:20。

enthos02/24 16:54A、B=>AI程式分析軟體->AI程式產生器->C.再修改成D

fantasystar02/24 18:07把共用的部分複製一份出來，弄好unit tests. 開發 C

fantasystar02/24 18:07的時候做好integration tests. A/B 的重構 （改成用

fantasystar02/24 18:07之前抽出來的模組）就另外跟 product owner 談。

mathrew02/24 19:37C先抽，AB先暫時放著，等有空再改AB

MonyemLi02/24 20:27下個看到你程式的會說同樣的話，無論你又沒有重構

MonyemLi02/24 20:29後面有空，不會發生的

jej02/24 22:12我會了解這個系統還會多久EOS

jej02/24 22:12如果一年內 那就讓他臭吧

jej02/24 22:12如果還有很長的路要走 當然重構阿

jej02/24 22:12軟體維護的思緒往往和直覺顛倒

jej02/24 22:12今天有3個案例再重複 代表很有大的機會往後也要有

jej02/24 22:12你今天不重構 就是往後一直痛下去

TakiDog02/24 22:50今天你不重構，痛的是自己，那就重構吧

jack020402/24 23:46問主管阿，主管都不在意的話你在意幹嘛

jack020402/24 23:47你可以C額外寫一個引入用的，然後去AB的註解寫todo

avril995002/25 00:31先說服你主管你們的扣超髒，再繼續下去疊床架屋要垮了

avril995002/25 00:31，一直恐嚇他到他願意排時程跟QA讓你重構

viper970902/25 00:46這個很標準的就是先抽C,AB等之後有改的時候再接

j9d902/25 08:12選KPI，長期來說不好， 可以考慮換工作

anandydy52902/25 10:37以前我是把AB也換成新的，但有人跟我說沒壞的東西為

anandydy52902/25 10:37什麼要動，想想也是很有道理

t6414102/25 10:47不是沒就不能動，是要有計畫的修正

t6414102/25 10:56開發時先求有再求好，維護時沒壞就不動，分開看看

t6414102/25 10:56都合理，放在一起常常是悲劇

youtuuube00002/25 17:08改了之後有bug客戶一直叫然後公司營收受損這樣有比

youtuuube00002/25 17:08較好嗎

aidansky098902/26 00:30他已經爛這麼多年沒事，說明並沒有重

aidansky098902/26 00:30構的價值

aidansky098902/26 00:31你很閒沒事幹可以

xluds2480502/26 01:38先上 C，寫測試。上線確認沒問題後再把 A、B 改用 C

xluds2480502/26 01:38 的新函式

sunsamy02/26 03:58建議要入境隨俗

sunsamy02/26 03:59要不然你會被程度差的碼農當成你程度差,來亂的!

jej02/26 08:02樓上 那是一時的 本肥年輕時也曾經因此被瞧不起

jej02/26 08:02前輩們看到就幹譙一次 後來他們不爽公司 離職的離職

jej02/26 08:02升遷的升遷 最後剩下要維護的你 繼續因為爛code 被逼到離職

pttano02/26 11:33你應該是菜鳥，兩段code的邏輯相同就要重構？

f763guy02/26 14:54願賭服輸，賭輸別怨

yourinfo02/26 21:46寫好C，然後在AB註解就好，以後有人要動AB再改好了

yourinfo02/26 21:47有時候花時間做爛了不會有人感謝的，最大限度做好事就好

daddy2902/27 01:46再過幾年你會發現其實就是自己能力沒這麼猛 需要時間多

MonyemLi02/27 19:14寫詳細點，你們怎麼測試的，人工，那你今天改A,B有人測

MonyemLi02/27 19:14嗎？那就是跟挖個機率坑給主管跳。請上報，一路報上去

MonyemLi02/27 19:14。不允許，商業理念與你待著幹嗎？但時間壓力加保守主

MonyemLi02/27 19:14義下多半不允許。

iamshiao03/02 01:58看你打算在這間待多久

zenuo03/06 00:08真的照bheegrl說的是比較合理的做法 不影響kpi又先把架構

zenuo03/06 00:08做好但不影響實際功能

hellophoenix03/14 01:56你好像我以前的同事，剩沒幾天要release然後說要

hellophoenix03/14 01:56重構