→ 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