Re: [討論] 重構之前要寫測試 不然不要重構
※ 引述《Ghamu (貓丸)》之銘言:
: 但事實上之前都沒寫測試了
: 你怎麼證明他之前是對的呢?
這就是TAD, 一般做法是假設以前人做的是對的
拿以前的output當測資 避免以後的output跟預期結果不同
技術面的錯誤→沒有防呆/沒有釋放資源/overflow/沒有check
這應該不在討論範圍內, 也有客觀標準
行為與邏輯的部分才是有爭議的, 要嘛根本沒規格只有口傳
要嘛就是寫的人弄拙成巧 剛好做對
所以在沒有規格跟明確定義的狀況下寫測試 只是寫的人自己覺得對而已
test code也是code 也一樣要維護 也一樣有可能會寫錯
: 所以我大多都直接給他改下去
: 反正重構後東西也比較清楚
: 即使有錯 也比起蝦雞巴狗爛毛程式碼好除錯
每個人都覺得對方code爛 現在我都用: 我就爛 的心態來寫
: 之前前輩都說會動的程式碼不要去碰
: 然後就一球在那邊
: 我說要改 他就說
: [啊你有寫測試嗎?]
: 開發時程又不允許
你沒聽出話中話 人家前輩是好心人
大家都寫程式 又不是你最聰明 所有人都知道時程不允許
你改了code 出現一堆bug 鍋在你頭上
對方一方面也知道那是爛code不想明講 搞不好寫爛code的人還在公司
一方面也知道重構沒有多少績效 做不好還惹得一身臭 期望值低到爆表
人家處處為你著想 你何苦先入為主
要是我是你同事 一定默默地讓你重構
: 就一球在那邊越來越痛苦
: 會動的爛程式碼越來越多
: 不知道大家怎麼看
ptt都是菁英群
基本上大家寫code都是clean code 還有落實unit test
要不是待在根本沒有legacy code的新創公司
要嘛就是會把數以萬計的legacy code補完unit test的楷模員工
你要是在的公司根本沒有在寫test
說明你公司太爛 八成沒一個同事是鄉民
建議你換好一點的公司 再上ptt跟大家討論 比較有共同基準
--
GJ
XD
中肯酸XD
沒有人寫test 因為tester把設計者氣跑 tester也不想別人測
通常自認為完美的程式都會死在外行測試者手上
誰規定我一定要照你邏輯操作?
那是edge case考慮不周全,所以才需要tester,跳脫思考框架
每個人都覺人其他人code爛 我可以理解XD
我也覺得自己以前寫得爛..沒test重構還能確保沒錯很神
推 中肯回覆
公司重視的只有產出,而不會在意100%的測試覆蓋率,要
重構還是先把功能做出,有時間再來寫測試,讓後面的
維護不會改A壞B
可以看看TDD是怎麼用測試把product code產出來
code本來就會因為業務邏輯熟悉程度有好壞之分
對業務夠熟把爛code整理一下也是好事
XDDDD
XDDD
厲害了 我也是這樣想所以離職 但是就沒工作了QQ
中肯酸
中肯
尤其最後兩段
高手都是隨便不爽不要做換公司或爛到說服老闆打掉重練
就沒legacy code了 根本就不需要重構及寫測試 尤其是
別人寫的程式
笨蛋才佔著茅坑(公司)不拉屎(爛code) 高手都是坑滿了
之後 換個茅坑再拉屎的好嗎
高手們躺著寫code也中槍
還以為凡事必OO凡扣必UT的毒觀念消失了 沒想到還有著魔
的人
酸度有像阿ㄆㄧㄚˇ
笑死 推這篇
最後一段很中肯啊,沒測試的地方還是不要久待
35
[討論] 重構跟kpi的考量假設以下情境 有個功能A、B都會用到相同邏輯,且有兩份重覆的code (沒有unit test保護,而且年久失修 要加入unit test會需要更多時程) 現在要加入C,也會用到相同邏輯 身為合格的工程師 應該會把ABC重覆的部份提取出來24
重構的幾個迷思覺得最近很多文章都有些不求甚解的問題,來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼,重寫舊的程式碼成自己爽的樣子,不一定是重構。 3. 重構是一種相對安全的工具型開發方法論, 但仍然有不少風險跟誘惑。23
Re: [討論] 怎樣算是一個合格的junior cpp programme針對關於 TDD 的討論另外回一篇好了 覺得用推文太長了 XD : 推 stupidlove0: 朝聖!重要的真的是unit test 08/23 18:47 : → HZYSoft: 回樓上 TDD 問題,TDD 不只要測試,還要先寫測試才寫code 08/23 21:33 : → HZYSoft: 很多人無法習慣這種順序,是否一定要 TDD 這有爭議 08/23 21:3421
Re: [討論] 重構跟kpi的考量如果 A, B 都沒有任何 tests,建議不要動他。 幫 C 實做這個功能的時候,把 unit test 寫好寫滿,確保 C 是對的 行有餘力,針對 A, B 的使用情境也加上 test case,確保未來在 A, B 確實能重用 (這點很重要,否則很容易程式長得很像你以為可以重用,實際上根本不能) 就先做到這樣就好,確保 C 的品質,同時你獲得了高品質的 reusable 模組16
Re: [請益] 這種情況要怎麼重構1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人. 2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1). 3. 假設改完會有衝突, 那表示你做的不是重構. 4. 如果完成再重構會花更多時間, 那表示你做的不是重構. 5. 你要用他的 code , 跟你要整理重構, 是兩回事.16
[討論] Unit test 的撰寫請益先說我對 Unit test 的看法:測試單元(可能是 function)的邏輯是否正確 好,進入正題 小弟最近剛工作,稍微讀了一下負責的 project 的程式碼後, 要開始開發 Unit test。 現況是,各個 file (.c) dependency 很重,13
Re: [討論] 重構跟kpi的考量感覺這個標題就是個假議題,你說不重構A、B因為Unit test來不及寫,那你新寫的C就不 用unit test了? 然後你又說三個code一模一樣,假設你幫C寫完unit test了,那你不就也把AB搞好了嗎? 再退一萬步來講,AB沒有unit test大家用的那麼爽你還硬要去動也只是吃飽太閒,不如 好好寫你C的unit test,寫完大家就用C就好啦13
Re: [討論] Unit test 的撰寫請益先說在前面 雖然聽起來很幹話,但很多東西沒有標準答案 有時是合適度的問題,也可能是喜好(品味?)的問題 同一個題目,實際的 code 長得不一樣,可能也會用不同的方法處理 另外,除了資源豐富到人力充沛到不行的專案,以及幾乎沒有時程壓力7
Re: [請益] 該辭職嗎?到哪都會遇到垃圾系統 還沒聽過哪家公司沒有垃圾code, legacy code, 歷史包袱的... 如果你的主要考量是這個系統太爛不想改他 那我會建議不要離職. 因為不管你走到哪,都會遇到一樣的問題5
Re: [心得] Paypay Android面試分享我自己是覺得 考作業也很難看出一個人的coding習慣 例如他commit message寫很完整 有做unit test 也有符合物件導向原則 clean code等等的 但實際上工時通通都沒做到呢?