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:34補充一下,TDD 是還沒有開始寫任何的 code 之前,就先針對
程式寫好之後 "預期應該要有的行為" 先寫 test cases
接著,先跑一次測試親眼看著他 fail
因為還沒寫任何 code,所以測試絕對會 fail,
如果沒寫 code 卻 pass 那表示你的 test case 根本沒有測到。
接著才開始寫 code,重複跑測試直到確認 pass 為止,就是完成了。
不同於先寫 code 再測試,TDD 是顛倒,先測試再寫 code,所以才叫 test driven
如果程式被報 bug,也是先寫一個會 fail 的 test case,確認可以重現 bug
接著才開始改 code 修正,直到測試 pass 為止,就表示修好了。
這是一個觀念很特別的流派,他們的主張都是有道理的,就只是比較違反直覺不好實現。如果你無法先寫出測試,那表示你還沒弄清楚要實作什麼行為,
或是你原先構思的 API 介面難以使用,以至於你寫不出 test case
這是強迫你釐清 spec 以及設計好介面的方法,但實在有點極端,被不少人視為邪教 XD
: 推 TeaEEE: TDD最大的阻力來自你的老闆 08/24 11:40Testing 相關的東西常常是這樣,因為一開始看不到立竿見影的成果,
花掉的資源,也沒有立刻轉成給客戶的價值,跟下水道工程一樣重要但看不見。
: 推 wulouise: TDD在需求不明確的時候寫會很痛苦,SPEC改testcase全改 08/24 12:43: → wulouise: 但只有一個test, 還是可以加快開發的iteration, test編 08/24 12:46: → wulouise: 譯執行時間通 08/24 12:46: → wulouise: 通常比跑production快很多 08/24 12:46這個事情我覺得不是 TDD 的鍋,需求不明確本身就很痛苦,TDD 只是讓你提早面對它
需求不明確或是改來改去,你連 code 該怎麼寫,寫出來該有什麼行為都不知道
自然是無法寫出 test case 的。但反過來說如果狀況是如此,你寫出的 code 會對嗎?錯是錯在沒定義清楚程式行為,不是 TDD 的錯。
TDD 只是一面鏡子,讓你提早發現問題,事實上這是好事。
表面上測試寫得很艱難拖慢進度,實際上是反映團隊溝通不良,和需求不清的問題
我們應該解決問題,而不是解決發現問題的人(跳過測試不做)
如果放棄做測試來節省時間,做出問題一堆的產品,這些時間後面也是要加倍還...
但也有情況例外,就是做 MVP 的時候。還來不及做測試,產品就被取消了,就免還債 XD
: → foreverk: TDD比較可怕的是工程師還沒掌握domain,寫出不合理的te 08/24 14:04: → foreverk: st case,而且自己不知道 08/24 14:04這或許不是 TDD 的鍋,domain 掌握不足,設計出來的 API 多半也會是有問題的,
TDD 並沒有讓事情更糟,只是強迫問題更早浮現罷了。
說了半天整篇都在幫 TDD 護航,但我自己大多是沒在用 TDD (汗顏...)
主要原因還是真的很難習慣,而且經驗比較不足,有時候 API 設計也是 try & error
雖然整個軟體巨觀該有什麼行為已經訂出來了,但程式會拆成很多小模組
每個模組該有哪些行為,完全端看你怎麼拆,而很多時候就是這點難以決定,
需要稍微實驗不同的作法,在這個階段強迫要先寫 test 還真有點強人所難。
但如果是定義很明確的 API,例如 web 後端的 RESTful API,介面都已經訂好了
這時候遵循 TDD 先寫 test case 完全是可行的,有興趣的朋友不妨一試!
--
Sent from PCMan on PCMan's PC
--
想問若是前端的話,該怎麼TDD較適合呢?觀念都理解,
但在前端常常寫一寫又拆出子組件…
抱歉這個我無法回答,我自身經驗也不夠 XD
雖然我能理解也算認同TDD的理念,但也沒辦法真的掌握它
應該不少人覺得實行起來困難,所以批評聲浪也沒停過
笑死 “Sent from PCMan on PCMan's PC”
推,最近寫UT也是很苦手,很高興可以看到此類討論
推
越靠ui的通常越難寫寫UT...至於規格不明確的確是不該怪T
DD, 只是不明確的時候應該先弄清楚再來寫XD
好想進去有走TDD的公司 感覺好讚
說真的有unit test就很好了,100%TDD執行面有困難
原來是這樣~感謝分享
前端大概或許用testing-library那種測法,內部你怎麼
拆不管
同意TDD是讓問題提早浮現,尤其edge case可能是使用到
其他api時才會發現的,不過通常需求會一環扣一環,團隊
其他人可能寧願你先寫個可以跑的東西讓他可以接下去,
而不是等到TDD流程都走完,要求團隊都有單元測試都有點
難了,還要大家都TDD實在無法想像XD
單元測試不是放在重點服務及重點功能上嗎?
真的有公司所有的程式都寫UT嗎? 實務可能嗎?
TDD很難的原因有可能是需要重構到很精簡沒有相依
才能寫出有效的測試 在開發階段寫UT就沒什麼時間了
更何況要重構 以及擔負重構衍生出的問題責任
你寫的任何程式不測試怎麼知道對不對,你把寫console lo
g跟用眼睛看結果的時間拿去寫 unit test就好了
一般真正能落實的公司,就是考管理政策推動。線上出現Bug
,不同等級,對於考績的影響是什麼,導致Unit Test,cover
age,增量覆蓋率,都有規範,避免出大錯。有了管理與考績
支持,TDD就變成增加效率的優勢了。
沒靠管理支撐品質,人都說有惰性的,絕對不覺得TDD多重要
。
結果是一張圖的時候應該沒辦法很難測吧
*應該很難測
面對隨時有隕石會砸下來的情況下TDD有用嗎?
其實越常變化或擴展測試的用處越大,不過跟 TDD 較無關
有寫就有用,不一定要 "先" 寫
TDD 可以提早驗證 API 的使用性有沒有缺陷
但並不是 API 漂亮就不會在架構上遇到問題
有時候兩邊都要顧一下會比較平衡
好奇真的有辦法先寫好unit test在開始寫程式嗎?
很多unit test都是在assert function 沒function的話
沒function的話要怎麼compile過呀 還是是說function先
宣告但內容不寫 然後先寫測試這樣嗎?
極端一點沒 function 直接寫測試也可以,要確定他會 fail
當程式有 #ifdef 的時候確實可能有些 code 根本沒 build
所以從頭到尾測試根本沒 build 到,先確定會 fail 有幫助
或是像 python,沒定義 function 也能跑 runtime 才失敗
這種也可以先跑看看確定他會 fail,確認 test 真的有執行
我自己真的有遇過 test function 沒跑到,結果假性 pass
原因是我把 function name test_xxx 拼錯成 tset_xxx
於是 python 的 unit test 沒抓到這個 test function
怎麼跑都 pass,因為根本就沒測到。所以不要覺得這很多餘
或是先寫個空的 function,跑看看確認他真的會 fail
這算是 TDD 一個重要的觀念
真的要先fail才有辦法確定他是有用的XD
我有遇到test永遠是對的 裡面對不對根本不知道
還有根本不存在資料被判斷存在,因為跟其他資料重複XDD
你有規格書就能先寫啊 沒有就只能邊做邊摸索
其實想起來也沒那麼邪,就像刷題,也是test先寫好等你
好
TDD難在要想出各種案例XD
TDD在做自己私人專案的時候比較好用,因為自己寫的本來就
比較隨興,用TDD方法一步一步做比較不會放飛自我
個人的經驗,一堆人在等你的code才能繼續下去,一個禮拜過
去了,這時只說我由於用tdd只完成了測試程式,會遭人白眼,
所以通常我們還是會先完成功能再補測試程式
tdd是測試跟實作交替寫,會說測試先寫完就是做錯了
測試先寫是針對要改動的地方,不是整個系統都只先寫測試
實務上確實是交替進行沒錯
TDD不會升遷啦,寫爛code升遷學弟接手讚讚(反串)
個人經驗TDD 適合需求明確的開發 不然光改測資就耗掉一
堆時間
1
關於 TDD 個人一點看法 我覺得 TDD 最大的用處是讓你 "做一下,想一下", 這件事本身就很有用,相信有不少人有類似經驗, 很快想到一個版本,在幾個循環後陸續想到 3~5 個改版, 其中則有某個版本特別好實作,可以用初版 1/5 以下的時間完成,3
剛好看到這個影片 觀摩資深人員是怎麼深入原始碼把 wasm64 轉成 wasm32 還能正常執行 他有一些直覺解臭蟲的作法讓人感受到真不愧是資深人員,而且猜函式名稱的準度有夠 高8
我提一個好像沒有人討論的點 一個合格的junior/entry-level C++ programmer應該要良好的trace code技能 這個也不是只有C++適用 而是所有語言都適用 在學校除非個人興去的關係碰過open source code 否則很難碰超過1萬行的code4
推文看到有人問前端. 我個人是做客戶端所以很多傳統的測試方法論對介面其實效用很低. 上述段落讓我想起以前寫作的經驗.單純分享. 我在2018~2020年在阿布達比UB維護手機線上遊戲Growtopia. 當時的案子有很多駭客想要破解我們的遊戲的攻擊行為.38
個人淺見,這點不見得是必要的,template 的 code 常常不好讀不好除錯 正確使用能寫出高彈性高效能的程式,但用過多維護跟閱讀起來會很痛苦 即便不用 template,日常大多數的事情都還是可以完成的, 如果是多人一起維護程式,有時為了提升可讀性,反而會避免太炫麗的 template 技巧 新人的話推薦不妨投資點時間,學習如何改善可讀性和與別人協作6
先說 我不會寫C++ 但是關於軟體架構和Design Pattern我可以補充一下 軟體架構實際上在台灣多數職場裡的狀況 大概可以用一句話來形容18
首Po諸位資工大神好,我本身是EE背景的 因為想脫離design house的生活 一直有在刷題+補充Cpp, oop 相關知識 之前有幸找到一份junior寫Cpp的工作 想了解對各位來說,有沒有一個對於qualified cpp programmer的具體標準1
錢很多,人難找。 : 2.維護legacy code 錢不錯到很多,公司賺錢有一些是爽缺。 : 1.的話重點是一堆效能增進的技巧 : 像是如何提高cache hit rate 或是multi threading的技術9
現在語言這麼多 你想學c++的目的是什麼 其實個人感覺你提的點以c++來說都不是重點 這年頭如果還有公司有c++的職缺 通常分兩大類 1.高效能運算21
STL 之外 boost () 也要會用一點, 有餘裕的話這兩個也稍微看一下: 如果確定公司偏好用哪一套的話可以指向性學習。
爆
[心得] 20年測試版上最近有十年設備的文章 那我也來分享一下20年測試好了 我的學歷是私立五專機械科 五專四年級的時候組了一台PENTIUM-75的桌機 畢業後機械科不知道要做啥 當初還去松山車站附近應徵機車學徒 後來去青輔會學電腦網路 一開始去光華商場附近的茂訊電腦當網路工程師 說好聽是工程師 其實就是客人買電腦之後 我來組裝出貨85
[請益] 接手外包商的code沒交接也沒人可以問各位大神好 我是最近剛從資策會(java)畢業找到目前這間台中的類博弈公司(40k) 面試的時候沒問目前團隊的狀態 上班第一天才發現原來我是第一個RD。MIS則是大概有六位 公司目前的code都是之前中國外包廠商寫的84
Re: [討論] API沒資料,回200還是404比較好這篇就不以引述的方式回覆了,因為算是對 後續其他人不論在推文中或是回文中的內容 回覆,另外也是針對我自己在前一篇文章中 沒有提到的部分進行說明。 (1) 敘述問題與回答問題77
[心得] 為什麼幹了20年 我終究還是一個測試仔前情提要: [心得] 20年測試 在講接下來故事之前,我先闡述我對於工作態度的定義。 我想引用我在方格子的一篇文章:67
Re: [請益] 接手外包商的code沒交接也沒人可以問我的第一份跟第二份工作都是這個樣子,一開始你會像麻痺的人,給你幾個建議 1. 掌握啟動前的入口 - 大部分程式語言都會有一個從作業系統下命令開始執行 的進入點,可能會載入 config、環境變數、命令參數這些東西,你要先清楚 這些東西的配置意義是什麼。 2. 掌握啟動後的入口 - 如果是 server 或常駐程式,在執行階段就會有監聽行為。40
[問卦] 程式能寫if 就不要用for loop?以前寫程式覺得要看起來厲害 明明能用if的 我會先建一個table 然後再用for loop尋找 好處是數量增加時增加的程式碼少 壞處是寫的時候和以後回來看的時候比較麻煩56
[請益] 快40的測試工程師轉職各位神人安 小弟目前在此公司已任職快12年了,年紀也來到了38歲 公司是個小公司(80人上下) 從進公司寫韌體一年後轉為職測試工程師已經10-11年了 月薪60K,年薪100-140(跟大神們比差很多)21
Re: [討論] 重構跟kpi的考量如果 A, B 都沒有任何 tests,建議不要動他。 幫 C 實做這個功能的時候,把 unit test 寫好寫滿,確保 C 是對的 行有餘力,針對 A, B 的使用情境也加上 test case,確保未來在 A, B 確實能重用 (這點很重要,否則很容易程式長得很像你以為可以重用,實際上根本不能) 就先做到這樣就好,確保 C 的品質,同時你獲得了高品質的 reusable 模組14
Re: [討論] 做測試的真的這麼慘?測試百百款,這邊回覆一下IC的ATE測試相關。 (俗稱CP、FT的測試,半導體測試廠與其相關) 單做TE就是賺不到大錢也餓不餓死的工作, 不會到慘來形容它,至少相對機會多。 看著現在多半的IC test TE就分主要兩大塊: