下午寫代碼，一邊寫單元測試，一邊修復通過單元測試發現的問題，遠比用debug調試效率更高，且會發現一些自己都意想不到的問題。所以，今天想和大家聊聊“單元測試”:
“這個方法邏輯這么簡單，一眼就能看明白，還需要寫測試么？”
這個是我們在代碼走查過程中，大家最喜歡說的一句話，聽起來似乎很有道理。但這個“有道理”有一個前提，是我們在靜態的看待這個代碼，和靜態的看寫代碼這件事情，而這兩個前提其實是不成立的:
復雜系統的爛代碼，不是一天兩天產生的，需求變更是很經常的事情，我們的代碼一開始可能都很簡單，但日積月累，就變得很復雜了，今天的簡單并不代表一直都簡單，而如果一開始就不去寫，后面變更的復雜的時候，基本上也不會愿意去寫。
寫單元測試，本身這個技能不是靜態的，很多時候大家不愿意寫，是因為交付壓力太大，覺得寫單元測試很花時間，不好的單元測試維護成本也高，這是一個惡性的循環。里面蘊含了兩個問題，寫單元測試花時間，是因為你對這件事情的熟練程度不夠高，不好維護的單元測試源于你寫法有問題，甚至可能是代碼結構不好，這說明問題不在于“單元測試不好”，問題在于你對這個技能的掌握不夠。所以，當我們面臨一些復雜的場景問題的時候就更寫不出來了。
因此，如果我們換個角度來看待這個問題，一個簡單的邏輯，去寫單元測試相對來說更容易，便于我們修煉寫的技能，當代碼演變更復雜的時候，相應的測試也會更加的豐富起來。久而久之，大家會養成一個習慣，當寫的越多，自然會寫的越快，也會寫的越好，技能提升了，當我們面臨復雜場景的時候也有了更大的信心。而且，一開始就寫測試的話，自然會從業務上去考慮邊界和異常場景的處理策略。習慣本身的力量是一個長期的累計效應，比做當下這件事情更有價值。
再從另外一個層面來看待這個問題，我們講到在梳理需求用例的時候，需要考慮這個需求的測試策略，哪些用例是可以通過UT覆蓋的，哪些用例是通過手工測試覆蓋的，不同層級的用例互補，尤其是對于一些邊界和異常的考慮。在手工測試層去做這樣的測試大多是很費時費力的，而且很多有可能基本沒法做。所以，當我們做故障復盤的時候會看到很多邊界和異常處理類的問題。當考慮到團隊整體的質量保障測試成本后，會發現很多時候，UT的成本相對低很多。
所以寫單元測試這件事情，并不單單只是對當前這幾行代碼的正確性的一個保障這么簡單。
最后一個角度，談談最近和高老師結對競賽的代碼，他主要負責實現功能，我負責重構。迭代過程中，他會不斷豐富功能和用例，我根據當前代碼不停去做重構，因為有單元測試的保證，所以重構過程也是一個很美好的體驗，可以隨意嘗試發揮，只要測試能跑過，重構的過程就是安全的。這和我們工程中復雜的，沒有任何單元測試保證的開發代碼重構相比感受就很明顯。這也是為什么大家在實際項目中很難去做大的重構的原因。因為《重構》《clean code》《單元測試》這些技術實踐從來都不是單獨生效的，需要很好的配合起來才能達到事半功倍的效果。
下午回來，媽媽正在包抄手，一邊包一邊告訴我:“等我們吃完，再包餃子”，我說:“已經有抄手了，為什么還要包餃子？”。她說:“因為抄手不好帶到公司去吃，餃子比較好帶”。原來，她是考慮到老公明天中午帶飯的問題，如此用心，滿滿的感動，感謝媽媽不辭辛苦每天用心為一家人準備美食。
下午吃完飯，和爸爸媽媽帶筱曉去公園散步，遇見小區里的白玉蘭花，開得正好，而且是罕見的淡黃色，遠遠看去，亭亭玉立，甚是端莊優雅，讓人心生歡喜。公園里，紫荊花、海棠花、櫻花也開得正盛，一串串，一簇簇，帶給我們很美的感受。
在公園逛的時候，我和爸爸推車走在前面，媽媽抱著筱曉半天沒跟上來。我停下來，等一等，等媽媽走上來后，我問她是不是抱不動了？她告訴我，她是在慢慢走，讓筱曉看看一路上的小狗和樹上的小鳥，她每天抱筱曉在公園玩的時候，都會慢慢的，走走停停，讓她去看看這些新鮮東西。我不僅反思，我帶筱曉出去的時候，心態遠沒有媽媽那么好，我更把帶她出去看成了是完成一件事情，會關注從哪里出發，走到哪里然后再回家，而沒有想著把步子慢下來，和她一起去觀察和體驗身邊的美好，心態會對我們產生如此大的影響，感恩媽媽，為我做了一個很好的榜樣，每天帶給筱曉很豐富的體驗。
