|
|
在 appWorks 有一些問(wèn)題我們常常討論，例如：用什么工具、做什么產(chǎn)品、該怎么營(yíng)銷(xiāo)、該跟誰(shuí)合作、怎么合作、什么時(shí)候增資、該拿多少錢(qián)…等等，這些問(wèn)題往往沒(méi)有一定的答案，也必須要視情況而定。但越是沒(méi)有標(biāo)準(zhǔn)答案的，我認(rèn)為越是應(yīng)該多討論，這樣才能幫助創(chuàng)業(yè)者們根據(jù)自己的情況，定義出最適合自己的處理方式。
而關(guān)于 coding，「要不要寫(xiě) test」就是其中有一個(gè)這樣的問(wèn)題。我個(gè)人的意見(jiàn)是當(dāng)你要做一個(gè)非常簡(jiǎn)單、用完即丟的MVP，那不必寫(xiě) test。如果邏輯比較復(fù)雜、日后有維護(hù)的必要或是和別人協(xié)同工作，那你一定要逼迫自己寫(xiě) test。
這絕對(duì)不只是完整性、邏輯性或是身為一個(gè)工程師的職責(zé)問(wèn)題，而是你如果不寫(xiě) test，就是跟自己過(guò)不去——跟好的comment/documentation一樣，不做的話，日后要維護(hù)時(shí)，你將會(huì)花更多時(shí)間在弄懂自己當(dāng)初寫(xiě)的code上，當(dāng)別人要用你的東西，你也必須花更多時(shí)間跟他解釋?zhuān)@不就是跟自己過(guò)不去嗎？
我得承認(rèn)關(guān)于更深入的判斷什么時(shí)候要寫(xiě) test、該怎么寫(xiě)，我不是專(zhuān)家。但是今天讀到一篇文章寫(xiě)得很好，在這里跟大家分享。
- Test 讓你用程序功力去挑戰(zhàn)你的程序功力 —— 身為工程師，大家最討厭的就是不斷的手動(dòng)測(cè)試了，那何不把這些寫(xiě)成程序？況且最好的進(jìn)步方法就是以己之矛，攻己之盾，這樣不斷的循環(huán)下去，你的程序功力一定突飛猛進(jìn)。
- Test 讓你跟你寫(xiě)的程序還有你自己對(duì)話 —— 當(dāng)你若干時(shí)間之后回來(lái)看自己寫(xiě)的 test，你將會(huì)重新檢視自己當(dāng)初的邏輯——這樣復(fù)雜的錯(cuò)誤處理真的有必要嗎？這個(gè)對(duì)象夠獨(dú)立嗎…等等，并且想清楚你寫(xiě)的程序跟整個(gè)系統(tǒng)的架構(gòu)是否吻合。
- Test 提醒你程序是用「用了」多少行衡量，而不是「寫(xiě)了」多少行——記住，最棒的程序代碼，不是程序代碼！
- 好的 Test 設(shè)計(jì)還包含好的 Test 批注——如果你寫(xiě)好的測(cè)試，別人更容易了解你的程序，和如何跟你介接。
- Test 讓你可以看穿別人寫(xiě)的 code ——同樣的道理，如果大家都寫(xiě)好的測(cè)試，那你可以更容易了解別人寫(xiě)的 code，大家都會(huì)進(jìn)步的更快。
以上，就是一些關(guān)于寫(xiě) test 這件事情的觀念，希望能夠讓你更認(rèn)同 test code 的價(jià)值。或許你有更有趣的經(jīng)驗(yàn)？歡迎留言跟大家分享。
imagevia richardmoross
it知識(shí)庫(kù)：Coding: 寫(xiě) Test 還是不寫(xiě) Test?，轉(zhuǎn)載需保留來(lái)源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
