PTT推薦

[討論] 重構跟kpi的考量

看板Soft_Job標題[討論] 重構跟kpi的考量作者
VScode
(VSisBestIDEinTheWorld)
時間推噓35 推:39 噓:4 →:82

假設以下情境

有個功能A、B都會用到相同邏輯,且有兩份重覆的code
(沒有unit test保護,而且年久失修 要加入unit test會需要更多時程)

現在要加入C,也會用到相同邏輯

身為合格的工程師 應該會把ABC重覆的部份提取出來

而不是讓這邏輯重覆三次

但以公司營運的角度來看 這次專案就只會測試C的部份

不應該動到A、B

這時就要冒著A、B壞掉風險重構,或是因為來不及加入unit test

就乾脆讓相同邏輯存在三個地方

身為專業工程師,我很想選擇重構

但過去的經驗告訴我

絕對要以kpi為最優先考量

於是程式充滿了註解、重覆片段

雖然靠著筆記、git log,能還原當時寫code的思路

但這些髒code就會永遠留存在程式裡

想問大家遇到這情況會怎麼做?

--

※ PTT留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 115.43.126.106 (臺灣)
PTT 網址
※ 編輯: VScode (115.43.126.106 臺灣), 02/24/2022 01:14:25

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來看就是自廢武功

我也是這樣想 不想為了kpi昧著良心

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

這倒是還好 這個地方的code好幾年沒動了

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壞掉你能負責嗎...

kpi會很慘...

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做好驗好就好

嗯嗯 我覺得我應該會這樣做 等未來要改A B時,再重構A B

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會問這種問題 就是你的不專業了

要如何兼顧專業跟績效呢?

※ 編輯: VScode (115.43.126.106 臺灣), 02/24/2022 08:45:52

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半天

只是這地方可能好幾年才動一次 會有一股衝動想一口氣弄好

※ 編輯: VScode (115.43.126.106 臺灣), 02/24/2022 08:48:18

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又另一個故事

改AB 可能是幾年後別人改 這時要把註解寫很清楚 哪裡重覆 哪裡要移去哪裡 我覺得也滿麻煩的

※ 編輯: VScode (203.67.131.41 臺灣), 02/24/2022 10:18:51

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

這個方法不錯 都忘了有obsolete attribute可以用

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等之後有改的時候再接

※ 編輯: VScode (115.43.126.106 臺灣), 02/25/2022 01:16:28

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重構