[討論] 寫程式的追求?
寫程式不知不覺也一年半了
看著公司龐大的老舊程式
前人寫的實在雜亂
造成了維護上有一定難度
最近有心想要嘗試從簡單的地方開始試著重構
讓後人可以更好的閱讀程式
但想想,整理這個不知道有沒有意義
以目前能力重構效能會不會變得更好都是未知數
而且還要花大量時間進行測試
最終效果可能就是變得 模組化 、好維護、易讀
不知道各位前輩 對於程式要求是什麼
維護能動就好?
偏好clean code的原則?
不管環境、工具、寫法如何 只要能快速端出需求就行?
-----
Sent from JPTT on my Samsung SM-S9380.
--
先談錢薪水福利 再談工作
改那個會讓你錢變多嗎
沒新 feature 能開的時候,重構點小東西總是好的。
不過,我覺得市場面或是長官總是新 feature >>> 重構,
自己要好好把握這個權重
1. 專案能活多久 2. 公司能活多久 3. 你能活多久
refactor出問題,以上三者可能就提前陣亡了
要記得refactor永遠是為了自己,為別人沒意義
甚至厲害的人是爛code丟給別人修,自己拿feature KPI
Clean code/arch的意義在,自己後續延伸能順利不會卡到
換言之一切都還是為了自己的feature = KPI
或是像我這種小廢物,已經接了無數別人丟來的爛專案來救
把專案救活還改到很好,KPI全算別人的。只能說問心無愧
每月薪水準時到,獎金準時發,我可以一直沒事
refactor有什摸performance嗎
想想現實面喇
當你會想這種事情的時候代表在這間的技術到頂了
理想很美滿現實很骨感
看過各種客製化 太靠北 想想這種還是繼續亂下去
有分紅 股票嗎 沒有的話 死薪水操什麼心 公司賺一百兆
跟一百塊 都沒差 搞好沒人在乎 搞爛一定抓起來噴
不要浪費時間重構
對長官而言重構一點貢獻也沒有
曾經有一個長官對我說:重構只是把code改成自己看得
懂的
多年後回想,確實如此
最近也在苦惱一樣的問題,code爛到老闆覺得只是一點小改
動,但需要花很多時間改,硬改出來也只是讓code更爛...
樓上,我建議就繼續爛,難改就盡量不要改
只要撐到交接出去的那天就好
問題是老闆覺得簡單就會一直壓時間,最後就只能靠加班,
我怕撐不到交接...
專案只看結果啊,除非換你當主廚地位的去code review
一年半,先什麼都別想
重構不是重寫
一年半 你別添亂就好了
看情況,如果是就業寒冬的歐美,就得學會屎山雕花還有
屎上堆屎,別問為啥這麼幹,全都是為了job security,
你善於維護糞code,這算自己的credit,公司就裁員時比
較不會動你。
重構就是模組化 避免構出一個垃圾還不好救
重構不都是面試才會提到的事情嗎
想做點什麼值得讚許啦,但老實說你想做這件事情只是自我
實現,別人根本不在意,不如自己做side project ,說不定
還能創業
看你覺得坑會不會害到未來的你啊~
你可以基於feature需求來改,不要沒有gain就花時間
重構吃力不討好,只會換到爛考績,受不了的話離職比較
快
可以想想自己的薪水有沒有多到值得你重構屎山代碼
直接跟你講 沒意義
你怎麼說服人重構的結果比較好?
我經常在做重構 來給些建議首先重構只應該占用你總工時的
30%以下 再來是分辨什麼樣的重構是有商業價值的 對於沒有
商業價值但卻又必須做的部分 應該要讓同事也來分擔 如果這
部分無法說服老闆 那我建議放棄 同時要思考做重構能對你個
人有什麼價值? 譬如這些經驗能把你訓練成一個architect嗎?
總結要做重構要規劃從最有價值的部分入手而不是最簡單的
且要說服老闆跟同事這是一件有價值的事 並能把工作分擔出去
再舉例什麼是有商業價值的重構? 譬如memory usage會減少
TAT會變快 UI更加user friendly
現在有AI幫忙通靈 要維護糞code應該容易很多了
不要想不開去重構糞code
一堆系統10、15年才大修,到時要重構再說 除非找你進
去就是為了系統翻新
沒追求,只想早點退休
有沒有一種可能 你重構完 下一個人看也覺得架構很差
先取得同事信任吧
其實追求更好的程式碼也才有機會挑戰更好的公司 如果總是寫
垃圾 分不清楚什麼是對是錯 你會機會進好公司嗎?
不過確實做feature 跟做出效能提升比較有價值就是了
有錢領最重要!程式只要能交付出去,照spec操作沒問題就好
花時間在那重構、clean code,都只是自己看爽而已,主管根本
不希望你去動那些
使用者需求導向什麼的也不用,主管要你做一坨精美的大便,就
照著做出來給他就好
沒產值的事情都是做來放履歷的 但這效果還不如做有產值的
你自己都不知道效能好不好了,怎麼說服大家?
看你時間成本和個人意願到哪
同意某panda
沒在整個重構的啦 這件事要有產值一定是重開發一套新的
開發新的記得要取新的名字,別像我用一樣名字讓大家熟悉
結果就是年終時被列為沒任何專案在做,同名的二代不算數
重構看目的是什麼 如果重構完效能變高很多 而且效能提
升讓這個產品在市場更有競爭力 那我覺得可以
人家叫你換個燈泡不要幫人家把天花板也重做
gn01705529講的是正解 模組化只有模組的人自己看得懂
重構完後兩個禮拜回頭看 又覺得需要重構
不要改
一堆人只會over design
你以為的 clean 其實是別人眼中的 messy and dirty
能動就好,程式內容一律放給它爛
我都在修bug的時候偷把code變成自己的形狀 潮爽der
因情況而異。根本就沒有標準答案。菜鳥才認為有答案。
改這個老闆只會覺的你一整天都沒事幹
只要能穩定給薪水 就沒差 沒能力出來當老闆就認命拿勞力
換錢
等等,寫一年半的程式是有能力去規劃重構的嗎?
能呀 不然要請那些寫15年程式的老狗去規劃重構呢
推六樓~做久了覺得真是這樣+1
40
[問卦] 程式能寫if 就不要用for loop?以前寫程式覺得要看起來厲害 明明能用if的 我會先建一個table 然後再用for loop尋找 好處是數量增加時增加的程式碼少 壞處是寫的時候和以後回來看的時候比較麻煩20
[請益] 公司請人如何看待ChatGPT?就是原本想轉換新程式語言, 原本推算會有很多東西要學, 但剛好ChatGPT騰空出世, 一開始想用ChatGPT來學 結果發現因為知道需求,24
重構的幾個迷思覺得最近很多文章都有些不求甚解的問題,來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼,重寫舊的程式碼成自己爽的樣子,不一定是重構。 3. 重構是一種相對安全的工具型開發方法論, 但仍然有不少風險跟誘惑。17
Re: [討論] 重構之前要寫測試 不然不要重構這就是TAD, 一般做法是假設以前人做的是對的 拿以前的output當測資 避免以後的output跟預期結果不同 技術面的錯誤→沒有防呆/沒有釋放資源/overflow/沒有check 這應該不在討論範圍內, 也有客觀標準 行為與邏輯的部分才是有爭議的, 要嘛根本沒規格只有口傳15
Re: [請益] 這種情況要怎麼重構我這篇寫的跟原原PO的狀況無關 ※ 引述《tbpfs ( )》之銘言: : 其實我真的不懂為什麼要急著重構 : 有好處嗎? : 一般而言,重構都是發生在農閒的時候12
Re: [請益] 如何選擇適合的設計模式請你把clean code三本都看完 可以的話clean architecture也一起 這系列就是在講什麼時候該用什麼模式的準則 我這篇也講幾個重點原則 1. 保持簡單7
Re: [請益] 痾 遇到這種事情 是不是需要趕快離職了?我個人感覺程式語言也是有語感的 跟學歷關係不大 我自己碰過一種寫法 if 變數 == a print 甲.jpg if 變數 == b print 乙.jpg5
Re: [請益] 請問程式架構和資料結構的差異安,小弟最近在複習資料結構 剛好看到了魔術方陣這題練習題 附上c#原始程式碼 你可以學我用物件導向的方式7
[問卦] 抽獎程式外包是不是很好作弊?公司內沒有軟體專業人員 抽獎程式找廠商外包 公司內部人員也沒能力監督這套程式 能正常跑就丟出來用 找律師來公證 律師又不會寫程式6
Re: [問卦] C++到底難學在哪裡同意你說的,寫程式確實天分有差 我跟很強的博士班親戚爭論過這點,對他來說 他覺得可以通過努力跟學習 對我來說,他就是有興趣、有天份加上肯努力的成功典範 而我,只是半調子,能過就好