Re: [討論] 會手癢想動前人的程式嗎?

作者
看板 Soft_Job
時間
留言 20則留言,10人參與討論
推噓 5推 1噓 14→
※ 引述《sec5566 (sec)》之銘言: : 或是命名規則有問題的, : 像函式用大駝峰,類別用小駝峰, : 或很奇怪的名稱之類, : 不然就是排版很亂的, : 這種大家會手癢去改嗎? 就跟推文鄉民講的一樣 這是團隊的管理問題 通常命名如果不符規則 只是改大小寫這應該不用過問吧 但是改名稱 老實講這要看寫的人還在不在職啦 不然你改了 code review時解釋說: 這名稱很奇怪 除非你跟對方溝通過 或你比對方大牌 做事做就是做人 沒有對事不對人的 (何況 你有辦法保證你的命名一定比較好?) : 改下去又是大工程了,結果工作越做越多 你前面講dry原則的 軟體開發原則很多 但這些原則多半都被有心人士拿來吵架用 更何況 這些原則能不能為商品帶來價值 多數都不能 我建議三小原則的 放在自己心中默默實踐就好 我講一下重構的幾個種類 這是小弟我在業界的觀察 1. 命名、拆解 這就是clean code裡很基本的東西 function不要太長 命名清晰描述單一動作 改名的事情我前面說過了 這邊就不贅述 IMO 比起改錯字、大小寫 他命名很奇怪我把他改掉 把大function拆解成小function 還比較有用 (而且絕對不會是大工程... 所以... 要實踐你所謂的dry可以從小事做起) 2. 運用語言技巧 精簡程式碼 老實講這種事情就只是單純的炫技 小弟我就曾經把一大段大量重複的code 利用Template 將邏輯拆解成Policy 使得每個重複的流程都可以透過組合的形式避免duplicated 但說真的 它的價值就只有文學上的價值而已 (我認為在某些狀況下 重複的code不見得是錯誤或不良的) 3. 架構 我認為需要改架構的狀況只有幾種: a) 邏輯紊亂重複 導致效能低落或維護不易 b) 當前的架構無法因應新的需求或改變 這種狀況 才是你所說的工程浩大 不然一般狀況下的重構搬移刪除重複代碼都只是很基本很淺的功夫 TL;DR 其實重點是這樣的 在這個業界 有需求 滿足需求才會產生價值 你的需求 如果只能滿足你個人 那我肯定你做的事情是沒啥幫助的 更何況 你重構又怎麼能保證不會有新的問題產生 所以最好的方式是 建立測試 才去重構 而不是重構自己爽完了 留給後人收拾問題 小弟上次重構 把一個重點功能的速度提升至少2.5倍 還贏得了與某大公司進一步合作的機會 給你參考 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.50.60.32 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1547265388.A.B12.html
t64141: 第二點,當專案需求是頻繁更動的時候,重用性的價值就出來了 01/12 12:05
t64141: 只需要修改一個地方跟修改一百的重複的地方,時間跟測試成 01/12 12:07
t64141: 本與風險都不一樣 01/12 12:07
Beatles5566: 只有文學上的價值 lol 那你改之前大概是秒懂型的code 01/12 12:12
Beatles5566: 改完之後反而多花時間看template 01/12 12:13
學Java還要特地跑到資策會的人 當然需要多多花時間練習看template呀
oneheat: 真的是小弟 01/12 12:53
NDark: "你保證你架構比較好?" 其實用相同的邏輯可以駁倒你. 01/12 13:01
我並沒有說我的架構比較好 但產品效能提升&受到認可是事實 我也不想浪費時間定義什麼架構 什麼命名比較好 誰有更好的做法 誰能帶來更好的效益 誰都可以去實踐 誰替公司賺錢 替公司貢獻技術 誰替產品解決問題 我想這才是最重要的 整天把架構問題搬上檯面吵 想著要駁倒誰 是把軟體架構當解決問題的工具 還是當作製造問題的工具呢? :)
DefTM: 覺得中肯 改什麼不重要 重要的是能替公司賺多少 01/12 13:49
※ 編輯: bachelorwhc (123.50.60.32), 01/12/2019 15:43:40
accessdenied: 推一個 01/12 16:29
Ghamu: 重構本身不是輸出輸入不變 只是改改程式碼 拆分 增加可讀性 01/12 17:38
Ghamu: 嗎? 提升速度效能 那算是另一個事情吧? 01/12 17:38
是兩件事沒錯 但我說過我認為兩種狀況下需要重構: 不易維護或流程過於複雜、有新的需求 我當時的目標是要提升效能 因為既有的程式碼很難滿足 所以才進行重構 這就是一種需求 而不是因為覺得自己架構比較好 才進行重構 至於你說的 改改程式碼 抽取function 這些看似很基本的事情 其實也能發現一些多餘的流程或效能不佳的寫法(當然你本身也要有鑑別這些問題的能力)
Ghamu: 增加可讀性是有用的 因為很多開發時間都是在閱讀程式碼 解b 01/12 17:42
Ghamu: ug 實際寫全新code 的佔比不如想像中的多 命名那些 我以前 01/12 17:42
Ghamu: 也有心魔覺得不要亂改資深同事的 但看書說 就給她給下去吧 01/12 17:43
Ghamu: ~ 原因很簡單 寫那段code的人早忘記了 改好的話會感謝你 01/12 17:43
iq1000x: 改程式碼就有可能速度不一樣了啊 又不是只改命名… 01/12 18:54
※ 編輯: bachelorwhc (123.50.60.32), 01/12/2019 19:45:04
ChungLi5566: 翻譯:耦合性 內聚性 每個人拿捏程度不一 01/14 08:52
BoXeX: 想到前公司有段code寫得非常巧妙 物件化的很好 01/14 22:29
BoXeX: 結果大家常用的 debug 工具在那邊很難用 01/14 22:29
BoXeX: 變成最難維護的一段 code 01/14 22:29
看更多 bachelorwhc 的文章,或回到 soft_job 看板

完整討論串

留言數 標題 作者 日期
68 [討論] 會手癢想動前人的程式嗎? sec5566 2019/01/11 15:08:43
20 >> Re: [討論] 會手癢想動前人的程式嗎? bachelorwhc 2019/01/12 11:56:25

最新熱門文章

[情報] 今日先發
[Lions] Sky77777777 551留言 2019-03-24 15:07:56
[公告] 水桶
[Baseball] tmlc 468留言 2019-03-24 13:53:43
[討論] 3/24 多益考試
[Toeic] mistel 301留言 2019-03-24 12:03:29
[閒聊] 陽岱鋼炸裂
[Baseball] thnlkj0665 260留言 2019-03-24 13:30:44