關於「重構─改善既有程式的設計, 2/e (Refactoring: Improving The Design of Existing Code) 」 的讀書心得- GitHub - ms314006/refactoring-with-javascript: ... ... <看更多>
重構改善既有程式的設計心得 在 Refactoring Ch.2-Refactoring Theory - Shan 日常筆記 的推薦與評價
綜合網路上巨人們的讀書心得 ... 在既有設計中想盡辦法改善它! ... 當使用重構的方式開發時,會常在程式重構及加新功能這兩個mode中互相切換。 ... <看更多>
重構改善既有程式的設計心得 在 重構的幾個迷思- 看板Soft_Job - 批踢踢實業坊 的推薦與評價
覺得最近很多文章都有些不求甚解的問題,來寫點論述。
1. 重構不是什麼了不起的事情
2. 變更程式碼,重寫舊的程式碼成自己爽的樣子,不一定是重構。
3. 重構是一種相對安全的工具型開發方法論,
但仍然有不少風險跟誘惑。
4. 如果你不應該或沒權力改的程式碼,
不要以為自稱是重構就能取得變更的權力。
5. 測試(單元或整合),是一種快速驗證,
程式是否符合自己預期的工具,但並不是不會犯錯的保證。
因為,自己的預期可能就是錯的,也可能測試相依過深,
一時半刻沒有足夠好的介面,測不到真正的主要情境。
6. 不論重寫或重構,所有的程式碼變更都有一個本質,
要把時間花在刀口上,對重要的程式碼優先處理,
不重要的程式碼延後處理,程式碼都有優先權問題。
所謂的程式碼沒壞就不要修他,
本質上是「如果他的現況不影響別的事情,暫時不用管他」。
但如果他已經卡到別的功能的擴充或維護,
造成 DEBUG 困難,常出問題等,修改他就有了價值。
那個狀態就又是另一回事。
======
另外,有些話我覺得講的不夠白,做點翻譯:
1. 東西沒壞就不要改他:
你最近改壞的東西太多了/
你最近正常改好的東西太少了/
這段扣不關你的事情你沒有權限可以碰。
2. 開發應該要先做測試:
你最近改壞的東西太多了/
你最近正常改好的東西太少了
3. 要重構之前應該要先做測試:
你現在的 CODE 搞不好都已經在亂寫了,
再大規模改 CODE 會不會死的更難看。
4. 這 CODE 寫的很爛:
我想把 CODE 改成我看起來爽的樣子
=====
坦白說,你寫程式品質高的話,要怎麼炫技都可以,
凡人登山要確保,很多高手可以無確保登山,
但這些人每隔幾年也就會有一兩個摔死上新聞。
嗯,反正說到底改程式碼的權限是個政治問題。
打著重構或效能調整的名義變更是沒關係,
但有沒有做好,是一翻兩瞪眼的事情。
個人 Credit 喪失事小,
把使用這個工具的人給搞成白癡事大,
還麻煩大家,量力而為。
自己爛,不會開發,不要牽拖工具方法論。
要重構先還是要測試先,會問這種問題的,
還不如先練習看看什麼是重構,什麼是測試。
-----
Sent from JPTT on my Google Pixel 3 XL.
--
網頁上拉近距離的幫手 實現 GMail豐富應用的功臣
數也數不清的友善使用者體驗 這就是javascript
歡迎同好到 AJAX 板一同討論。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.231.31.193 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1594081682.A.E16.html
比起有沒有事(應該沒多少人是真的沒事的),
更重要的問題是很多人會看 code 看不順眼. (不過這個行為本身不見得是壞事)
看到一個問題就想要去挑戰更好的作法,
不論是求表現也好, 或是想找事情殺時間, 這是人之常情.
※ 編輯: TonyQ (210.61.209.201 臺灣), 07/07/2020 10:49:27
我自己改過很多次, 通常原因都是前人能力不足/膽量不足.
所以要問問的應該是自己有沒有比前人厲害.
這篇真正的立場叫做掂掂自己斤兩。
... <看更多>