文章插圖
每次都會有人意識不到 。這么簡單的題目都會被繞暈，到底要多有自信，fizzbuzz問題，才會覺得復雜的需求不會出錯呢？所以還是老老實實的給自己加測試防護網吧 。測試一個很重要的原則，是防止低級錯誤，而不是惡意欺騙 。
先確認需求，再實現(xiàn)，需求以測試的形式寫出來，然后再去實現(xiàn)，這就是TDD了 。如果實現(xiàn)的時候只java需要關注其中一種可能性，這樣思維負擔比較輕 。如果你腦力強勁，覺得步子大一點沒事，你就步子大一點，我是沒有講解此等自信 。有些人問我，TDD的時候測試有沒有階段性，測試是否有要分批寫？我大概會分三批：
第一批測試只有一個測試，意義是：定義輸入輸出，確定函數(shù)在哪 。第二批測試的意義是：建立主干框架，把程序的主干走通 。然后再寫第三批測試，把各種分支和異常都考慮到 。這樣寫出來的程序就是一個比較健壯的程序 。反過來看，當你時間不夠的時候 。你要減的測試是哪個？肯定是第三批測試，不是整組干掉，而是在這組當中減少量 。有很多人會說自己沒有時間寫測試，或者說測試很浪費時間 。但是如果你打開代碼的時候，發(fā)現(xiàn)前兩組測試都不存在，就很說不過去了，因為前兩組幾乎不花什么時間 。而且如果做得好還會提高效率，減少時間花費 。一個最簡單的道理，當我有一天出了bug，我能以多快的速度建立一個可運行的程序現(xiàn)場，fizzbuzz java，以多短的周期反復重現(xiàn)這個bug，并且對新解決方案進行嘗試，決定了修bug的速度 。前兩組測試完全可以為這個場景服務，而這個場景不完全發(fā)生在測試測出來bug，在我們日常寫代碼的時候，我們不能保證我們寫的代碼是一次就能寫對的，那么在沒有寫對之前就等于代碼中存在了bug，也是要反復調試的，那這個對實驗的周期時間的要求是一樣的 。有那個調試的功夫，直接看測試不是一樣嗎？
過度設計
到此為止，我們寫出來帶的代碼如下所示：
文章插圖
實現(xiàn)并不復雜，仔細看看這代碼還可以，夠用，不難懂，那就行了，我們就先不請英語重構登場了 。天下設計都講究一個不要過度設計，軟件設計也不例外，做到這里是很好懂的，那我們也不要畫蛇添足 。
很多人一看到可能的擴展點，就想了一大堆可能的需求，再有個9呢？或者是所有的素數(shù)，比如11啊，13啊……
這方面我們要有耐心一點，比起可能降臨的擴展給我們帶來的困擾，我們自己亂添加的擴展機制更可能會坑死自己 。
有個段子是這么講的，有個人請來了一個新手，一個老手，一個高手，給他們布置了一個任務，穿過一片農田到對面的房子去，這片農田就隱喻我們的代碼，問要多長時間 。
新手看了一眼距離說估計15分鐘就能過去 。老手看了一眼，說要半天 。高手也看了一眼，說15分鐘 。新手進到農田，不停的掉到坑里，踩爆了幾個雷，最后被埋在田里了 。老手小心翼翼，過程中填了幾個坑，排了幾個雷，花了半天的時間，終于到達了房子 。發(fā)現(xiàn)高手早就已經在那兒等了他很久了 。老手不解，問為什么你可以這么快？你怎么干掉那些雷的？高手說，因為從一開始我就沒有埋雷 。
這個段子告訴我們，程序員自己給自己埋的雷往往會成為未來的負擔，好的程序員會盡量少的給自己埋雷 。這所謂的雷，可能一開始就是一個精心設計的機制 。
不要以為這只是一個段子，在曾經工作的一個項目上，我接了一個特別簡單的任務，以為一會兒就能做完，打開代碼之后，我發(fā)現(xiàn)之前的代碼竟然是用反射機制設計的一個極其復雜的擴展機制 。為了搞懂這個機制，我竟然花了一個禮拜 。最后我覺得這個機制實在不利于擴展，我現(xiàn)在對它知根知底，為了防止后人再進這個坑，我就把它刪掉了 。刪之前我就很好奇，這么復雜的機制，有沒有起到易于擴展的作用啊，于是我就打開版本控制的歷史記錄，我發(fā)現(xiàn)他是兩年前添加的，在過去的兩年之中，從來沒有進行過一次擴展，直到今天被我刪掉 。想想也對，這么復雜的代碼，別人讀都讀不懂，為什么會選擇在這兒擴展呢？所以不要盲目追求易于擴展的設計，絕大多數(shù)時候剛剛好的設計才是最好的設計 。
相關經驗推薦
- 家譜英語
- 第三天英文怎么寫 第四天英文怎么寫
- oliver怎么讀 oliver怎么讀英語人名
- 蘋果的英語怎么讀 螞蟻的英語怎么讀
- 即使是這樣英語怎么說 即使這是色情
- 新年賀詞中英文對照50字 英語新年賀詞50字
- 你喜歡吃水果嗎的英語怎么說 問別人喜歡吃什么水果的英浯怎么說
- 制造商一定要在外包裝上寫嗎 制造商一定要在外包裝上寫嗎英語
- 云南2023年普通高等學校招生第二次英語科目聽力考試和口語測試公告
- 云南高考第二次英語聽力考試需要戴口罩嗎